I just reviewed the related threads on this list and the proposed text
quoted below seems to have unanimous support (less ~2 persons) on the
list. I support this text as well, but have a worry about it not stating
in which context flow label, when set, is meaningful. The text below
says that the label is used to "label sets of packets". In the SLC
meeting I presented our proposal to consider the (Source Address, Flow
Label, Destination Address) 3-tuple to classify the "set of packets".
There was wide support for this in the room (as is recorded in the
minutes:
http://playground.sun.com/ipng/minutes/ipv6-minutes-dec2001.txt). See
the presentation for the rationale for the 3-tuple:
http://playground.sun.com/ipng/presentations/dec2001/draft-rajahalme-ipv
6-flow-label-001.pdf.
The problem with not stating this is that we could end up having
multiple state establishment methods specifying conflicting classifiers,
which would make classification in routers ambiguous. Also, not stating
how the "set" can be classified will not help HW-designers to do the
right thing with their designs ASAP.
Text including the S+D addresses would be like (the second sentence is
added, no other changes):
The 20-bit Flow Label field in the IPv6 header MAY be set by a
source to label sets of packets. A packet can be classified to a set
with the source address, flow label, destination address triplet.
Nodes that do not support the Flow Label field MUST set the field to
zero when originating a packet, and MUST ignore the field when
receiving a packet. All routers MUST pass the field on unchanged
when forwarding a packet.
This specification does not further define the meaning of the
Flow Label.
[and delete Appendix A, which is unhelpful.]
The added benefit of the above is that IF there is an SLA referring to
specific flow label values, those values would only effect the treatment
of the packets of the customer having the SLA (one of the customer's IP
addresses being either in the source or destination address fields).
Also, note that the above does not prevent having multiple triplets
indicate the same "set" (so, IMO, no generality is lost).
So, for those who have hummed yes to the text below, how many of you
would oppose modifying it to include mentioning the fields used for
classification, and why?
Jarno
> -----Original Message-----
> From: ext Margaret Wasserman [mailto:[EMAIL PROTECTED]]
> Sent: 27. joulukuuta 2001 18:09
> To: Brian E Carpenter
> Cc: [EMAIL PROTECTED]
> Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]
>
>
>
> Actually, I would take out the word "uniquely". I am
> not sure that we want to confine possible QoS solutions
> to "uniquely" labeling anything.
>
> Margaret
>
>
> At 10:43 AM 12/27/01 , Brian E Carpenter wrote:
> >Taking Scott's suggestion, here's another try:
> >
> >I'd like to propose the following as the
> >complete and total replacement of Section 6 of RFC 2460.
> >
> > The 20-bit Flow Label field in the IPv6 header MAY be set by a
> > source to uniquely label sets of packets. Nodes that do
> not support
> > the Flow Label field MUST set the field to zero when
> originating a
> > packet, and MUST ignore the field when receiving a
> packet. All routers
> > MUST pass the field on unchanged when forwarding a packet.
> >
> > This specification does not further define the meaning of the
> > Flow Label.
> >
> > [and delete Appendix A, which is unhelpful.]
> >
> > 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
