[rbridge] Critical bits for options

[Eastlake III Donald-LDE008]

Hi Joe,

See comments below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Tuesday, December 04, 2007 11:23 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] Critical bits for options

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.

@@@ Yes, "summary" is a reasonable description of these bits. And, if
one is trying to postpone defining the structure of options in detail,
as the current protocol draft does, making it possible to avoid parsing
them seems like a good idea :-)

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

@@@ If by "parse the entire header" you mean look at each option
individually, I disagree. If all options present are non-critical, the
egress Rbridge, like all Rbridges, need not look at any of them.

@@@ If by "parse the entire header" you mean examine stuff beyond the
TRILL Header, the egress Rbridge has to do that to decapsulate but
transit Rbridges have to do this also. While there are lots of other
reasons to look beyond the TRILL header for various cases of
multi-destination tree pruning, the most general reason is to get the
frame priority from the inner VLAN tag. This is necessary even for known
unicast frames for robustness since the outer VLAN tag may have been
stripped. However, skipping over the options without parsing them is
easy since their length is given and, if you know there were no critical
options present, safe. 

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.

@@@ Well, I expect that many Rbridges will, for a long time, not
implement any options, so they clearly wouldn't need to parse them if
these summary bits were available. Even with Rbridges that do support
some options, I would expect the more detailed TRILL option feature
specification to require that all hop-by-hop options to precede all
end-to-end options (and perhaps, within those categories, to have
critical options precede non-critical options) so a transit Rbridge
could stop parsing as soon as it hits an end-to-end option. You could
also add a summary bit for the existence of non-critical hop-by-hop
options so a transit Rbridge would know if all the options present are
end-to-end.

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

@@@ Transit Rbridges that support no hop-by-hop options, critical or
non-critical, are expected to be very common.

@@@ It is also good to keep in mind that, at least for unicast, these
summary bits are probably just a safety measure. That's because I would
expect that Rbridges will be required to announce in their LSP what
options they support (at least for critical options and probably for
all). Thus, by imposing requirements on the sender, you could claim that
no unicast frame with a critical option should ever be sent to an
Rbridge that does not support it. However, in the real world, errors of
all types happen. If, say, a transit Rbridge that supported no options
did receive a frame with a critical hop-by-hop option in it and you did
not have these summary bits (or they were set wrong), it will screw up.
But there is no way in the real world to guarantee that something like
that could never happen.

@@@ An argument in favor of the bits is that you might have a case where
you are forwarding a multi-destination frame down a distribution tree
from Rbridge Z and out one port there are three downstream Rbridges one
hop away, A, B, and C, where the frame has a critical option that you
know from the link state database is supported by A and B but not C. It
might be nice, for some options, to be able to just multicast the frame
knowing that C will just discard it. This would be a decision by RBridge
Z (which must understand the option or it would not have created or
successfully received the frame).

Joe

@@@ Thanks,
@@@ Donald