> -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Friday, February 26, 2010 4:04 AM > To: Rémi Després > Cc: Sheng Jiang; '6man' > Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] > > On 2010-02-25 20:48, Rémi Després wrote: > > Brian, Sheng, > > > > The proposal seems nicely stabilized as regards the MSB=0 case. > > IMHO though, more than proposed so far could be done > concerning the MSB=1 case. > > > > In sec 3, instead of "If the MSB of the flow label is 1, > the remaining 19 bits MAY obey a locally defined set of rules > and those bits MAY be changed en route", we could have: > > "If the MSB of the flow label is 1, the remaining 19 bits > MAY obey a different defined set of rules. Each such set will > have to be identified by a specific value of the 3 bits that > follow the MSB." > > > Hmm. I am not anxious to invent a central registration scheme > that would mean the user only has 16 bits left to play with. > Some of the schemes I have seen (references in the draft) use > most of the 20 bits in ingenious ways.
I guess, this is a little bit out of the scope. I prefer to discuss how to use the remaining 19 bits with specific use cases. For me, until we have specific use cases, we cannot decide whether identify bits for subset of local defined behaviors are needed and how many bits may be needed. I also agree with Brian, 19 bits is already very limited, give out any bit is luxurious. Sheng > > > We therefore: > > - avoid to exclude some new rule sets that would apply end to end; > > - prevent that some new rule set would take for itself all > possible values having MSB = 1. > > > > Sorry to have this a little late, but better late than > never, right? > > > > RD > > > > > > Le 25 févr. 2010 à 00:15, Sheng Jiang a écrit : > > > >> > >>> -----Original Message----- > >>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > >>> Sent: Thursday, February 25, 2010 4:10 AM > >>> To: Rémi Després > >>> Cc: Sheng Jiang; '6man' > >>> Subject: Re: [Fwd: I-D > >>> Action:draft-carpenter-6man-flow-update-00.txt] > >>> > >>> On 2010-02-25 02:39, Rémi Després wrote: > >>>> Le 23 févr. 2010 à 22:02, Brian E Carpenter a écrit : > >>>> > >>>>> I think we can make this OK by the following type of rule > >>> (I really > >>>>> haven't worked out all the possible cases carefully, however). > >>>>> > >>>>> If a packet arrives with all 0, then local use is > allowed but if > >>>>> the packet leaves the local domain the label MUST be set > >>> back to all > >>>>> 0. > >>>>> > >>>>> That actually requires that the local use method MUST > >>> include a flag > >>>>> bit meaning "this was originally all 0", but that seems > >>> easy enough. > >>>>> Then the current default behaviour is perfectly preserved > >>> when viewed > >>>>> outside the local domain. > >>>> What makes the most sense to me is: > >>>> - first bit =0 ==> Must be preserved end to end. > >>>> - If there is some local use to traverse a domain, the > >>> value at entrance has to be restored at exit. > >>>> Now, if the entrance value is all 0, this fact can be coded > >>> in the local-use format, so that it is easy to restore > the entrance > >>> value at exit. > >>>> On the other hand, if the entrance value is E2E and non 0, > >>> some means to keep this value in the modified packet has to be > >>> found. How to do it has to be taken care of when designing each > >>> particular local use. > >>>> Reasonable? > >>> 100%, in my humble opinion. So there are actually three > cases when a > >>> packet arrives in a local-use domain (either from a local host or > >>> from a border router): > >>> > >>> Flow label is zero: local use allowed (with MSB=1) but > label must be > >>> set to zero on exit from the domain. > >>> > >>> Value between 1 and 0x7FFFF: local use not allowed, label > must not > >>> be changed > >>> > >>> MSB=1: local use allowed. > >> This is petty good. It solves our original worry: local use is not > >> allowed when flow label is all zero. I guess we can update > the draft > >> with this design now. > >> > >> Cheers, > >> > >> Sheng > >> > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
