[rbridge] FTag

[Gray, Eric]

Radia,

	I believe it is not quite accurate to interpret Caitlin's 
included reply to Silvano as "support for FTag" - but I may be
wrong.  In fact, in qualifying that "support" I would say that
you are offering more support for FTag than Caitlin is.

	I am unsure why the earlier suggestion to use the EXP bits
(analog - since this is technically not exactly an MPLS shim) is
not sufficient.  Do we need more than that?   Why, and for what
potential gain?

	I personally don't see any reason to steal further from the
20-1 bits we currently expect to use to identify either where the
frame came from or where it is going to.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Monday, October 16, 2006 2:10 PM
--> To: Caitlin Bestler
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] FTag
--> 
--> I agree with Caitlin, that FTag is certainly valuable. The 
--> question is 
--> how valuable, and how many bits.
--> In the 4-byte (MPLE-like) shim, the egress/ingress RBridge 
--> nickname is 
--> 19 bits. I suspect 16 bits
--> would suffice, and we could use 3 bits for F-tag. Would 
--> that be enough? 
--> I'd sort of hope so, since
--> 3 bits means 8 forwarding tables, 8 times as many ingress 
--> RBridge trees.
--> 
--> So potentially we could eat 3 bits out of the 
--> label/nickname field and 
--> use that for F-tag.
--> 
--> We haven't discussed the LID fields. Perhaps that should be 
--> a different 
--> thread. Since that doesn't
--> affect forwarding, and is only a convenience to the egress 
--> RBridge, that 
--> doesn't seem too compelling.
--> The ingress RBridge has to do the lookup per endnode, so 
--> it's only at 
--> most twice as much computation
--> for a Designated RBridge to have to do the lookup both when 
--> a packet 
--> leaves its link and when it enters.
--> 
--> Radia
--> 
--> 
--> 
--> Caitlin Bestler wrote:
--> 
--> >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
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->