Subject: [rbridge] FTag

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 16 Oct 2006 12:27:06 -0400

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