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
Margaret Wasserman wrote:
>
> Hi Jarno,
>
> At 09:51 AM 1/10/02 , [EMAIL PROTECTED] 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 PROTECTED]
--------------------------------------------------------------------
