[rbridge] Critical bits for options

[Joe Touch]

Eastlake III Donald-LDE008 wrote:
> Hi Joe,
> 
> See comments below at @@@
> 
...
>> 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,

Yes.

> I disagree. If all options present are non-critical, the
> egress Rbridge, like all Rbridges, need not look at any of them.

Optional non-critical options?

Here's the issue: let's say you have a hop option that IS implemented at
the internal hops, but is NOT critical. Which hops would ever see them?
If nobody looks at them, why bother putting them in?

IMO, every internal hop must examine all hop options, and an egress must
examine all end options - that's the only way for either to know which
ones they implement that they CAN handle. The only short-cut here is
that internal hops could skip examining options if there were no hop
options.

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

Yes, safe, but again what's the point of putting things in that nodes
can ignore even if they implement? If the node doesn't examine the
options, how does it know it does or does not support them?

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

The bits are relevant only to rbridges that don't implement the options
used. As you point out, that is useful for rbridges that implement NO
options.

An rbridge that implements ANY options would then need to examine them
ALL to see which ones to handle.

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

You don't need that bit - you get that info from examining the first
option (if it's not HBH, then there are no HBH 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.
> 
> 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.

Sure - for nodes that support NO options, these flags might be useful. B

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

Overall, I'd like to see a case for using these bits. You've made the
case for IPv6 rules - ordering the options, and there clearly also needs
to be IPv6-like flags inside the options.

If the only reason for the summary flag is for transit rbridges
implementing NO options, that's an extraordinarily specific corner case,
IMO, for such a flag.

The flag isn't particularly useful at the egress, IMO.

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/20071205/e5749c67/signature.bin