Brian et al,
A lot of mail but lots of it are repeating. The only way my change in
vote for "c" will work is if we do this below per Brian. But I presented
this case in front of the IETF WG at Minneapolis and folks did not want to
go there and Steve presented good counter arguments to doing it. It is a
compromise to do the below.
A few statements:
Immutable field: I agree with Tony 100% if we have a per microflow it
should be immutable for that option and I mean in the strongest sense
that it is read-only. I will not post my reasons again but they are in
line with Tony and also that I am not comfortable saying nodes along the
path will return the field to its former value. AT ALL.......Causing bugs
with per microflows for apps that depend on it is something I could never
support and to trust the edge and core with that without how its to be
done is a bit of a stretch for me and I think for any IETF specifications
sound protocol effect on networks. Immutable field is the quickest way to
standards track I would argue for per micro-flows. In the future after
some practical experience that could be re-discussed.
MF Classifiers: We should solve this problem so that all classification is
done only at the header. The multiple tuple value for classification
beyond the header in Diffserv architecture was a huge mistake to put in
the model and having boxes look at L4+ values is bordering absurdity IMO.
IETF Rants we need to support QOS other standards: This is simply bogus
logic. As Bob said the place to change our rules is in POISED not IPng.
If Diffserv made a mistake or neglected to deal with cases like IPsec that
does not mean IPv6 WG MUST support fixes to make it work. That is the
bogus logic. It assumes a rule for us in IPv6 WG which DOES NOT EXIST.
Arguing it may be the right thing to do is fair. I don't agree though.
Are we getting anywhere? After working on this for many years I feel NO.
The bottom line is can the IPv6 WG agree to the attached compromise in
some form? That should be the first thing we have to agree on or Thomas
is correct we need to just leave it alone for awhile till we can get
consensus. We don't have it now IMO.
Should we use the flow for other than QOS? I think that is a wise vision.
But then we need some kind of compromise for that too.
/jim
On Tue, 28 Aug 2001, Brian E Carpenter wrote:
> How would people feel about this encoding for the flow label
> (deemed to be immutable end to end)?
>
> 0 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0| Per-microflow unique value |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> 0 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |1| Non-unique value |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> I'm not yet 100% convinced that the second case is sufficient for
> diffserv, but at least it would be a more generic approach
> than reserving half the space for diffserv.
>
> Brian
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
