[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