[rbridge] Critical bits for options
Radia.Perlman at sun.com
Tue Dec 4 19:02:45 PST 2007
I'd like to make sure the decision about whether to define critical bits
for options is made with "informed consent" of the WG. I will write
this with no opinion -- just the tradeoffs.
Currently the TRILL spec says to ignore all options -- the only thing
the spec says is how to skip the options, if any.
A "critical" option (some people call it "mandatory") is an option that
if it appears and you don't understand it, you MUST drop
the packet. A noncritical option is one that you are allowed to ignore
and skip over.
The way the spec is now precludes critical options, because RBridges
following the current spec will skip all options.
An alternative is for TRILL to define two bits at the beginning of the
options (these bits only appear if the options length is
greater than 0).
The two bits are:
a) a critical hop-by-hop option exists
b) a critical end-to-end option exists.
If we define these bits, then an egress RBridge MUST look to see if
either of those bits are set, and if so, parse the options.
A transit RBridge MUST look to see if the hop-by-hop bit is set, and if
so, MUST parse the hop-by-hop options.
Though I suppose an RBridge that doesn't support ANY critical options
would know based on the presence of a critical
option that it should drop the packet, without having to parse to find
the critical option.
So, our choices as a WG:
Choice A: Define NOW that the first 2 bits in the option portion, if the
option length is nonzero are those two
critical bits. And that if you are forwarding an encapsulated data
packet (i.e., you are acting as a transit RBridge
for this packet), and thost of choice first (hop-by-hop critical) bit is
set, you MUST drop the packet. And if you are egress
RBridge, and either of the first two bits are set, you MUST drop the packet.
Choice B: Leave the spec as it is
The cost of choice A is a bit more complexity, and a bit more overhead
of forwarding because of having the set the bit.
The cost of choice B is that we cannot ever define critical options.
The other arguments might be
. how likely is it that we'd ever need critical options? Can we imagine
some examples that we'd ever really want/need?
. we could support such things by using a new version TRILL header when
including critical options, so we are not
really precluding critical options.
. we could advertise (in LSPs for end-to-end critical options, in Hellos
for hop-by-hop critical options), support for critical
options, and the previous hop RBridge can throw the packet away if
there's no way to forward it without the critical option, so
we don't really need for the receiving RBridge to discard the packet.
. how bad would it be for an RBridge to ignore a critical option?
So...what do people think?
More information about the rbridge