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

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Jan 2002 13:01:55 -0500

Hi Jarno,

At 09:51 AM 1/10/02 , [email-masked] wrote:
>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. 

I do not think that we should define this as part of the IPv6
base specification.  The semantics of the flow label (including how 
it can (or can't) be used to identify a flow) should be specified 
as part of any flow management mechanism that uses the IPv6 flow label 
field.  This may differ from one mechanism to another.

I do not think that the base IPv6 specs should place any constraints
on how flow management mechanisms can use the flow label.

NOTE:  I realize that immutability is a constraint.  I have
        agreed to compromise on that one point.

>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".

It would be okay with me to take out the words "sets of", if you
believe that this is confusing without further context.  

I do not think that we want to specify, as part of IPv6, that a 3-tuple
can be used to identify a flow.  I have two reasons for this:

         - The 3-tuple that you describe is not sufficient to unambiguously
                 identify a flow without further specification of how/when
                 flow labels can be re-used by hosts.
         - How to classify a flow shouldn't be part of the base IPv6
                 specification -- it is specific to a flow management
                 mechanism.

[...]
>Also, not stating 
>how the "set" can be classified will not help HW-designers to do the 
>right thing with their designs ASAP.

Can you give examples of "right things" that could be done if we make
this change that could not be done if we don't make this change?

>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.
[...]
>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?

I strongly object to mentioning "the fields used for classification" as
part of the base IPv6 specs.  I think that flow management mechanisms
and their semantics (including flow classification mechanism(s)) should
be specified in separate documents (and by separate WGs).

Margaret

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jan 2002 08:50:59 +0100

I agree with Margaret. To give one example of where Jarno's
addition can lead us into trouble, an SCTP flow may have
several different addresses at different times; we could
discuss for days whether Jarno's extra text is consistent
with that case. But let's not do so; fewer words are better
in this case.
   
    Brian