[rbridge] Critical bits for options

[Erik Nordmark]

James Carlson wrote:

> We can "special case" the critical options by tweaking the order, if
> necessary.  Just make the order:
> 
>    1. Critical hop-by-hop
>    2. Non-critical hop-by-hop
>    3. Critical end-to-end
>    4. Non-critical end-to-end
> 
> Then, if there are implementations that don't implement any options
> and if those implementations need to "optimize" the discard/pass
> action (!), they can simply look to see if the first option on the
> list is critical, and bail if so, and pass otherwise.  (Decapsulating
> end nodes would have to span over non-critical hop-by-hop options, but
> that seems like a small price.)

With the above ordering constraint it might still be useful to include a 
length of each of the four types, for instance by having the option part 
of the packet start with four N-bit numbers.

That allows a transit RBridge which supports no hop-by-hop options to 
just look at "length of #1 != 0" and if so discard the packet, and it 
allows decapsulating RBridges that don't support any end-to-end options 
to also check quickly that length, and determine the offset for the 
critical end-to-end options.

I think that would make it slightly more efficient to implement RBridges 
that support some options.

But it still isn't clear to me which cases of options we think are worth 
optimizing.

    Erik