Margaret, First, I agree - the normative text needed is very short (Tony's paragraph) and the current draft can be confusing (I can say that since I was a co-author of the previous version:).
Second- both intserv and diffserv already document their use of the flow label. For intserv it's in RFC 2205 (only slightly out of date). For diffserv it's in the MIB (queued up at the RFC Editor). For intserv, the flow label is an optional part of a Filter_Spec, i.e. it needs to have the same value all along the path since the Filter_Spec is signalled along the path by RSVP. For diffserv, the flow label is the only field available as an ISP-independent QOS flag, so (unlike the traffic class) it needs to survive ISP boundaries. Brian Margaret Wasserman wrote: > > >No. The immutability property is necessary for both of the > >existing QOS standards, and is necessary for any QOS mechanism > >that doesn't require an explicit chain of SLAs along the entire > >path (an unlikely scenario in a dynamically routed internet). > > If immutability would make the flow label field useful for > diffserv and intserv, then I have no objection to it being > immutable. I think that making intserv/diffserv more useful > and/or efficient would be a fine use for the flow lable. > > Could we get a draft that explains how the flow label would be > used for diffserv/intserv? One that justifies the need for > immutability? > > Assuming that immutability would actually make the flow > label more useful for diffserv/intserv, I would accept the > minor changes to the base IPv6 spec (adding immutability) that > Tony sent. But, I have not seen any draft that would make this > single change. > > The current draft (in the subject) says a lot more > than this. First, it recaps parts of the IPv6 Appendix, > without really making it clear what parts of that Appendix > it is (and is not) intending to standardize. > > The draft also states that a given source/desination/FL > combination will uniquely identify a flow. This is not > true -- some knowledge of lifetimes, or some restrictions > against flow label re-use would be needed to make this > true. > > Anyway, how a flow is identified shouldn't be defined as > part of the base IPv6 specification. Each signalling > (or other flow management) mechanism should define how > flows are identified for its use -- and this may differ > for different mechanisms. > > So -- what I'd like to see: > > - A draft that explains how the flow label > would be used for intserv and/or > diffserv that explains what properties > are necessary for that use (i.e. > length, immutability, values, etc.) > - A draft that proposes the simple change > to the IPv6 spec that Tony sent. > > Do you think that is reasonable? > > 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] --------------------------------------------------------------------
