[rbridge] FTag

Tue Oct 17 21:05:19 PDT 2006

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
> 
> Silvano,
> 
> 	Ethertype is a field in the 802.3 header (see, for example, the
> figure at:
>
http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_Ether
Ty
> pe
> _field).
> 
> 	Assume that - when examining the SHIM header - the Ethernet
header
> has been
> removed, retaining only the relevant "context" information required by
a
> specific
> implementation.  Part of the "context" would be related to MAC DA (is
it
> mine?),
> and Ethertype.  Related to (perhaps as a litteral, perhaps as a
mapping),
> not the
> same as.
> 
> 	For purposes of examining the SHIM, it is convenient to assume
that
> it is
> aligned as presented.  How it is actually aligned will be
implementation
> specific.
> 
> 	Where alignment matters most is in software used to prepare data
for
> sending
> or decode data on receipt.  In some cases, alignment can be important
in
> reducing
> the complexity of hardware re-use.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> Sent: Tuesday, October 17, 2006 12:34 PM
> --> To: Gray, Eric; Caitlin Bestler
> --> Cc: rbridge at postel.org
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> --> Eric,
> -->
> --> Do you include in your computation the 16 bits of Ethertype =
TRILL?
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> --> > Sent: Monday, October 16, 2006 4:06 PM
> --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
> --> > Cc: rbridge at postel.org
> --> > Subject: RE: [rbridge] FTag
> --> >
> --> > Silvano,
> --> >
> --> > 	The "encapsulated frame" alignment varies from layer to
> --> > layer and is independent from layer to layer.  When the bits
> --> > hit the wire (or glass), the alignment is not of a particular
> --> > importance.  It is the process of "hand-off" between stack
> --> > layers that might be relevant, depending on implementation.
> --> >
> --> > 	It is problematic - at best - to attempt to include the
> --> > next layer in the protocol stack in computing alignment, thus
> --> > it is not a good idea to take into account bit-wise alignment
> --> > of the MAC header when determining the "proper" alignment of
> --> > the SHIM, or the "proper" alignment of the next MAC header.
> --> >
> --> > 	Hence, if we want to have a 32-bit aligment of the SHIM
> --> > header, the options are N*32 bits.
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> > --> Sent: Monday, October 16, 2006 6:21 PM
> --> > --> To: Gray, Eric; Caitlin Bestler
> --> > --> Cc: rbridge at postel.org
> --> > --> Subject: RE: [rbridge] FTag
> --> > -->
> --> > -->
> --> > --> IMHO, since the encapsulated frame should be 32 bit
> --> > --> aligned, the size of
> --> > --> this option can be 16+n*32, without counting the Ethertype.
> --> > --> I proposed
> --> > --> n=2, i.e. 80 bits, the only other pragmatic alternative is
> --> > --> n=1, i.e. 48
> --> > --> bits.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> --> > --> > Sent: Monday, October 16, 2006 9:29 AM
> --> > --> > To: Gray, Eric; 'Caitlin Bestler'
> --> > --> > Cc: 'rbridge at postel.org'; Silvano Gai
> --> > --> > Subject: RE: [rbridge] FTag
> --> > --> >
> --> > --> > Oops - "they come in handy 32-bit packages" is the quote
> --> > --> I meant to
> --> > --> > include...
> --> > --> >
> --> > --> > --> -----Original Message-----
> --> > --> > --> From: Gray, Eric
> --> > --> > --> Sent: Monday, October 16, 2006 12:27 PM
> --> > --> > --> To: Caitlin Bestler
> --> > --> > --> Cc: rbridge at postel.org; Silvano Gai
> --> > --> > --> Subject: RE: [rbridge] FTag
> --> > --> > -->
> --> > --> > --> Actually, it is the fact that "they in handy 32-bit
> --> > --> packages" that
> --> > --> > --> should mandate the level of need required to justify
> --> > --> an extra bit.
> --> > --> > -->
> --> > --> > --> If inclusion of an extra bit means including 31
> --> > --> additional bits,
> --> > --> it
> --> > --> > --> should be just a little bit harder to justify the
extra
> --> bit...
> --> > --> > -->
> --> > --> > --> --
> --> > --> > --> Eric
> --> > --> > -->
> --> > --> > --> --> -----Original Message-----
> --> > --> > --> --> From: rbridge-bounces at postel.org
> --> > --> > --> --> [mailto:rbridge-bounces at postel.org] On
> --> Behalf Of Caitlin
> --> > --> Bestler
> --> > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM
> --> > --> > --> --> To: Silvano Gai; rbridge at postel.org
> --> > --> > --> --> Subject: Re: [rbridge] FTag
> --> > --> > --> -->
> --> > --> > --> --> rbridge-bounces at postel.org wrote:
> --> > --> > --> --> > Another important field proposed in:
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > -->
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
> --> > --> > --> --> > cap-00.txt
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> > Is the Ftag (see section 3).
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> > Is there any opposition to add this field?
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> > -- Silvano
> --> > --> > --> -->
> --> > --> > --> --> Despite the description, this is ultimately a
> --> > --> Class of Service
> --> > --> > --> --> field. Class of Service fields are always useful,
> --> > --> the question
> --> > --> > --> --> is whether they are useful enough. Each extra bit
is
> --> > --> > --> less useful,
> --> > --> > --> --> and potentially costs a lot more.
> --> > --> > --> -->
> --> > --> > --> --> To justify increasing the shim header size I
> --> > --> think a scenario
> --> > --> > --> --> that would specifically require the extra
> --> classes would
> --> be
> --> > --> > --> --> useful -- or at least one that exhausts
> --> those available
> --> > --> without
> --> > --> > --> --> the extra field.
> --> > --> > --> -->
> --> > --> > --> --> Philosophically, I take the attitude that
> --> the bandwidth
> --> > --> belongs
> --> > --> > --> --> to the customer. I want a justification for each
> --> > --> and every bit
> --> > --> > --> --> I take out of it (although realistically I know
> --> > --> that they come
> --> > --> > --> --> in handy 32-bit packages).
> --> > --> > --> -->
> --> > --> > --> -->
> --> > --> > --> -->
> --> > --> > --> --> _______________________________________________
> --> > --> > --> --> rbridge mailing list
> --> > --> > --> --> rbridge at postel.org
> --> > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > --> > --> -->
> --> > --> > -->
> --> > -->
> -->