[rbridge] {Filename?} RE: Critical bits for options

[James Carlson]

Eric Gray writes:
> As an example, suppose you have an option that applies to 
> multicast forwarding but only needs to be acted upon by the
> replication points in a multicast tree.  Is that HbH or E2E?

Forcing that case to be HbH solves the problem.  The hops that are not
replication points need do no work, but we don't necessarily know
which ones these are ahead of time, so we do need each hop to handle
it.

(I get the general point that there may be choices outside of HbH and
E2E, but I'm not sure this example nails the problem.)

> What we have consensus on is to allow for options in the
> future.  Including an options length field is sufficient
> to allow for that.

It's sufficient only if we also remove the text in the current draft
that supposes the existence of "critical" options.

With that text in place, we're in an impossible position: nodes are
required to drop packets with uninterpreted "critical" options, but
they have no way to determine whether any such options are present
that might pose a problem.

That's why I previously suggested defining the length field, supposing
all options are "non-critical," and then bumping the TRILL version
field if we ever require "critical" options.

> > @@@ (cont.)
> >	But I would agree that if an Rbridge advertises in the link 
> >	state database that it supports an option, then it should do 
> >	so.
> 
> And now we are assuming that this will be included in the LSDB
> (as opposed to asserting that it may be)?
> 
> The statement I made above (relative to approriate responses
> in this case) applies.  Failure of a device to accept what it
> has previously agreed to accept represents a serious error -
> for which "oh, well, maybe if I simply forget about it, it
> will go away" may be a less than adequate response.

It's actually unclear to me whether it constitutes any sort of error
for the general case.

The problem is that TRILL packets are forwarded based on tables at
each hop -- they're not source-routed.  That means that the original
sender who generated the packet and inserted those options may not
necessarily know which nodes will actually handle the packet, and thus
doesn't necessarily know which options can be interpreted on the path.

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