[rbridge] ECN RE: TRILL Options

[Caitlin Bestler]

Donald Eastlake wrote:
> 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?

Very cleverly.

Which is to say, that the RBridge and the hosts it services would have
to have some form of local collaboration on traffic flow for this
information
to be fully useful. Since it would not be universally applicable I had
assumed
that this usage would have a very poor chance of grabbing the last few
bits
in the TRILL Header or in getting it to expand by 32 bits.

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

My assumption is that having an L2 entity modify L3 headers is something
best avoided. Of course, if the group thought this was the best strategy
it could add a "MAY modify the IP header for the following reasons"
clause.

But while an RBridge is more like a Router than a traditional Bridge, I 
still think that we're better off thinking of it as an L2 device and NOT
encouraging it to play with L3 headers. That's a slippery slope that
leads
all too quickly to trying to standardize PNAT behavior and a dozen other
forms of middlebox mischief.

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

I'm viewing this more as a supplement to 802.1 Congestion Management.
The 802.1Qau effort is more focused on short congestion storms, while
IETF efforts have been exploring topics such as admission control.
It would be a shame if by enabling larger L2 clouds, RBridges diminished
the value of these IETF congestion controls that work over a longer time
period than 802.1Qau's methods.