[rbridge] FTag

[Gray, Eric]

Silvano,

	In order to avoid giving the impression that I agree with the
below analysis, I've discovered that I need to respond to it.  However,
I do not currently have the time to do so in depth.

	So please accept this brief note as evidence that I disagree
with your analysis and conclusions with respect to alignment needs.
I will respond in depth - hopefully - sometime next week...

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Wednesday, October 18, 2006 12:04 PM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> 
--> Eric,
--> 
--> Let me depict you what happens when you insert one MPLS 
--> label, ore a 1Q
--> option or a 1S option
--> 
--> Original:
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> 
--> Original + Opt (where Opt can be MPLS, 1Q or 1S)
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |      Opt      |
--> +--------------------------------+
--> |      opt       |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> The HW that perform the insertion/removal does not need to 
--> realign the
--> payload that is in its buffer.
--> 
--> 
--> Now Let's consider the encapsulation/decapsulation function 
--> by looking
--> at the Original frame + TRILL header (as proposed by the 
--> current draft)
--> +--------------------------------+
--> |         Outer DA               |
--> +----------------+---------------+
--> |    Outer DA    |  Outer SA     |
--> +----------------+---------------+
--> |         Outer SA               |
--> +--------------------------------+
--> |Ethertype=TRILL |   Trill Shim  |
--> +--------------------------------+
--> |  Trill Shim    |  ????????     |
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> If you don't have the 16 bits indicated by ???????, the 
--> hardware will
--> need to realign the inner frame. The frame is not on the 
--> wire. The frame
--> sits in the packet buffer and the memory bandwidth of the 
--> packet buffer
--> is today the MOST important consideration in port ASIC design.
--> 
--> More inline
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > Sent: Wednesday, October 18, 2006 4:57 AM
--> > To: Silvano Gai
--> > Cc: rbridge at postel.org
--> > Subject: RE: [rbridge] FTag
--> > 
--> > 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).
--> 
--> From the above picture it should be clear that you should 
--> consider the
--> TRILL header as a whole, and the TRILL header as only one form of
--> Ethernet encapsulation.
--> 
--> > 
--> > Second, "Ethernet" headers do not all align the same.
--> > 
--> 
--> Agreed, but that is not my concern, My concern is to not 
--> change their
--> alignment due to the insertion/removal of the TRILL header.
--> 
--> > 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.
--> 
--> Neither do I.
--> 
--> > 
--> > 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.
--> 
--> Yes and a similar observation can be made for MPLS, but all 
--> these three
--> do not change the alignment of the fields that follow.
--> 
--> > 
--> > 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.
--> 
--> As I told before you need to consider the whole TRILL header, i.e.
--> 6 bytes of DA
--> 6 bytes of SA
--> 2 bytes of Ethertype
--> 4 bytes of shim
--> ----------------------
--> 18 bytes
--> 
--> Which is 2 bytes short of N*32, i.e. it is not HW friendly.
--> 
--> For this reason I propose that Ethertype + shim should be 
--> N*32 to be HW
--> friendly.
--> 
--> 
--> > 
--> > <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.
--> 
--> I agree that bits on the wire are not aligned, but you need 
--> to buffer
--> the incoming frame (or at least part of it) until you have 
--> enough fields
--> to perform your lookup and decide what to do with the 
--> frame. From that
--> point on the frame is not on the wire, it is in the packet 
--> buffer and
--> alignment is crucial at the performance we are talking about.
--> 
--> I hope this time I made my point more clear
--> 
--> -- Silvano
--> 
--> > 
--> > 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]---
-->