[rbridge] Critical bits for options

[James Carlson]

Eastlake III Donald-LDE008 writes:
> Hi James,
> 
> See below at @@@

Oh, how I wish the quoting styles were common ...

> @@@ There is clearly a spectrum of possibilities for the details in the
> "base protocol" specification. The current document is pretty much at
> one extreme, having just a size field and saying nothing about the
> content of the options area.

Indeed.  The problem that causes is that you can't really have a
meaningful conversation about when to drop or pass based on options,
as there's currently no understanding of what's *in* the options.

> @@@ Adding a specification of a few summary bits at the start of the
> options area if the options length is non-zero would be the next step.

I don't agree.  That's a *possible* next step, but not *the* next
step.  The assumption you're making is that summary bits are either
useful or necessary, and until we have some clue about the semantics
we want, we don't know that.

So, for example, it's possible to arrange the options such that a
transit node that implements _no_ options at all can determine whether
to pass or drop a frame based on the flags on the first option alone.
In that case, there's really very little reason to define "summary
bits" because all we're doing is very slightly and trivially
optimizing that one special edge case -- while at the same time adding
another point where things can be broken.

What happens if the summary bits disagree with the options contained?
Obviously, the system fails, but the point is that duplicating data --
bits from the options into bits in the header -- *always* causes a
risk of data synchronization errors.  Consider for example a node that
must remove options because of the way the options work or because of
local configuration that dictates how optioned-packets are forwarded.
What will it do?  There's a good risk here that the summary bits will
become wrong, as they need to be recalculated during changes.

> While I personally favor this, I used to think it didn't make much
> difference because you would be able to tell what options an Rbridge
> supports by looking in the link state database and not send an Rbridge
> any options it does not support. But that only works well for unicast.
> Because of multi-destination frames (broadcast, unknown unicast, and
> non-IP-derived multicast) I'm even more convinced that it would be
> useful to specify these summary bits now.

I think we need a solid framework for options first, and *then* decide
whether it's worthwhile to add extra flags to optimize corner cases.

The summary bits aren't primary functionality.  They're secondary.
They're derived from the information in the options themselves.  As
such, they're expendable and merely performance hacks.  The life of a
performance hack depends pretty strongly on the performance case for
it, and I haven't seen that argument made yet.

> @@@ The next stage after summary bits would be to specify the format,
> ordering, etc., of options, which is what you are suggesting.
> Unfortunately, I think that could be fairly controversial.

It might be controversial, but what we have right now is a #include in
the specification that names a non-existent file.  We can pretend
that's not a problem by papering around it, but it's going to bite us
eventually.

> Furthermore,
> I believe that the design of the options format would be greatly
> improved by designing a number of specific options at the same time.
> Some such options, like a data frame security option, might be fairly
> complex.

Agreed; having some idea of what might be in options would help, but
it's also true (as others have pointed out) that we can borrow ideas
from other successful option mechanisms.

Having critical/non-critical and hop-by-hop/end-to-end seems like a
sufficient diversity -- but simple specification -- that we can layer
other mechanisms on top later.

> Furthermore, I believe there are multiple efforts working
> towards high speed Rbridges that implement no options and which would
> benefit from progressing the specification to the stability of an RFC.

I don't see that as a serious issue.  What's stopping people from
building implementations before there's an RFC?  What makes them think
that there won't be changes _after_ there's an RFC?  This isn't an
IEEE spec.

I agree that all implementations will benefit from getting this right.
I think they'll benefit more if we define it correctly, so that it
doesn't cause more trouble down the road.

> @@@ All in all, I think that trying to put the detailed option format in
> the specification could delay things by 6 months. A separate document
> seems to me like the way to go. 

Six months seems unlikely to me ... but even if it is that long, I'd
rather have a more robust document than a "quick" one that (years from
now) has vestigial bits relating to performance hacks for obscure
implementations that've been long forgotten.  Protocols are forever,
hardware is not.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677