[rbridge] Summary of "critical bits" issues
touch at ISI.EDU
Thu Dec 13 12:07:29 PST 2007
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)
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
IMO, E2E rbridges don't need this optimization.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071213/b4db0df6/signature.bin
More information about the rbridge