Subject: [rbridge] FTag

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 19 Oct 2006 14:47:29 -0700

Disagreement noted, waiting for the explanation

Cheers

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Thursday, October 19, 2006 11:48 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] FTag
> 
> 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]---
> -->