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