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

[Gray, Eric]

Donald,

	Sorry, I am confused by your response: when you say "very little
additional logic is required to support this" - what is "this"...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Tuesday, October 31, 2006 2:03 PM
--> To: rbridge at postel.org
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 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
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->