[rbridge] TRILL Options

[James Carlson]

Caitlin Bestler writes:
> Not that the list of options described in this document needs to
> be all inclusive, but I think there is one class of option at least
> as probable as those cited here: a "pseudo-router" option.
> 
> This option would allow an RBridge to report congestion as though
> it were a router, by encoding what a ECN capable router would have
> encoded -- but without requiring the RBridge to actually modify 
> L3 headers.

Why would it need to be an option?

Since we know about ECN now, why not just reserve a couple of bits for
it, and allow the bridges that know how to mark properly do so?
(Those that don't know how will just blindly forward the existing bits
along, which is what you want for ECN anyway.  An ECN-incapable egress
would just lose the bits.)

Perhaps I'm missing the point, but I think the only reason to have
options is that there's something that requires inter-bridge
cooperation.  If it doesn't require cooperation in order to achieve
interoperability, then it doesn't need an option.

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