[rbridge] FTag

[Silvano Gai]

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