[rbridge] Critical bits for options

[Dinesh G Dutt]

You're saying that if we make options support possible in the fast path, 
most likely over time there will be more devices that support some 
options but not others, so a single bit doesn't suffice because the 
device that supports some options cannot decide if a specific option is 
critical or not. So you're saying if we define within  the options two 
additional containers, hop-by-hop and e2e,  and state that one comes 
before the other, we're in a better shape.

I agree with your logic.

I'm still not sure whether we need all the logic of IPv6 options such as 
stating whether an option may change HbH and we can probably use a 
single bit to decide whether we can skip over the option or discard the 
frame; we can ignore the ICMP options piece.

Dinesh
Joe Touch wrote:
> Dinesh G Dutt wrote:
>   
>> v6 rules are more complicated than we need, aren't they ? All we need is
>> the ability for an Rbridge to say, "I don't support any options, but
>> this frame has options which I understand are fine to ignore and so I'll
>> process the frame in fast path AND not delete the options from the
>> outgoing frame". 
>>     
>
> If there are two variants:
> 	- NO options implemented
> 	- some options implemented
>
> AND we're trying to optimize the no-options case, then yes, a single bit
> would be useful. I am concerned that "no options" is a corner case; it's
> more likely that over time there will be some options in most devices.
>
> If that's the case, then a single bit doesn't help.
>
>   
>> This allows us to define options that can pass through
>> transit Rbridges. If we don't do this, I'd say that options would in
>> "dead in the water", pretty much like IP options.
>>     
>
> If we need to optimize for the 'no critical options' case, then ALL
> critical options are dead in the water, by the above logic...
>
> Joe
>   
>> Dinesh
>> Joe Touch wrote:
>>     
>>> A few lessons from IP (which we may or may not want to emulate):
>>>
>>> --------------------------
>>> V6 rules:
>>>
>>> - hop-by-hop options MUST come before E2E ones
>>>
>>> - unrecognized options have 4 variants indicated via flags:
>>>     - silent pass (skip over silently)
>>>     - silent discard
>>>     - discard w/ICMP
>>>     - discard w/ICMP iff source != multicast
>>>
>>> - an additional per-option flag indicates:
>>>     - immutable en-route
>>>     - mutable en-route (i.e., ignore in Auth)
>>>
>>> --------------------------
>>> V4 rules:
>>>
>>> - unrecognized options
>>>     - silent pass
>>>
>>> -------------------------
>>>
>>> I'll note that IPv6 doesn't e have a summary bit about critical HBH
>>> options. I don't see why we would anticipate being more complex than
>>> IPv6 in this regard.
>>>
>>> IMO, the IPv6 rules are probably sufficient to use as-is.
>>>
>>> Joe
>>>
>>>
>>>  
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>   
>>>       
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan