[rbridge] ECN RE: TRILL Options

[Caitlin Bestler]

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com]
> Sent: Tuesday, February 26, 2008 9:44 AM
> To: Caitlin Bestler
> Cc: Eastlake III Donald-LDE008; Rbridge at postel.org
> Subject: RE: ECN RE: [rbridge] TRILL Options
> 
> Caitlin Bestler writes:
> > > That's it exactly.  I think ECN is pretty much worthless
otherwise;
> > > it's an end-to-end exercise involving the transport layer, or it
> may
> > > as well not be implemented at all.  ECN that's consumed by
RBridges
> > > alone doesn't make any sense to me.
> > >
> >
> > A TRILL option with ECN semantics could be used directly by an
> RBridge
> > that had other traffic control options on its local ports than just
> > PAUSE, Priority-based Flow Control or Drop. If such methods were
> > available, they would be preferable to modifying the L3 header.
> 
> If that's the intent, then I'm just neutral on the proposal.  I can
> see value in ECN behavior that interoperates with existing network
> layer ECN semantics, but if it's its own independent beast, it's no
> longer interesting ... at least to me.
> 

There probably are  mechanisms where ECN-semantics could supplement
the congestion control mechanisms defined by 802.1Qau. But that type
of extension would not naturally be developed until the 802.1Qau work
was complete. When that happens, it would be a good use of a TRILL
option.