[rbridge] ECN RE: TRILL Options

[Eastlake III Donald-LDE008]

A few things:

Currently there are only two free bits in the TRILL Header.

If the intent of the ECN feature is to affect host behavior, how is this
communicated to the host? If it uses bits either in the TRILL Header or
in a TRILL Option, these are lost at the egress Rbridge. -- Although
perhaps affecting Rbridge behavior could also be beneficial. And for IP
frames, we could set bits in the IP header...

There is also the 802.1 Congestion Management effort perking along...

Thanks,
Donald

-----Original Message-----
From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] 
Sent: Monday, February 25, 2008 2:12 PM
To: James Carlson
Cc: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] TRILL Options

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