[rbridge] Critical bits for options

[Radia Perlman]

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?

Radia