[rbridge] Summary of "critical bits" issues

[Dinesh G Dutt]

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

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 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. Unsetting a 
bit is far less work than stripping an option, for example and so I'm 
not worried about that complexity. 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.

Dinesh
Joe Touch wrote:
> IMO, here are the important elements:
>
> 1. option order
> 	if you care about short-circuit option processing,
> 	which is reasonable, then we should put HBH options
> 	before E2E ones, and required options (i.e., discard
> 	if not supported) before voluntary options (i.e.,
> 	pass if not supported)
>
> 2. option groups
>
> 	Hop-by-hop
> 		examined at all rbridges
>
> 	End-to-end
> 		examined ONLY at ingress and egress rbridges
>
> 	Discard
> 		if not supported, the device discards the segment
>
> 	Pass
> 		if not supported, the device passes the segment
>
> 	Silent
> 		if not supported, the device acts as indicated
> 		with no further action (e.g., discard or pass)
>
> 	Noisy
> 		if not supported, the device sends a signal segment
> 		indicating the failure upstream towards the offending
> 		segment source; this MAY occur periodically as an
> 		aggregate signal
>
> 	NB: that means THREE flags in every option
>
> Some on this list argue that the common case will be devices that
> support no options, thus it would be useful to also know the following:
>
> 3. summary flag in the main header
>
> 	ALL SILENT, ALL PASS
>
> This would be a logical OR of all equivalent bits in the options.
>
> The cost of doing this is that:
>
> 	1. space in the main header
>
> 	2. adding/removing any option MUST update the summary flag
>
> 	COST to add: easy; just OR the extra bits
>
> 	COST to delete: expensive; MUST scan other headers
> 	to determine whether the summary flag changes
> 	i.e., every option delete is O(entire option space) in cost
>
> Whether this summary flag represents HBH only or includes E2E, or
> whether there are two flags - one for each - is also up in the air.
>
> -------------------------
>
> A key point here is that the summary flag makes sense ONLY if there are
> SILENT, PASS options. IMO, they're useless - if an rbridge can ignore an
> option and be equivalently compliant, why would it ever implement that?
>
> I.e., I would argue that any SILENT, PASS options are thus implicitly
> optional, and should be omitted from consideration anyway.
>
> As a result, it makes no sense to me to include the summary bit(s).
>
> 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