[rbridge] Summary of "critical bits" issues

[Joe Touch]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071213/b4db0df6/signature.bin