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

[Gray, Eric]

Silvano,

	You do not need to send a message to the mailing list
to do this, as this is not currently a WG document and you
are one of its authors.

	If you're asking if the draft would be more acceptable
if this change were made, then that is what you should say.

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> Sent: Tuesday, October 31, 2006 11:02 AM
--> To: Dinesh G Dutt; Radia Perlman
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 
--> I propose that we replace Figure 3 in
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-
--> encap-00.txt
--> 
--> with:
--> 
--> 0xxxxxxxxxxxxxxx	Unicast
--> 100rrrffffffffff	Unicast floooding
--> 101rrrffffffffff	Registered multicast
--> 110rrrffffffffff	Non-registered multicast
--> 111rrrffffffffff	VLAN Broadcast
--> 
--> Where:
--> xxxxxxxxxxxxxxx is the RBridge ID
--> ffffffffff is the FTAG
--> r is reserved
--> 
--> -- Silvano
--> 
--> 
--> 
--> > -----Original Message-----
--> > From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]
--> On
--> > Behalf Of Dinesh G Dutt
--> > Sent: Tuesday, October 31, 2006 7:25 AM
--> > To: Radia Perlman
--> > Cc: rbridge at postel.org
--> > Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> > 
--> > 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
--> > 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
--> > >
--> > >
--> > 
--> > --
--> > We make our world significant by the courage of our 
--> questions and by
--> > the depth of our answers.                               - 
--> Carl Sagan
--> > _______________________________________________
--> > 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
-->