Subject: Update: Proposed update to RFC 2460 [was Re: Flow Label]

From: [email-masked]
Date: Thu, 10 Jan 2002 16:51:52 +0200

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-masked]]
> Sent: 27. joulukuuta 2001 18:09
> To: Brian E Carpenter
> Cc: [email-masked]
> 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-masked]
> >-------------------------------------------------------------------- 
> 
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Sun, 13 Jan 2002 01:22:57 -0500 (EST)

I agree.  The triplet is necessary and will avoid state deadlocks for
sure.  This is what I thought I agreed to at SLC as you suggest. I support
your change.

regards,

/jim

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 13 Jan 2002 18:30:13 -0800

Using an Exclusive OR function on the two StarGate values
means that the bit difference is carried across the IPv4 transport.
Either end knows itself and can derive the other side by doing
another Exclusive OR. This is similar to using Exclusive OR
values in linked lists where only one address is stored. When
one knows the location of the node, and a node where they
came from, they can compute where they are going.

http://www.dot-biz.com/RepliGate/

Jim Fleming
http://www.RepliGate.net

----- Original Message -----
From: "Jim Bound" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, January 12, 2002 10:22 PM
Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label]