Subject: [rbridge] New shim header proposal---without F-tag field

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 30 Oct 2006 18:49:52 -0800

After talking to Silvano and Dinesh to get them to explain to me why
the use of F-tag didn't multiply the number of trees that RBridges
needed to compute by the number of F-tag values, they were able to
explain to me why they wanted the F-tag. Here is a proposal to
get the functionality they want without the use of F-tag.

***********************

Motivation for F-tag

They want to be able to do multipathing on multicast. We can already
do multipathing on unicast by having an RBridge keep multiple equal
cost (or near equal cost) paths to destination D, and split traffic
however it wants. But if we have a single tree for all multicast
with ingress RBridge R1, then all multicast traffic has to use
the same links. The original proposal was to use F-tag as a selector
for a tree. But the modified proposal is to use the "egress RBridge"
field, which wasn't all that useful for multicast, as a "tree selector".

******************************

So the proposal is:

In the shim header will only be:
1) 16-bit ingress RBridge
2) 16-bit egress RBridge
3) TTL

How these fields will be used in order to do multipathing:

a) RBridges calculate a single tree for each ingress RBridge

b) For unicast, an RBridge can calculate multiple equal-cost
paths to the destination (or near-equal cost), and split traffic. That 
is how
we'd get multipathing for unicast. If S7 has two ways to get to 
destination D,
it can send some of its traffic one way, some of it the other. This is 
solely
S7's choice and doesn't need to be coordinated with any other switches.

c) For multicast, we can provide multipathing by letting the ingress RBridge
choose the distribution tree.
The tree used will be indicated by the "egress RBridge"
field. So, if S3 receives a multicast packet from an endnode, it puts
"S3" as "ingress RBridge", but selects a tree by whatever means it
wants, and puts, say, "S1" into "egress RBridge". That way the packet
will be forwarded based on the tree calculated using S1 as the root.

With this proposal, we get multipathing for multicast without configuration.
The same space used for RBridge nicknames can be used for choosing the
tree for multicast packets. The number of trees to be calculated does
not change---it is still per ingress RBridge.

Radia

---

From: riw at cisco.com (Russ White)
Date: Tue, 31 Oct 2006 09:18:46 -0500

This sounds fine to me, as it also means that implementations that don't
want to support this won't suffer from the additional space and work
involved in the F-Tag. My primary question would be--what will happen if
two implementations, one supporting, the other not, are used in the same
network?

:-)

Russ

Radia Perlman wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 31 Oct 2006 07:22:52 -0800

I'm fine with this proposal, Radia. Thanks for working through this,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 31 Oct 2006 07:25:03 -0800

I hit "send" too soon. We talked about an additional bit in the header 
to identify a multicast frame. Did you see no need for that ?

Dinesh

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 31 Oct 2006 10:05:57 -0800

No. I just forgot that bit.

So, we need
a) ingress RBridge
b) egress RBridge
(where both above fields are the same size)
c) TTL (6 bits ought to be enough)
d) multicast flag (just a single bit)

Anything else?

Radia

Dinesh G Dutt wrote:

>> paths to the destination (or near-equal cost), and split traffic. 
>> That is how
>> it can send some of its traffic one way, some of it the other. This 
>> is solely

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 31 Oct 2006 14:02:31 -0500

Speaking as a WG member: Since rbridges need to be able to compute an
ingress rbridge based tree for various other rbridges, it seems to me
that very little additional logic is needed to support this.
Implementation would be relatively easy and would have to be mandatory
to assure proper frame delivery. If it was optional, you have different
nodes using different trees and it is trivial to come up with cases
where a frame is delivered zero times or twice when it should be
delivered once. Depending on implementation, it is also possible to
create permanent loops if this is optional.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Russ White
Sent: Tuesday, October 31, 2006 9:19 AM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] New shim header proposal---without F-tag field

:-)

Russ

Radia Perlman wrote:
> explain to me why they wanted the F-tag. Here is a proposal to get the

> functionality they want without the use of F-tag.
> 
> ***********************
> 
> Motivation for F-tag
> 
> however it wants. But if we have a single tree for all multicast with 
> ingress RBridge R1, then all multicast traffic has to use the same 
> links. The original proposal was to use F-tag as a selector for a 
> tree. But the modified proposal is to use the "egress RBridge"
> b) For unicast, an RBridge can calculate multiple equal-cost paths to 
> the destination (or near-equal cost), and split traffic. That is how 
> destination D, it can send some of its traffic one way, some of it the

> other. This is solely S7's choice and doesn't need to be coordinated 
> with any other switches.
> 
> c) For multicast, we can provide multipathing by letting the ingress 
> RBridge choose the distribution tree.