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

[Gray, Eric]

Radia,

	I don't think there is consensus yet that we only need 16 bits
for RBridge IDs.

	I personally disagree with the part of the proposal below that
builds in the assumption that 16 bits is sufficient.

	My reasoning is that 16 bits may not be large enough if the
future where some implementations may use more than one RBridge ID
for the same device.  Some reasons for doing this are to support per
interface (or per VLAN) IF-IF instances.

	16 bits may get used up much more rapidly than you think if 
implementations are not explicitly forbidden to do this (which is 
not a good idea, given that there is very little that can be done
to enforce such a prohibition - beyond deliberately choosing to use
an "ID-space" too small to accommodate it).

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Monday, October 30, 2006 9:50 PM
--> To: rbridge at postel.org
--> Subject: [rbridge] New shim header proposal---without F-tag field
--> 
--> 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
-->