[rbridge] FTag

[Gray, Eric]

Silvano,

Let me answer your points in order, leaving out irrelevant issues:

<Your Point> N*32 is correct, when including Ethernet options/shims 
             (e.g. .1Q or .1S).  This is hardware friendly, because
		 alignment doesn't change going from one header to another.

There are a few different "Ethernet" encapsulations, once we start to
include Ethernet options and the shims associated with those options.

First, and I believe most important, the "shim" we are talking about
(in TRILL) is not an Ethernet option (or associated shim).  It's a 
"shim" as a separate "layer."  Otherwise, it would be inappropriate 
for us to do this work here (in TRILL, as part of the IETF).

Second, "Ethernet" headers do not all align the same.  

Currently, we are talking about having a single Ethertype defined to
distinguish inter-RBridge traffic from other types of Ethernet frames.
If your implementation produces 32-bit aligned Ethernet frames, using
802.1Q, then it will similarly produce 32-bit aligned frames - prior
to considering the TRILL shim - using the new Ethertype.  

We are not proposing a change in any Ethernet frame/header format.

The reference to 802.1Q is slightly disingenuous, because 802.1Q
effectively displaces the existing Ethertype by 32 bits.  802.1Q
"shims" include the Ethertype, because they replace the original
one with 0x8100 and have to include the original in the "shim."

I assume that a similar observation could be made about 802.1S.

In TRILL, we are not replacing the original Ethertype, we are adding
a new encapsulation.  The original Ethertype stays in the original
- re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
no reason to consider the Ethertype to be part of the TRILL shim.

<Your Point> TRILL should adopt this model for its shim header - the
             Ethertype should be included as part of computing "shim"
             size.

In TRILL, we are not replacing the original Ethertype, we are adding
a new encapsulation.  The original Ethertype stays in the original
- re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
no reason to consider the Ethertype to be part of the TRILL shim.

<Your Point> TRILL should optimize the Ethernet case that will cover 99% 
             of TRILL applications.

Coverage is slightly more complete than that.  Considering all of the
layer 2 encapsulations that currently come under an Ethernet umbrella,
TRILL applications are 100% included.

I think we are essentially in agreement on this point.

<Your Point> TRILL bridges will be implemented mainly in hardware and 
             the encapsulation and decapsulation functions need to be 
             HW friendly.

Okay.  I was not making any other point - except to say that alignment
is usually a software concern, especially in initial design.  

Let me be blunt, alignment does not factor into initial hardware design,
but is an issue with hardware re-use complexity.  Bits on a wire are not
"aligned" - you simply collect them as they arrive, serially.

And, in any case, the "alignment issue" is moot, unless you assume that
we need to add an _additional_ Ethertype and I am not including that in
my size computation.

We do not need the additional Ethertype, consequently, we do not have to
account for it.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Wednesday, October 18, 2006 12:05 AM
--> To: Gray, Eric; Caitlin Bestler
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> Eric,
--> 
--> I beg to differ.
--> 
--> N*32 is correct, if you include the 16 bits of Ethertype.
--> 
--> With all the respect for wikipedia, I prefer a reference to IEEE 802.1Q
--> and IEEE 802.1D in which the Ethertype is considered part of the
options/shims.
--> 
--> This is what happens for options like .1Q or .1S (16 bit of Ethertype +
--> 16 bits of options).
--> 
--> This is hardware friendly, since inserting or removing the shim does not
--> change the 32 bit alignment of what follows.
--> 
--> IMHO TRILL should adopt a shim header that is N*32 including the
--> Ethertype = TRILL or 16 + M*32 excluding the Ethertype.
--> 
--> I don't buy that, to be layer 2 independent, we need to not optimize the
--> Ethernet case that will cover 99% of TRILL applications.
--> 
--> I also don't buy any software implementation arguments: TRILL bridges
--> will be implemented mainly in hardware and the encapsulation and
--> decapsulation functions need to be HW friendly.
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > Sent: Tuesday, October 17, 2006 9:48 AM
--> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
--> > Cc: rbridge at postel.org
--> > Subject: RE: [rbridge] FTag
---[SNIP]---