[rbridge] Critical bits for options

Radia Perlman Radia.Perlman at sun.com
Thu Dec 6 14:39:56 PST 2007


I think the possibilities are
a) what's in the spec now: a way to skip over all options. This means we 
can't define a critical option, because current RBridges
will skip over it, and not realize that they are supposed to drop the 
packet because it has a "critical" option in it
b) define option format, including marking each option as critical or not
c) everything in b, but also have two summary bits "critical hop by hop 
option is in this packet" and "critical end to end option is in this packet"
d) just define the two bits "critical hop by hop" and "critical end to 
end" option exists.
The issues in each
a) we won't be able to define an option that is "critical" without using 
a new version of the TRILL header (which is actually a plausible
work-around), because current RBridges will just skip all options
b) Might slow the WG down, but maybe the format won't be controversial. 
If the two critical bits are not there, then it will slow down
RBridges that don't support any critical options, because they will have 
to parse through all the options.
c) the two summary bits are, as someone pointed out, redndant 
information if each option is marked as critical or not. However,
the summary bits do make forwarding faster for bridges that don't 
support any options, because they don't have to look through the
options
d) this is the minimal thing we'd need to do if we want to allow 
critical options

At this point I favor d), because it's really easy to specify, and then 
we don't have to argue about the format of options.
Don Eastlake actually had designed a format, and has verbiage for it, 
but I had perhaps bullied him into taking it out of the spec because
at the time I didn't think it was worthwhile defining the option formats 
if we weren't defining any options.

Radia


More information about the rbridge mailing list