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