[rbridge] Summary of "critical bits" issues

[Dinesh G Dutt]

Joe,

I see now that what you're proposing is that all RBridges learn how to 
process options from day one, the processing logic is what an 
intelligent IPv6 router does. I see the logic. If this acceptable to 
all, I'm fine with it.

Dinesh
Joe Touch wrote:
> Dinesh G Dutt wrote:
>   
>> Very nice summary Joe.
>>
>> I disagree with your conclusion of "If an RBridge can ignore an option
>> and be compliant, who would implement it". For cost reasons, I see that
>> we can build a device with a small MAC table than uses the LID, in
>> Donald's example, to forward the frame at the last hop RBridge (this
>> will be in a modular chassis with separate ingress and egress forwarding
>> tables). I can also see a bunch of other examples where the core
>> RBridges are the existing ones, with no support for options, but the
>> edges support a new option that provides a value add and so customers
>> can only change the edge devices and not upgrade their core RBridges
>> (i.e. all their infrastructure to gain support of a feature).
>>     
>
> The last issue would address the HBH vs E2E options. It still begs the
> question of silent pass E2E options.
>
>   
>> If we don't add support for this (a summary bit or two), I think options
>> are dead in the water. Bumping the version number doesn't work unless we
>> add verbiage to indicate essentially the same thing. Most implementors
>> barf if they see a version that is different from what they're expecting.
>>     
>
> I don't see why the decision is:
>
> 	a) summary bit (or two)
> 	OR
> 	b) version numbers
>
> There is a fine third option, which is what IPv6 uses:
>
> 	c) declare the basic format of an option now
> 	and the bits therein, and parse the options at each hop
>
> Note also that the summary bits are basically equivalent to:
>
> 	d) declare an option right now that is a function of these
> 	bits in all the other options, and which must appear first
> 	in the option list
>
>   
>> I also see that the cost of parsing options is something that those
>> RBridges that support options must do and so setting the summary bit,
>> clearing the summary bit is all work that they'll do anyway.
>>     
>
> Processing a single HBH option is much less work than scanning all
> remaining options to decide whether to clear the summary bit.
>
>   
>> Unsetting a
>> bit is far less work than stripping an option, for example and so I'm
>> not worried about that complexity.
>>     
>
> To be more clear, stripping an option - or changing its bits - involves
>  work, but much less than subsequently scanning all remaining options to
> recalculate the summary bit.
>
>   
>> But those RBridges that don't support
>> options can merely look at the summary bits without worrying about
>> understanding and parsing through all the options.
>>     
>
> If we outlaw options that are SILENT, PASS, HBH - which is a very wierd
> case - then we really don't need a bit at all. All we need to do is
> examine the first option:
>
> a HBH rbridge could then execute the following:
>
> 	- if there ARE options, AND the first option is HBH
> 		FAIL
> 	else
>  		PASS
> 	
> IMO, E2E rbridges don't need this optimization.
>
> Joe
>
>
>   

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