Subject: [rbridge] FTag

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 15 Oct 2006 18:20:56 -0700

Another important field proposed in:

http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt

Is the Ftag (see section 3).

Is there any opposition to add this field?

-- Silvano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061015/2ffca1b6/attachment.html

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 16 Oct 2006 09:09:13 -0700

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 16 Oct 2006 09:59:36 -0700

Caitlin Bestler wrote:...
> in handy 32-bit packages).

And it's nice to have room for expansion, i.e., unused bits.

IMO, we're either trying to support routed ethernet or routed IP; if the
former, there's no point in anything other than the TTL field beyond the
destination address. If the latter, then let's put in a full IPv6 header
- with options and run IP on the nodes - i.e., just use IP.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061016/9cf520f2/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 16 Oct 2006 11:09:58 -0700

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 mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 18 Oct 2006 11:06:08 -0700

> leaves its link and when it enters.

If we are trying to squeeze bits and see a need for a LID capability, it 
might make sense to allow different egress rbridges have different 
number of LID bits - they only need to number their ports so in some 
cases few bits would be sufficient.

Assuming we have a 19 bit space for RBridge alias plus LID, then an 
rbridge with 16 ports would ask for an alias that is 19-4=15 bits.

The downside of such an approach is that the alias setup would need to 
be able to handle variable length aliases, and the transit rbridges 
would either need variable length matching on the RBridge alias, or 
expand out to all the matching 19 bit patterns and have the hardware do 
full 19 bit matches. For instance, the above 15 bit alias would expand 
to 16 different matches on 19 bits.

    Erik

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 18 Oct 2006 13:19:17 -0700

Erik Nordmark wrote:
> Radia Perlman wrote:
> 
>> 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.
>> 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.
> 
> If we are trying to squeeze bits and see a need for a LID
> capability, it might make sense to allow different egress
> rbridges have different number of LID bits - they only need
> to number their ports so in some cases few bits would be sufficient.
> 
> Assuming we have a 19 bit space for RBridge alias plus LID,
> then an rbridge with 16 ports would ask for an alias that is 19-4=15
> bits. 
> 
> The downside of such an approach is that the alias setup
> would need to be able to handle variable length aliases, and
> the transit rbridges would either need variable length
> matching on the RBridge alias, or expand out to all the
> matching 19 bit patterns and have the hardware do full 19 bit
> matches. For instance, the above 15 bit alias would expand to
> 16 different matches on 19 bits.
> 
>     Erik

Bitmask aliasing an RBridge ID has the same potential uses as
LID aliasing for InfiniBand, and the same complexities.

My generate comment on the LID is that it is only worth considering
if it can be multiplexed with the RBridge ID. Otherwise you are
replacing an egress RBridge table [local mac-->local port] by
having having more data in the ingress RBridge table
[remote mac-->remote rbridge + LID]. I'm not certain
that it really reduces the amount of memory, and given
the likely size of the [local mac-->local port] table
I don't think it improves latency.