Subject: [rbridge] TRILL Options

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 24 Feb 2008 10:06:39 -0500

An individual draft has been posted at
ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-
00.txt
for discussion. It gives an example of a more complete options
specification with some example specific options.

Thanks,
Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 25 Feb 2008 13:04:28 -0500

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.

---

From: James Carlson <[email-masked]>
Date: Mon, 25 Feb 2008 13:35:33 -0500

> encoded -- but without requiring the RBridge to actually modify 

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              <[email-masked]>
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
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 25 Feb 2008 14:11:33 -0500

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:[email-masked]]
> Sent: Monday, February 25, 2008 10:36 AM
> To: Caitlin Bestler
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] TRILL Options
> 
> Caitlin Bestler writes:

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 26 Feb 2008 10:22:56 -0500

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

---

From: James Carlson <[email-masked]>
Date: Tue, 26 Feb 2008 11:09:38 -0500

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

That's a pretty good reason to be hesitant.  ;-}

> communicated to the host?

Note that "hosts" in TRILL terminology are quite likely to be
"routers" in the network layer world.

In any event, I'd expect the encapsulating TRILL node to copy the ECN
bits (likely similar to RFC 3168, but perhaps requiring mapping for
non-IP protocols) into the TRILL header, and the decapsulating TRILL
node to apply those ECN bits to the encapsulated packet before
disgorging it onto the destination network.  You then have a record of
congestion encountered in the middle of the bridged network.

Systems that don't do ECN will generally ignore the bits (and will set
00 on transmit), and those that do it will do the Right Thing.  If the
TRILL network doesn't support ECN at all, then the bits get copied
from input to output unmolested -- meaning that congestion through the
larger network is still detected, but that congestion within the TRILL
network is invisible.

If the TRILL encapsulator doesn't do ECN, then the bits will be zero
on input, and the egress can ignore them on output.  If the egress
doesn't do ECN, then the inner packet will be left unchanged, again
meaning that ECN works but that the TRILL network is not visible.

Finally, if the carried protocol doesn't support ECN, or the ingress
RBridge doesn't know how the next level protocol deals with ECN, then
set the bits to zero on entry and thus do nothing on egress.

No "intent" needs to be communicated, as best I can tell.  It's a
best-effort signaling mechanism.

> If it uses bits either in the TRILL Header or

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.

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

I'm afraid I don't know what they're doing.  :-<

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 26 Feb 2008 12:22:56 -0500

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

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 26 Feb 2008 12:29:35 -0500

James Carlson wrote:

> > perhaps affecting Rbridge behavior could also be beneficial. And for
> > IP frames, we could set bits in the IP header...
> 

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.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 26 Feb 2008 13:26:21 -0500

> Sent: Tuesday, February 26, 2008 9:44 AM
> To: Caitlin Bestler
> Subject: RE: ECN RE: [rbridge] TRILL Options
> 
> Caitlin Bestler writes:
> 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.

---

From: James Carlson <[email-masked]>
Date: Tue, 26 Feb 2008 12:43:37 -0500