[rbridge] FTag

[Silvano Gai]

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