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.
Caitlin Bestler wrote:
>rbridge-bounces at postel.org wrote:
>>Another important field proposed in:
>>Is the Ftag (see section 3).
>>Is there any opposition to add this field?
>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
More information about the rbridge