Subject: [rbridge] FTag

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 16 Oct 2006 19:05:41 -0400

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