[rbridge] TRILL Options

[Caitlin Bestler]

ECN-like bits *could* be defined in the RBridge header, but they
would not be necessary for *RBridge* functionality, but rather for
RBridges to provide this bonus info to the host stacks.

I would be perfectly happy with ECN-like bits being encoded in the
RBridge header, but I can't really make a case as to why the information
needs to be there rather than in options. Encoding it in the options
will work. If there is enough of a consensus that almost everyone
would find ECN-like reporting useful for RBridges then they could
be promoted, but like most of the other speculative options that
Donald listed, this is just an idea about something that seems likely
to be advantageous. It is not a concrete proposal that has been
prototype tested or anything like that.

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com]
> Sent: Monday, February 25, 2008 10:36 AM
> To: Caitlin Bestler
> Cc: Eastlake III Donald-LDE008; Rbridge at postel.org
> Subject: Re: [rbridge] TRILL Options
> 
> 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