[rbridge] FTag

Radia Perlman Radia.Perlman at sun.com
Mon Oct 16 11:09:58 PDT 2006


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



More information about the rbridge mailing list