[rbridge] Critical bits for options

[Joe Touch]

Radia Perlman wrote:
> 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.

I believe we're talking about a "summary" bit in each case. As a result,
the goal of these bits is to avoid parsing the options in detail.

There is benefit ONLY for hop-by-hop bits, i.e., to accelerate
forwarding. Egress rbridges would need to parse the entire header anyway.

That said, I'm not sure this is the right meaning for these bits. They
are useful as a summary ONLY if they indicate whether "CAN IGNORE" in
fast path rbridges.

Let's presume that's NOT what the bit means, i.e., the bit means there
is a critical option (as defined above). The rbridge still needs to
parse the entire option set to find out WHICH options are listed, and to
decide whether each is supported or not anyway.

> 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.

That works ONLY for the case where an rbridge supports NO critical
options. If it supports any, then it needs to parse the entire header
anyway. Is that really worth this?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071204/0870e5cf/signature.bin