[rbridge] New shim header proposal---without F-tag field
Gray, Eric
Eric.Gray at marconi.com
Tue Oct 31 14:33:00 PST 2006
Donald,
Sorry, I hit "Alt-S" instead of "Ctrl-S".
I was going to finish this by asking how this relates to Radia's
question or Russ' answer, but I was starting to understand and wanted
to think about it some more.
Apparently, what you mean by "this" is Radia's proposal to use
the egress RBridge ID as a "tree selector." That was not obvious -
even with your response - until I was in the process of re-formatting
Radia's original suggestion and found the bit she buried at the end
of one of her paragraphs (the part that basically captures her actual
proposal).
I had read her proposal as a suggested encapsulation without
FTAG as opposed to a way to use something else instead of FTAG.
To your point, then, it would not be optional to support the
use she proposes as it would be necessary to compute trees at each
RBridge hop, corresponding to each alternate path. To do this, an
intermediate RBridge has to be aware that such alternate paths are
possible and what each such alternate path is identified by.
Personally, I think that equal cost multipathing of multicast,
broadcast and flooded frames is inherently dangerous. Of course, we
could look forward to seeing yet another "considered dangerous" RFC
in a year or so... :-)
--
Eric
--> -----Original Message-----
--> From: Gray, Eric
--> Sent: Tuesday, October 31, 2006 5:22 PM
--> To: Eastlake III Donald-LDE008
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] New shim header proposal---without
--> F-tag field
-->
--> Donald,
-->
--> WRT 1)
--> ======
-->
--> With the previous (current?) SHIM, the only RBridge ID in
--> the SHIM would be the ingress RBridge in the multicast, broadcast
--> and flooded (IRT) case. So I don't understand how the "shim
--> 'ingress' and 'egress' rbridges are the same" in this case.
-->
--> Even in the new (proposed?) SHIM, only the ingress RBridge
--> ID is meaningful until - at best - you get to a point where the
--> specific egress for an IRT is unambiguous. Note that this may
--> not occur even at the egress RBridge's penultimate hop (if - for
--> example - the penultimate hop is connected to more than one such
--> egress by a shared Ethernet segment). Consequently, the field
--> intended for egress RBridge may not - in the IRT case - have any
--> meaningful value in it at any point in the CRED.
-->
--> WRT 2) and 3)
--> =============
-->
--> Any ingress RBridge is necessarily on the IRT for an egress
--> to which it is expected to deliver multicast, broadcast or flooded
--> frames. It is an "Ingress" RBridge Tree precisely because each of
--> these is rooted at an ingress, and there is at least one for every
--> ingress RBridge providing a delivery path for all egresses - with
--> the qualification that some egress RBridges may be pruned as early
--> as at the ingress, if the two are not connecting any common VLAN
--> including the default (or null) VLAN.
-->
--> Over-all
--> ========
-->
--> How does this relate to the
-->
--> --> -----Original Message-----
--> --> From: Eastlake III Donald-LDE008
--> --> [mailto:Donald.Eastlake at motorola.com]
--> --> Sent: Tuesday, October 31, 2006 2:36 PM
--> --> To: Gray, Eric; rbridge at postel.org
--> --> Subject: RE: [rbridge] New shim header proposal---without
--> --> F-tag field
--> -->
--> --> Being able to send the frame on the (pruned) ingress
--> rbridge tree
--> --> determined by the "egress" rbridge field of the shim
--> header for a
--> --> multicast frame, rather than the "ingress" rbridge field of
--> --> that shim
--> --> header.
--> -->
--> --> I suppose there are actually three cases for multicast frames:
--> -->
--> --> 1) The shim ingress and "egress" rbridges are the same.
--> --> This is the same
--> --> case as the current specification.
--> -->
--> --> 2) They are different but the ingress rbridge, which
--> constructs this
--> --> encapsulation, is on the IRT of the selected "egress"
--> (actually IRT
--> --> root) rbridge. Seems like you just need to add the
--> usual bridge logic
--> --> to distinguish frames heading towards/away from the root.
--> -->
--> --> 3) I'm not sure if this case is needed but you could
--> have a case where
--> --> the ingress rbridge which constructs the encapsulation
--> is not on the
--> --> IRT for the designated "egress" rbridge. If this case
--> can occur, while
--> --> I could imagine much more complex and optimal things to
--> do, it seems
--> --> adequate to just use the "unicast" forwarding towards
--> the "egress"
--> --> rbridge until you first hit an rbridge which is on the
--> IRT rooted at
--> --> the "egress" rbridge at which point the case 2 logic
--> can take over.
--> -->
--> --> Donald
--> -->
--> --> -----Original Message-----
--> --> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> --> Sent: Tuesday, October 31, 2006 2:21 PM
--> --> To: Eastlake III Donald-LDE008; rbridge at postel.org
--> --> Subject: RE: [rbridge] New shim header proposal---without
--> --> F-tag field
--> -->
--> --> 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/
--> --> --> > 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
--> --> -->
--> -->
-->
More information about the rbridge
mailing list