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

[Eastlake III Donald-LDE008]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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:
> 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
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFR1tGER27sUhU9OQRApFbAKCeoYIxA/FpF2hCXNwmE+1m42twsQCfWDXy
75f9f5LHU5Pacuh2vwdIK3c=
=4sIq
-----END PGP SIGNATURE-----
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge