[rbridge] Critical bits for options

[James Carlson]

Dinesh G Dutt writes:
> v6 rules are more complicated than we need, aren't they ? All we need is 
> the ability for an Rbridge to say, "I don't support any options, but 
> this frame has options which I understand are fine to ignore and so I'll 
> process the frame in fast path AND not delete the options from the 
> outgoing frame". This allows us to define options that can pass through 
> transit Rbridges. If we don't do this, I'd say that options would in 
> "dead in the water", pretty much like IP options.

I don't understand that quoted section.  Why would we define options
that "everybody" is going to ignore?  What would be the point in
having always-ignored options?

If an implementation actually has support for a given option, then I
would expect it to be obligated[1] to process that option, and it
should not just "ignore" it.  Ignoring is equivalent to _not_
implementing.

I think the only question is whether a node receiving a TRILL frame
can determine if there are options that it must process.  The rules
sound to me like:

	- If you're a transit node, then process all options up to
          either the end of the list or the first end-to-end option,
          if any.

	- If you're an end node, then process all the options.

We can "special case" the critical options by tweaking the order, if
necessary.  Just make the order:

   1. Critical hop-by-hop
   2. Non-critical hop-by-hop
   3. Critical end-to-end
   4. Non-critical end-to-end

Then, if there are implementations that don't implement any options
and if those implementations need to "optimize" the discard/pass
action (!), they can simply look to see if the first option on the
list is critical, and bail if so, and pass otherwise.  (Decapsulating
end nodes would have to span over non-critical hop-by-hop options, but
that seems like a small price.)


[1] Choosing my words carefully here -- "obligated" in moral sense,
    rather than "required" in an RFC 2119 sense.

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