From touch at ISI.EDU Tue Apr 1 07:50:16 2008 From: touch at ISI.EDU (Joe Touch) Date: Tue, 01 Apr 2008 07:50:16 -0700 Subject: [rbridge] VLAN registration In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77034D336B@nekter> References: <47E12312.7090304@sun.com><3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com><47E1AB61.5050101@cisco.com><3870C46029D1F945B1472F170D2D979003A9521D@de01exm64.ds.mot.com> <47F06900.4050906@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77034D336B@nekter> Message-ID: <47F24BA8.5010508@isi.edu> Caitlin Bestler wrote: > > Dinesh Dutt wrote: >> Donald, >> >> Next, are we going to specify what an Rbridge does for every single >> IEEE >> protocol ? I don't think so. ... >> I'd like to draw a clean demarcation of Rbridge functionality from > IEEE >> bridge functionality. ... > I agree with this approach. > > I suspect this boils down to where we think an RBridge fits in 802's > hierarchy. ... > > 802.1 has trouble keeping track of 802.1 projects. We don't want to go > there. > > A more stable approach is to view RBridge as a *consumer* of 802.1 > services. This is why I wanted (and still want) to define a campus as emulating a single ethernet switch - where the IEEE defines that device, not us. That then defines all other behaviors as a derivative of that approach. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080401/7ed84c54/signature.bin From anoop at brocade.com Tue Apr 1 11:38:41 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 1 Apr 2008 11:38:41 -0700 Subject: [rbridge] FW: VLAN registration Message-ID: <4C94DE2070B172459E4F1EE14BD2364E01252209@HQ-EXCH-5.corp.brocade.com> (Due to some problems with my outgoing email address, some of my messages didn't make it to the list. I am forwarding all of them. Those on the "to" list will probably see a duplicate.) > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake at motorola.com] > Sent: Sunday, March 30, 2008 11:53 AM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] VLAN registration > > Hi Anoop, > > So what should an Rbridge which does not support MVRP do when > it receives an MVRP frame? (I assume you are not just > supporting the older GVRP over MVRP so what you are really > saying is that an Rbridge does not need to provide any real > support for dynamic VLAN registration.) > > Under such circumstances, there are various possibilities: > > Just discarding the frame doesn't seem very friendly and > certainly won't work if you have bridges in the path that > have dynamic VLAN configuration. > > Distributing as a non-IP-derived multicast, which is what the > -06 draft provided, seems pretty flakey. It might work > sometimes, depending on exactly port configurations, but > would commonly fail because the VLAN registration frame > wouldn't get to where it was needed or, if it did, it would > be VLAN tagged in violation of 802.1Q. > > You could also special case it as a non-VLAN constrained > frame which is never VLAN-tagged when decapsulated... I think the right way for RBridges to participate in MVRP is as an endstation. This means that when they receive an MRPDU, they create a registration on the link; that registration then propagates via IS-IS to all of the other RBridges marked as such. Those RBridges then originate the MRPDU on the LANs that they are connected to. The other option would be to do what you mention in your last point, but I'm not sure if that will work for actually registering VLAN membership at that RBridge. Anoop From anoop at brocade.com Tue Apr 1 11:39:28 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 1 Apr 2008 11:39:28 -0700 Subject: [rbridge] FW: (slight) modification of how to choose mulitcast trees Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0125220B@HQ-EXCH-5.corp.brocade.com> (Resent message.) This looks like a reasonable approach. I have the following comments to add: - Do we want to restrict traffic from certain VLANs to certain trees? If so, then the Rbridge that decides the number of trees would also decide the mapping of VLAN to tree. I would actually prefer this option, but I'd like to hear opinions on this. - Do we care about path congruency -- i.e. when a MAC DA is unknown and it is sent over a multicast tree, and later it becomes known, do we want the unicast path to be along the branch of the multicast tree? This would be essential for maintaining ordering. My personal opinion is that this becomes an implementation choice, but in the presence of multipathing it is not possible given the current RBridge specification (because it would require the computation of more than one tree, one each that included each ECMP path to the destination). Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Friday, March 28, 2008 7:55 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] (slight) modification of how to choose > mulitcast trees > > Dinesh suggested the following, as a way of making > configuration easier for how to choose multicast trees. > > 1) Each RBridge is configured with a priority for being > selected a multicast tree root (with of course a default > being a medium priority) > > 2) Each RBridge R1 s also configured with a parameter > indicating "total number of trees in the campus", which R1 > announces in its LSP > > 3) RBridges are ranked by (priority, ID). The RBridge with > the numerically lowest priority, and then numerically lowest > ID being the tie breaker, dictates the total number of trees > all the other RBridges must calculate (the number that R1 > announces in its LSP according to rule 2 above. > > 4) An RBridge calculates n distribution trees, where n is the > number announced by the lowest (priority, ID) RBridge R1, in > R1's LSP, as the "total number of trees". The n trees > computed are the ones using the n numerically lowest > (priority, ID) RBridges as roots > > 5) if RB1 is ingress RBridge on port p, and (*note another parameter > "k"*) is configured to do k-way path splitting on that port > for multidestination frames, the k tree roots that RB1 > chooses consist of the three for which the triple "(cost of > root to me, priority, ID)" are the k smallest. > > Intuition: suppose there is a topology with a lot of "leaf" > RBridges., and "next level" RBridges that the leaf RBridges > connect to. > If there are m leaf RBridges connected to next level RBridge > RBx, then there is no reason to compute trees with any of the > leaf RBridges as root -- the tree rooted at RBx will be the > same tree, and will indeed be a shortest path tree for each > of the attached leaf RBridges. If a leaf RBridge is attached > to several next-level RBridges, the most significant number > in the triple -- "cost of root to me" will cause the leaf > RBridge to multipath the multicast among multiple shortest-path trees. > > This seems completely safe, and easier than configuring, for > each RBridge, the set of root RBridges to choose for > multicast tree roots. > It also means that you can configure in one place a total > number of roots, rather than possibly having too many > RBridges volunteer for being tree roots, and winding up with > too much overhead on RBridges because they'll have to compute > a tree for every RBridge that says it will want to be a tree root. > > There might be a concern about volatility -- when an RBridge > with numerically low priority goes down, it might cause: > a) a change to the total number of trees to be computed by > everyone (since the next best might be configured with a > different number) > b) a change to the list of "tree roots I will choose" > announced by RB2 when one of the roots for the k best (cost > to me, priority, ID) goes down. > > Other than that, I can't think of any possible problems. > > Radia > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Tue Apr 1 11:41:21 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 1 Apr 2008 11:41:21 -0700 Subject: [rbridge] FW: Proposed replacement for a paragraph in section 2.3 ofdraft-ietf-trill-rbridge-protocol-07 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0125220E@HQ-EXCH-5.corp.brocade.com> (Resent message.) I have a few clarifications about this proposal. See below. > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Claudio DeSanti > Sent: Monday, March 10, 2008 7:19 AM > To: Rbridge at postel.org > Subject: [rbridge] Proposed replacement for a paragraph in > section 2.3 ofdraft-ietf-trill-rbridge-protocol-07 > > Hi all, > > as just presented, this is a proposed clarification for an > existing paragraph in section 2.3 of the base protocol spec. > Thanks, > > Claudio. > > ------- > > > Existing paragraph: > > By default, RBridges tag IS-IS Hellos with VLAN 1. However, an > RBridge MAY be configured to transmit Hellos on a set of VLANs, and > if elected DRB, to designate to the other RBridges on the > link which > VLAN to tag Hellos with. Once the DRB, say RB1, is elected, and > specifies the designated VLAN, say VLAN-x, on which to send Hellos, > (1) all RBridges on the link, except the DRB, transmit > Hellos tagged > only with VLAN-x, (2) all RBridge-RBridge communication (including > Hellos, forwarded data packets, and LSPs) are tagged with > VLAN-x, and > (3) the DRB only lists, in its Hello, and in the > pseudonode LSP, the > set of RBridges from which the DRB hears VLAN-V tagged packets. > > > Proposed replacement: > > > An RBridge maintains per each port the following parameters: > a) Announcing VLANs set: the set of VLANs where an RBridge > port announces IS-IS Hellos on a link; > b) Designated VLAN: the VLAN used by an RBridge port to > communicate with other RBridge ports on a link; and > c) Forwarding VLANs set: the set of VLANs for which an > RBridge port is appointed VLAN forwarder on a link. > > By default the Announcing VLANs set contains all the VLANs > active on the port, however it may be configured to contain a > subset of them. What is the set of active VLANs? If Ingress VLAN filtering is not enabled is this all the 4094 VLANs? > When a port of an RBridge becomes operational, the RBridge > MUST transmit IS-IS Hellos on each VLAN of the Announcing > VLANs set of that port. Because of the above 4094 number, I would be opposed to having this as a MUST. In addition, it should be clearly specified that the purpose of these hellos is only for connectivity/misconfiguration detection. In other words, there is no IS-IS adjacency established, and it should be possible to operate with just a single VLAN hello if one chooses to not use this mechanism for connectivity/misconfiguration detection. > If the RBridge is elected DRB for the link to which that port > is connected, the RBridge MUST: > a) continue to send IS-IS Hellos per each VLAN of the > Announcing VLANs set of that port; > b) designate the Designated VLAN to be used to communicate > with the other RBridges connected to that link; and > c) establish the Forwarding VLANs set per each RBridge > connected to that link, including itself. > > If the RBridge is not elected DRB for the link to which that > port is connected and its Forwarding VLANs set is not empty, > the RBridge MUST: > a) learn from the DRB the Designated VLAN on that link; > b) act as a VLAN forwarder for the VLANs included in its > Forwarding VLANs set; and > c) transmit IS-IS Hellos messages only on the Designated VLAN > and on the VLANs of its Forwarding VLANs set. > > If the RBridge is not elected DRB for the link to which that > port is connected and its Forwarding VLANS set is empty, the > RBridge MUST: > a) learn from the DRB the Designated VLAN on that link; and > b) transmit IS-IS Hellos messages only on the Designated VLAN. BTW, in the meeting Silvano had mentioned that it is never possible to configure an 802.1 network such that spanning tree will not take care of loops. This is incorrect. In cases where the PVIDs are different on both ends of the link, it is actually possible to have a persistent loop when using MSTP. In 802.1ah (provider backbone bridging) they also have the same problem of loops that we have here. They solve that problem using an enhancement to STP, called the Layer 2 gateway protocol, but it doesn't look like it's well enough defined in the text. I would have to look at the STP state machines to understand its operation. The point is, we need to be reasonable about the overhead imposed for detecting connectivity problems and misconfiguration. Anoop From ddutt at cisco.com Tue Apr 1 18:43:04 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 01 Apr 2008 18:43:04 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47EFD523.4000303@sun.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> Message-ID: <47F2E4A8.7010200@cisco.com> I agree with you Radia on both points, Dinesh Radia Perlman wrote: > My only 2 comments on your comments: > a) I don't see how there can be a default of square root of number of > RBridges, since RBridges wouldn't know the number > of bridges. I'd say we should pick a number like "10". > b) Sorry -- need to "think aloud" here for a bit. > A few questions about "order": "ports" is known in advance and doesn't > change. "adjacencies" is not known in advance . > But then you really want "RBridge adjacencies" and not just ports to > endnodes...so I'm not sure. Maybe > it has to be "RBridge adjacencies". But does having a fluctuating > "order" cause problems? In theory we might want a pseudonode > to be a tree root, but pseudonodes don't get nicknames, and therefore > can't be specified as a tree root in the TRILL header. > > And then using numerically largest works for "order" but not for > "distance to me", so that has to be adjusted (shouldn't be hard, perhaps > making "order" be 1000 minus the number of RBridge adjacencies, going no > lower than "0"). And "order" can be calculated from > the LSP -- it doesn't have to be separately announced. Though if you are > connected to a pseudonode do you have to remember > to count all the RBridges connected to that pseudonode? > > It might be simpler to just have "order" feed into priority, as in, if > your priority is not configured in advance, then if you have more > than some number (say 2) RBridge adjacencies, you decrement your > priority by 1 for every extra RBridge adjacency. If your > priority is configured, you'd leave it at whatever it is configured to be. > > Radia > > > > > Eastlake III Donald-LDE008 wrote: > >> Hi, >> >> I agree that the present requirement that all Rbridges default to having >> the RequestTree be TRUE probably results in Rbridges being required to >> calculate too many trees in a large campus. See comments below at @@@ >> >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On >> Behalf Of Radia Perlman >> Sent: Friday, March 28, 2008 10:55 PM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] (slight) modification of how to choose mulitcast >> trees >> >> Dinesh suggested the following, as a way of making configuration easier >> for how to choose multicast trees. >> >> 1) Each RBridge is configured with a priority for being selected a >> multicast tree root (with of course a default being a medium priority) >> >> 2) Each RBridge R1 is also configured with a parameter indicating "total >> >> number of trees in the campus", which R1 announces in its LSP. >> >> @@@ So what's the recommended default here? It might sound a bit odd but >> I would suggest that the default be something like the square root of >> the number of Rbridges in the campus. (See comment below on volatility.) >> >> 3) RBridges are ranked by (priority, ID). The RBridge with the >> numerically lowest priority, and then numerically lowest ID being the >> tie breaker, dictates the total number of trees all the other RBridges >> must calculate (the number that R1 announces in its LSP according >> to rule 2 above. >> >> @@@ As long as you are generating a concatenated global priority number >> like (priority, ID), why not make it a little more clever by having it >> be (priority, order, ID) or something like that? (Where "order" is the >> number of adjacencies the Rbridge has, so you'd have to change the >> ranking to be highest priority is numerically largest...). >> >> 4) An RBridge calculates n distribution trees, where n is the number >> announced by the lowest (priority, ID) RBridge R1, in R1's LSP, >> as the "total number of trees". The n trees computed are the ones using >> the n numerically lowest (priority, ID) RBridges as roots >> >> 5) if RB1 is ingress RBridge on port p, and (*note another parameter >> "k"*) is configured to do k-way path splitting on that port for >> multidestination frames, the k tree roots that RB1 chooses consist of >> the three for which the triple "(cost of root to me, priority, ID)" are >> the k smallest. >> >> @@@ Of course the ranking has to be the same so if "order" were added as >> above, it would have to be added here also. >> >> Intuition: suppose there is a topology with a lot of "leaf" RBridges., >> and "next level" RBridges that the leaf RBridges connect to. >> If there are m leaf RBridges connected to next level RBridge RBx, then >> there is no reason to compute trees with any of the leaf >> RBridges as root -- the tree rooted at RBx will be the same tree, and >> will indeed be a shortest path tree for each of the attached >> leaf RBridges. If a leaf RBridge is attached to several next-level >> RBridges, the most significant number in the triple -- "cost >> of root to me" will cause the leaf RBridge to multipath the multicast >> among multiple shortest-path trees. >> >> @@@ That's all true but the special case of an Rbridge of order 1 >> connected to an Rbridge of order >1 seems so simple to check for that >> you could just rule them out. Or, if "order" were added to the >> comparison tuple as above, in the default case where all Rbridges have >> the default priority, order 1 Rbridges would automatically have lowest >> priority. (See also slides 8 and 9 of my presentation at >> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >> >> This seems completely safe, and easier than configuring, for each >> RBridge, the set of root RBridges to choose for multicast tree roots. >> It also means that you can configure in one place a total number of >> roots, rather than possibly having too many RBridges volunteer for >> being tree roots, and winding up with too much overhead on RBridges >> because they'll have to compute a tree for every RBridge that >> says it will want to be a tree root. >> >> There might be a concern about volatility -- when an RBridge with >> numerically low priority goes down, it might cause: >> a) a change to the total number of trees to be computed by everyone >> (since the next best might be configured with a different number) >> b) a change to the list of "tree roots I will choose" announced by RB2 >> when one of the roots for the k best (cost to me, priority, ID) goes >> down. >> >> @@@ There are plenty of other possible causes for volatility. Like a >> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >> priority-to-be-tree-root being reconfigured. But the solution to them >> all is the same. An Rbridge has to keep calculating (or at least keep >> around) trees for old roots as long as their reasonably might be frames >> in transit specifying those roots. It has to calculate trees for any new >> roots right away and, if appropriate, start advertising that it might >> use them. What root (or from what set of roots) to choose for new native >> multi-destination frames an Rbridge is encapsulating is a bit messier. >> Seems to me that until it is reasonably sure that information has >> propagated concerning new roots, it should only use those in the >> intersection of the sets of old and new roots. If that intersection is >> null, something only likely to occur when there are a very small number >> of tree roots, you have a bit of a problem and might as well use the new >> root(s). But this is no worse than under the previous scheme if >> RequestTree was FALSE for all Rbridges and the Rbridge with the lowest >> system ID, which had defaulted to being the only tree root, goes down. >> >> Other than that, I can't think of any possible problems. >> >> @@@ Overall, I like the proposal. >> >> Radia >> >> @@@ Thanks, >> @@@ Donald >> >> _______________________________________________ >> 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 > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From ddutt at cisco.com Tue Apr 1 18:48:20 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 01 Apr 2008 18:48:20 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47EFD523.4000303@sun.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> Message-ID: <47F2E5E4.1020402@cisco.com> Slight modification. I'd want the default to be smaller, say 2 or 4. But I won't quibble, Dinesh Radia Perlman wrote: > My only 2 comments on your comments: > a) I don't see how there can be a default of square root of number of > RBridges, since RBridges wouldn't know the number > of bridges. I'd say we should pick a number like "10". > b) Sorry -- need to "think aloud" here for a bit. > A few questions about "order": "ports" is known in advance and doesn't > change. "adjacencies" is not known in advance . > But then you really want "RBridge adjacencies" and not just ports to > endnodes...so I'm not sure. Maybe > it has to be "RBridge adjacencies". But does having a fluctuating > "order" cause problems? In theory we might want a pseudonode > to be a tree root, but pseudonodes don't get nicknames, and therefore > can't be specified as a tree root in the TRILL header. > > And then using numerically largest works for "order" but not for > "distance to me", so that has to be adjusted (shouldn't be hard, perhaps > making "order" be 1000 minus the number of RBridge adjacencies, going no > lower than "0"). And "order" can be calculated from > the LSP -- it doesn't have to be separately announced. Though if you are > connected to a pseudonode do you have to remember > to count all the RBridges connected to that pseudonode? > > It might be simpler to just have "order" feed into priority, as in, if > your priority is not configured in advance, then if you have more > than some number (say 2) RBridge adjacencies, you decrement your > priority by 1 for every extra RBridge adjacency. If your > priority is configured, you'd leave it at whatever it is configured to be. > > Radia > > > > > Eastlake III Donald-LDE008 wrote: > >> Hi, >> >> I agree that the present requirement that all Rbridges default to having >> the RequestTree be TRUE probably results in Rbridges being required to >> calculate too many trees in a large campus. See comments below at @@@ >> >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On >> Behalf Of Radia Perlman >> Sent: Friday, March 28, 2008 10:55 PM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] (slight) modification of how to choose mulitcast >> trees >> >> Dinesh suggested the following, as a way of making configuration easier >> for how to choose multicast trees. >> >> 1) Each RBridge is configured with a priority for being selected a >> multicast tree root (with of course a default being a medium priority) >> >> 2) Each RBridge R1 is also configured with a parameter indicating "total >> >> number of trees in the campus", which R1 announces in its LSP. >> >> @@@ So what's the recommended default here? It might sound a bit odd but >> I would suggest that the default be something like the square root of >> the number of Rbridges in the campus. (See comment below on volatility.) >> >> 3) RBridges are ranked by (priority, ID). The RBridge with the >> numerically lowest priority, and then numerically lowest ID being the >> tie breaker, dictates the total number of trees all the other RBridges >> must calculate (the number that R1 announces in its LSP according >> to rule 2 above. >> >> @@@ As long as you are generating a concatenated global priority number >> like (priority, ID), why not make it a little more clever by having it >> be (priority, order, ID) or something like that? (Where "order" is the >> number of adjacencies the Rbridge has, so you'd have to change the >> ranking to be highest priority is numerically largest...). >> >> 4) An RBridge calculates n distribution trees, where n is the number >> announced by the lowest (priority, ID) RBridge R1, in R1's LSP, >> as the "total number of trees". The n trees computed are the ones using >> the n numerically lowest (priority, ID) RBridges as roots >> >> 5) if RB1 is ingress RBridge on port p, and (*note another parameter >> "k"*) is configured to do k-way path splitting on that port for >> multidestination frames, the k tree roots that RB1 chooses consist of >> the three for which the triple "(cost of root to me, priority, ID)" are >> the k smallest. >> >> @@@ Of course the ranking has to be the same so if "order" were added as >> above, it would have to be added here also. >> >> Intuition: suppose there is a topology with a lot of "leaf" RBridges., >> and "next level" RBridges that the leaf RBridges connect to. >> If there are m leaf RBridges connected to next level RBridge RBx, then >> there is no reason to compute trees with any of the leaf >> RBridges as root -- the tree rooted at RBx will be the same tree, and >> will indeed be a shortest path tree for each of the attached >> leaf RBridges. If a leaf RBridge is attached to several next-level >> RBridges, the most significant number in the triple -- "cost >> of root to me" will cause the leaf RBridge to multipath the multicast >> among multiple shortest-path trees. >> >> @@@ That's all true but the special case of an Rbridge of order 1 >> connected to an Rbridge of order >1 seems so simple to check for that >> you could just rule them out. Or, if "order" were added to the >> comparison tuple as above, in the default case where all Rbridges have >> the default priority, order 1 Rbridges would automatically have lowest >> priority. (See also slides 8 and 9 of my presentation at >> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >> >> This seems completely safe, and easier than configuring, for each >> RBridge, the set of root RBridges to choose for multicast tree roots. >> It also means that you can configure in one place a total number of >> roots, rather than possibly having too many RBridges volunteer for >> being tree roots, and winding up with too much overhead on RBridges >> because they'll have to compute a tree for every RBridge that >> says it will want to be a tree root. >> >> There might be a concern about volatility -- when an RBridge with >> numerically low priority goes down, it might cause: >> a) a change to the total number of trees to be computed by everyone >> (since the next best might be configured with a different number) >> b) a change to the list of "tree roots I will choose" announced by RB2 >> when one of the roots for the k best (cost to me, priority, ID) goes >> down. >> >> @@@ There are plenty of other possible causes for volatility. Like a >> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >> priority-to-be-tree-root being reconfigured. But the solution to them >> all is the same. An Rbridge has to keep calculating (or at least keep >> around) trees for old roots as long as their reasonably might be frames >> in transit specifying those roots. It has to calculate trees for any new >> roots right away and, if appropriate, start advertising that it might >> use them. What root (or from what set of roots) to choose for new native >> multi-destination frames an Rbridge is encapsulating is a bit messier. >> Seems to me that until it is reasonably sure that information has >> propagated concerning new roots, it should only use those in the >> intersection of the sets of old and new roots. If that intersection is >> null, something only likely to occur when there are a very small number >> of tree roots, you have a bit of a problem and might as well use the new >> root(s). But this is no worse than under the previous scheme if >> RequestTree was FALSE for all Rbridges and the Rbridge with the lowest >> system ID, which had defaulted to being the only tree root, goes down. >> >> Other than that, I can't think of any possible problems. >> >> @@@ Overall, I like the proposal. >> >> Radia >> >> @@@ Thanks, >> @@@ Donald >> >> _______________________________________________ >> 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 > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Donald.Eastlake at motorola.com Tue Apr 1 21:11:39 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 2 Apr 2008 00:11:39 -0400 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47F2E4A8.7010200@cisco.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> Hi, See below at @@@ -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Tuesday, April 01, 2008 To: Radia Perlman Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. Subject: Re: [rbridge] (slight) modification of how to choose mulitcast trees Slight modification. I'd want the default to be smaller, say 2 or 4. But I won't quibble, Dinesh I agree with you Radia on both points, Dinesh Radia Perlman wrote: > My only 2 comments on your comments: > a) I don't see how there can be a default of square root of number of > RBridges, since RBridges wouldn't know the number > of bridges. I'd say we should pick a number like "10". @@@ OK, so let's go with a recommended default of 8. > b) Sorry -- need to "think aloud" here for a bit. > A few questions about "order": "ports" is known in advance and doesn't > change. "adjacencies" is not known in advance . > But then you really want "RBridge adjacencies" and not just ports to > endnodes...so I'm not sure. Maybe > it has to be "RBridge adjacencies". But does having a fluctuating > "order" cause problems? In theory we might want a pseudonode > to be a tree root, but pseudonodes don't get nicknames, and therefore > can't be specified as a tree root in the TRILL header. > > And then using numerically largest works for "order" but not for > "distance to me", so that has to be adjusted (shouldn't be hard, perhaps > making "order" be 1000 minus the number of RBridge adjacencies, going no > lower than "0"). And "order" can be calculated from > the LSP -- it doesn't have to be separately announced. Though if you are > connected to a pseudonode do you have to remember > to count all the RBridges connected to that pseudonode? > > It might be simpler to just have "order" feed into priority, as in, if > your priority is not configured in advance, then if you have more > than some number (say 2) RBridge adjacencies, you decrement your > priority by 1 for every extra RBridge adjacency. If your > priority is configured, you'd leave it at whatever it is configured to be. @@@ I'm fine with order feeding into priority in some fashion if your priority is not configured. People who are configuring ought to know what they are doing and avoid ties. @@@ Thanks, @@@ Donald > Radia > > > > > Eastlake III Donald-LDE008 wrote: > >> Hi, >> >> I agree that the present requirement that all Rbridges default to having >> the RequestTree be TRUE probably results in Rbridges being required to >> calculate too many trees in a large campus. See comments below at @@@ >> >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On >> Behalf Of Radia Perlman >> Sent: Friday, March 28, 2008 10:55 PM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] (slight) modification of how to choose mulitcast >> trees >> >> Dinesh suggested the following, as a way of making configuration easier >> for how to choose multicast trees. >> >> 1) Each RBridge is configured with a priority for being selected a >> multicast tree root (with of course a default being a medium priority) >> >> 2) Each RBridge R1 is also configured with a parameter indicating "total >> >> number of trees in the campus", which R1 announces in its LSP. >> >> @@@ So what's the recommended default here? It might sound a bit odd but >> I would suggest that the default be something like the square root of >> the number of Rbridges in the campus. (See comment below on volatility.) >> >> 3) RBridges are ranked by (priority, ID). The RBridge with the >> numerically lowest priority, and then numerically lowest ID being the >> tie breaker, dictates the total number of trees all the other RBridges >> must calculate (the number that R1 announces in its LSP according >> to rule 2 above. >> >> @@@ As long as you are generating a concatenated global priority number >> like (priority, ID), why not make it a little more clever by having it >> be (priority, order, ID) or something like that? (Where "order" is the >> number of adjacencies the Rbridge has, so you'd have to change the >> ranking to be highest priority is numerically largest...). >> >> 4) An RBridge calculates n distribution trees, where n is the number >> announced by the lowest (priority, ID) RBridge R1, in R1's LSP, >> as the "total number of trees". The n trees computed are the ones using >> the n numerically lowest (priority, ID) RBridges as roots >> >> 5) if RB1 is ingress RBridge on port p, and (*note another parameter >> "k"*) is configured to do k-way path splitting on that port for >> multidestination frames, the k tree roots that RB1 chooses consist of >> the three for which the triple "(cost of root to me, priority, ID)" are >> the k smallest. >> >> @@@ Of course the ranking has to be the same so if "order" were added as >> above, it would have to be added here also. >> >> Intuition: suppose there is a topology with a lot of "leaf" RBridges., >> and "next level" RBridges that the leaf RBridges connect to. >> If there are m leaf RBridges connected to next level RBridge RBx, then >> there is no reason to compute trees with any of the leaf >> RBridges as root -- the tree rooted at RBx will be the same tree, and >> will indeed be a shortest path tree for each of the attached >> leaf RBridges. If a leaf RBridge is attached to several next-level >> RBridges, the most significant number in the triple -- "cost >> of root to me" will cause the leaf RBridge to multipath the multicast >> among multiple shortest-path trees. >> >> @@@ That's all true but the special case of an Rbridge of order 1 >> connected to an Rbridge of order >1 seems so simple to check for that >> you could just rule them out. Or, if "order" were added to the >> comparison tuple as above, in the default case where all Rbridges have >> the default priority, order 1 Rbridges would automatically have lowest >> priority. (See also slides 8 and 9 of my presentation at >> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >> >> This seems completely safe, and easier than configuring, for each >> RBridge, the set of root RBridges to choose for multicast tree roots. >> It also means that you can configure in one place a total number of >> roots, rather than possibly having too many RBridges volunteer for >> being tree roots, and winding up with too much overhead on RBridges >> because they'll have to compute a tree for every RBridge that >> says it will want to be a tree root. >> >> There might be a concern about volatility -- when an RBridge with >> numerically low priority goes down, it might cause: >> a) a change to the total number of trees to be computed by everyone >> (since the next best might be configured with a different number) >> b) a change to the list of "tree roots I will choose" announced by RB2 >> when one of the roots for the k best (cost to me, priority, ID) goes >> down. >> >> @@@ There are plenty of other possible causes for volatility. Like a >> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >> priority-to-be-tree-root being reconfigured. But the solution to them >> all is the same. An Rbridge has to keep calculating (or at least keep >> around) trees for old roots as long as their reasonably might be frames >> in transit specifying those roots. It has to calculate trees for any new >> roots right away and, if appropriate, start advertising that it might >> use them. What root (or from what set of roots) to choose for new native >> multi-destination frames an Rbridge is encapsulating is a bit messier. >> Seems to me that until it is reasonably sure that information has >> propagated concerning new roots, it should only use those in the >> intersection of the sets of old and new roots. If that intersection is >> null, something only likely to occur when there are a very small number >> of tree roots, you have a bit of a problem and might as well use the new >> root(s). But this is no worse than under the previous scheme if >> RequestTree was FALSE for all Rbridges and the Rbridge with the lowest >> system ID, which had defaulted to being the only tree root, goes down. >> >> Other than that, I can't think of any possible problems. >> >> @@@ Overall, I like the proposal. >> >> Radia >> >> @@@ Thanks, >> @@@ Donald >> >> _______________________________________________ >> 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 > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From ddutt at cisco.com Tue Apr 1 21:32:45 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 01 Apr 2008 21:32:45 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com> <3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> Message-ID: <47F30C6D.8080605@cisco.com> Why 8 ? I prefer something much less. But again, this isn't something I'd debate much about. Priority will be configured as users want predictablity and determinism. Dinesh Eastlake III Donald-LDE008 wrote: > Hi, > > See below at @@@ > > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Tuesday, April 01, 2008 > To: Radia Perlman > Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. > Subject: Re: [rbridge] (slight) modification of how to choose mulitcast > trees > > Slight modification. I'd want the default to be smaller, say 2 or 4. But > > I won't quibble, > > Dinesh > > I agree with you Radia on both points, > > Dinesh > > Radia Perlman wrote: > >> My only 2 comments on your comments: >> a) I don't see how there can be a default of square root of number of >> RBridges, since RBridges wouldn't know the number >> of bridges. I'd say we should pick a number like "10". >> > > @@@ OK, so let's go with a recommended default of 8. > > >> b) Sorry -- need to "think aloud" here for a bit. >> A few questions about "order": "ports" is known in advance and doesn't >> > > >> change. "adjacencies" is not known in advance . >> But then you really want "RBridge adjacencies" and not just ports to >> endnodes...so I'm not sure. Maybe >> it has to be "RBridge adjacencies". But does having a fluctuating >> "order" cause problems? In theory we might want a pseudonode >> to be a tree root, but pseudonodes don't get nicknames, and therefore >> can't be specified as a tree root in the TRILL header. >> >> And then using numerically largest works for "order" but not for >> "distance to me", so that has to be adjusted (shouldn't be hard, >> > perhaps > >> making "order" be 1000 minus the number of RBridge adjacencies, going >> > no > >> lower than "0"). And "order" can be calculated from >> the LSP -- it doesn't have to be separately announced. Though if you >> > are > >> connected to a pseudonode do you have to remember >> to count all the RBridges connected to that pseudonode? >> >> It might be simpler to just have "order" feed into priority, as in, if >> > > >> your priority is not configured in advance, then if you have more >> than some number (say 2) RBridge adjacencies, you decrement your >> priority by 1 for every extra RBridge adjacency. If your >> priority is configured, you'd leave it at whatever it is configured to >> > be. > > @@@ I'm fine with order feeding into priority in some fashion if your > priority is not configured. People who are configuring ought to know > what they are doing and avoid ties. > > @@@ Thanks, > @@@ Donald > > >> Radia >> >> >> >> >> Eastlake III Donald-LDE008 wrote: >> >> >>> Hi, >>> >>> I agree that the present requirement that all Rbridges default to >>> > having > >>> the RequestTree be TRUE probably results in Rbridges being required >>> > to > >>> calculate too many trees in a large campus. See comments below at @@@ >>> >>> -----Original Message----- >>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] >>> > On > >>> Behalf Of Radia Perlman >>> Sent: Friday, March 28, 2008 10:55 PM >>> To: Developing a hybrid router/bridge. >>> Subject: [rbridge] (slight) modification of how to choose mulitcast >>> trees >>> >>> Dinesh suggested the following, as a way of making configuration >>> > easier > >>> for how to choose multicast trees. >>> >>> 1) Each RBridge is configured with a priority for being selected a >>> multicast tree root (with of course a default being a medium >>> > priority) > >>> 2) Each RBridge R1 is also configured with a parameter indicating >>> > "total > >>> number of trees in the campus", which R1 announces in its LSP. >>> >>> @@@ So what's the recommended default here? It might sound a bit odd >>> > but > >>> I would suggest that the default be something like the square root of >>> the number of Rbridges in the campus. (See comment below on >>> > volatility.) > >>> 3) RBridges are ranked by (priority, ID). The RBridge with the >>> numerically lowest priority, and then numerically lowest ID being the >>> tie breaker, dictates the total number of trees all the other >>> > RBridges > >>> must calculate (the number that R1 announces in its LSP according >>> to rule 2 above. >>> >>> @@@ As long as you are generating a concatenated global priority >>> > number > >>> like (priority, ID), why not make it a little more clever by having >>> > it > >>> be (priority, order, ID) or something like that? (Where "order" is >>> > the > >>> number of adjacencies the Rbridge has, so you'd have to change the >>> ranking to be highest priority is numerically largest...). >>> >>> 4) An RBridge calculates n distribution trees, where n is the number >>> announced by the lowest (priority, ID) RBridge R1, in R1's LSP, >>> as the "total number of trees". The n trees computed are the ones >>> > using > >>> the n numerically lowest (priority, ID) RBridges as roots >>> >>> 5) if RB1 is ingress RBridge on port p, and (*note another parameter >>> "k"*) is configured to do k-way path splitting on that port for >>> multidestination frames, the k tree roots that RB1 chooses consist of >>> > > >>> the three for which the triple "(cost of root to me, priority, ID)" >>> > are > >>> the k smallest. >>> >>> @@@ Of course the ranking has to be the same so if "order" were added >>> > as > >>> above, it would have to be added here also. >>> >>> Intuition: suppose there is a topology with a lot of "leaf" >>> > RBridges., > >>> and "next level" RBridges that the leaf RBridges connect to. >>> If there are m leaf RBridges connected to next level RBridge RBx, >>> > then > >>> there is no reason to compute trees with any of the leaf >>> RBridges as root -- the tree rooted at RBx will be the same tree, and >>> > > >>> will indeed be a shortest path tree for each of the attached >>> leaf RBridges. If a leaf RBridge is attached to several next-level >>> RBridges, the most significant number in the triple -- "cost >>> of root to me" will cause the leaf RBridge to multipath the multicast >>> > > >>> among multiple shortest-path trees. >>> >>> @@@ That's all true but the special case of an Rbridge of order 1 >>> connected to an Rbridge of order >1 seems so simple to check for that >>> you could just rule them out. Or, if "order" were added to the >>> comparison tuple as above, in the default case where all Rbridges >>> > have > >>> the default priority, order 1 Rbridges would automatically have >>> > lowest > >>> priority. (See also slides 8 and 9 of my presentation at >>> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >>> >>> This seems completely safe, and easier than configuring, for each >>> RBridge, the set of root RBridges to choose for multicast tree roots. >>> It also means that you can configure in one place a total number of >>> roots, rather than possibly having too many RBridges volunteer for >>> being tree roots, and winding up with too much overhead on RBridges >>> because they'll have to compute a tree for every RBridge that >>> says it will want to be a tree root. >>> >>> There might be a concern about volatility -- when an RBridge with >>> numerically low priority goes down, it might cause: >>> a) a change to the total number of trees to be computed by everyone >>> (since the next best might be configured with a different number) >>> b) a change to the list of "tree roots I will choose" announced by >>> > RB2 > >>> when one of the roots for the k best (cost to me, priority, ID) goes >>> down. >>> >>> @@@ There are plenty of other possible causes for volatility. Like a >>> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >>> priority-to-be-tree-root being reconfigured. But the solution to them >>> all is the same. An Rbridge has to keep calculating (or at least keep >>> around) trees for old roots as long as their reasonably might be >>> > frames > >>> in transit specifying those roots. It has to calculate trees for any >>> > new > >>> roots right away and, if appropriate, start advertising that it might >>> use them. What root (or from what set of roots) to choose for new >>> > native > >>> multi-destination frames an Rbridge is encapsulating is a bit >>> > messier. > >>> Seems to me that until it is reasonably sure that information has >>> propagated concerning new roots, it should only use those in the >>> intersection of the sets of old and new roots. If that intersection >>> > is > >>> null, something only likely to occur when there are a very small >>> > number > >>> of tree roots, you have a bit of a problem and might as well use the >>> > new > >>> root(s). But this is no worse than under the previous scheme if >>> RequestTree was FALSE for all Rbridges and the Rbridge with the >>> > lowest > >>> system ID, which had defaulted to being the only tree root, goes >>> > down. > >>> Other than that, I can't think of any possible problems. >>> >>> @@@ Overall, I like the proposal. >>> >>> Radia >>> >>> @@@ Thanks, >>> @@@ Donald >>> >>> _______________________________________________ >>> 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 >> >> >> > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From erik.nordmark at sun.com Wed Apr 2 10:53:12 2008 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 02 Apr 2008 10:53:12 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47EDAF9C.7070000@sun.com> References: <47EDAF9C.7070000@sun.com> Message-ID: <47F3C808.4090805@sun.com> Radia Perlman wrote: > Dinesh suggested the following, as a way of making configuration easier > There might be a concern about volatility -- when an RBridge with > numerically low priority goes down, it might cause: > a) a change to the total number of trees to be computed by everyone > (since the next best might be configured with a different number) > b) a change to the list of "tree roots I will choose" announced by RB2 > when one of the roots for the k best (cost to me, priority, ID) goes down. Has anybody looked at the volatily when the network comes up e.g., after a building power failure? In that case RBridges will start sending hellos incrementally adding adjacencies, and receive flooded LSAs from RBridges that have just appeared. Clearly if the network builds one RBridge at a time the regular unicast tree (the one rooted at the RBridge itself) would end up being recalculated up to N times (perhaps even more if the adjacencies between the N RBridges come up incrementally). But here we are adding the fact that the *set of* multi-destination trees you to calculate would change as the network powers up. Do we know anything about the amount of churn that would cause? It seems like receiving the first flooded LSA from an RBridge that just came up could cause the receiver to conclude that one (or more than one?) of the trees it has calculated are no longer needed, and that it instead needs to calculate a different set of trees. A later LSA (from a different RBridge) could cause things to switch back to use the trees that were just discarded. It sounds like this behavior can be quite dynamic. Erik From anoop at brocade.com Wed Apr 2 11:08:48 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 2 Apr 2008 11:08:48 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47F30C6D.8080605@cisco.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com><47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com><3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> <47F30C6D.8080605@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0139C328@HQ-EXCH-5.corp.brocade.com> I would go even further and say that 1 tree is what should be mandated. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt > Sent: Tuesday, April 01, 2008 9:33 PM > To: Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge.; Radia Perlman > Subject: Re: [rbridge] (slight) modification of how to choose > mulitcast trees > > Why 8 ? I prefer something much less. But again, this isn't > something I'd debate much about. Priority will be configured > as users want predictablity and determinism. > > Dinesh > Eastlake III Donald-LDE008 wrote: > > Hi, > > > > See below at @@@ > > > > -----Original Message----- > > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > > Sent: Tuesday, April 01, 2008 > > To: Radia Perlman > > Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] (slight) modification of how to choose > > mulitcast trees > > > > Slight modification. I'd want the default to be smaller, > say 2 or 4. > > But > > > > I won't quibble, > > > > Dinesh > > > > I agree with you Radia on both points, > > > > Dinesh > > > > Radia Perlman wrote: > > > >> My only 2 comments on your comments: > >> a) I don't see how there can be a default of square root > of number of > >> RBridges, since RBridges wouldn't know the number of > bridges. I'd say > >> we should pick a number like "10". > >> > > > > @@@ OK, so let's go with a recommended default of 8. > > > > > >> b) Sorry -- need to "think aloud" here for a bit. > >> A few questions about "order": "ports" is known in advance and > >> doesn't > >> > > > > > >> change. "adjacencies" is not known in advance . > >> But then you really want "RBridge adjacencies" and not > just ports to > >> endnodes...so I'm not sure. Maybe it has to be "RBridge > adjacencies". > >> But does having a fluctuating "order" cause problems? In theory we > >> might want a pseudonode to be a tree root, but pseudonodes > don't get > >> nicknames, and therefore can't be specified as a tree root in the > >> TRILL header. > >> > >> And then using numerically largest works for "order" but not for > >> "distance to me", so that has to be adjusted (shouldn't be hard, > >> > > perhaps > > > >> making "order" be 1000 minus the number of RBridge > adjacencies, going > >> > > no > > > >> lower than "0"). And "order" can be calculated from the LSP -- it > >> doesn't have to be separately announced. Though if you > >> > > are > > > >> connected to a pseudonode do you have to remember to count all the > >> RBridges connected to that pseudonode? > >> > >> It might be simpler to just have "order" feed into > priority, as in, > >> if > >> > > > > > >> your priority is not configured in advance, then if you have more > >> than some number (say 2) RBridge adjacencies, you decrement your > >> priority by 1 for every extra RBridge adjacency. If your > priority is > >> configured, you'd leave it at whatever it is configured to > >> > > be. > > > > @@@ I'm fine with order feeding into priority in some > fashion if your > > priority is not configured. People who are configuring > ought to know > > what they are doing and avoid ties. > > > > @@@ Thanks, > > @@@ Donald > > > > > >> Radia > >> > >> > >> > >> > >> Eastlake III Donald-LDE008 wrote: > >> > >> > >>> Hi, > >>> > >>> I agree that the present requirement that all Rbridges default to > >>> > > having > > > >>> the RequestTree be TRUE probably results in Rbridges > being required > >>> > > to > > > >>> calculate too many trees in a large campus. See comments below at > >>> @@@ > >>> > >>> -----Original Message----- > >>> From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > >>> > > On > > > >>> Behalf Of Radia Perlman > >>> Sent: Friday, March 28, 2008 10:55 PM > >>> To: Developing a hybrid router/bridge. > >>> Subject: [rbridge] (slight) modification of how to choose > mulitcast > >>> trees > >>> > >>> Dinesh suggested the following, as a way of making configuration > >>> > > easier > > > >>> for how to choose multicast trees. > >>> > >>> 1) Each RBridge is configured with a priority for being > selected a > >>> multicast tree root (with of course a default being a medium > >>> > > priority) > > > >>> 2) Each RBridge R1 is also configured with a parameter indicating > >>> > > "total > > > >>> number of trees in the campus", which R1 announces in its LSP. > >>> > >>> @@@ So what's the recommended default here? It might > sound a bit odd > >>> > > but > > > >>> I would suggest that the default be something like the > square root > >>> of the number of Rbridges in the campus. (See comment below on > >>> > > volatility.) > > > >>> 3) RBridges are ranked by (priority, ID). The RBridge with the > >>> numerically lowest priority, and then numerically lowest ID being > >>> the tie breaker, dictates the total number of trees all the other > >>> > > RBridges > > > >>> must calculate (the number that R1 announces in its LSP > according to > >>> rule 2 above. > >>> > >>> @@@ As long as you are generating a concatenated global priority > >>> > > number > > > >>> like (priority, ID), why not make it a little more clever > by having > >>> > > it > > > >>> be (priority, order, ID) or something like that? (Where "order" is > >>> > > the > > > >>> number of adjacencies the Rbridge has, so you'd have to > change the > >>> ranking to be highest priority is numerically largest...). > >>> > >>> 4) An RBridge calculates n distribution trees, where n is > the number > >>> announced by the lowest (priority, ID) RBridge R1, in > R1's LSP, as > >>> the "total number of trees". The n trees computed are the ones > >>> > > using > > > >>> the n numerically lowest (priority, ID) RBridges as roots > >>> > >>> 5) if RB1 is ingress RBridge on port p, and (*note > another parameter > >>> "k"*) is configured to do k-way path splitting on that port for > >>> multidestination frames, the k tree roots that RB1 > chooses consist > >>> of > >>> > > > > > >>> the three for which the triple "(cost of root to me, > priority, ID)" > >>> > > are > > > >>> the k smallest. > >>> > >>> @@@ Of course the ranking has to be the same so if "order" were > >>> added > >>> > > as > > > >>> above, it would have to be added here also. > >>> > >>> Intuition: suppose there is a topology with a lot of "leaf" > >>> > > RBridges., > > > >>> and "next level" RBridges that the leaf RBridges connect to. > >>> If there are m leaf RBridges connected to next level RBridge RBx, > >>> > > then > > > >>> there is no reason to compute trees with any of the leaf > RBridges as > >>> root -- the tree rooted at RBx will be the same tree, and > >>> > > > > > >>> will indeed be a shortest path tree for each of the attached leaf > >>> RBridges. If a leaf RBridge is attached to several next-level > >>> RBridges, the most significant number in the triple -- > "cost of root > >>> to me" will cause the leaf RBridge to multipath the multicast > >>> > > > > > >>> among multiple shortest-path trees. > >>> > >>> @@@ That's all true but the special case of an Rbridge of order 1 > >>> connected to an Rbridge of order >1 seems so simple to check for > >>> that you could just rule them out. Or, if "order" were > added to the > >>> comparison tuple as above, in the default case where all Rbridges > >>> > > have > > > >>> the default priority, order 1 Rbridges would automatically have > >>> > > lowest > > > >>> priority. (See also slides 8 and 9 of my presentation at > >>> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) > >>> > >>> This seems completely safe, and easier than configuring, for each > >>> RBridge, the set of root RBridges to choose for multicast > tree roots. > >>> It also means that you can configure in one place a total > number of > >>> roots, rather than possibly having too many RBridges > volunteer for > >>> being tree roots, and winding up with too much overhead > on RBridges > >>> because they'll have to compute a tree for every RBridge > that says > >>> it will want to be a tree root. > >>> > >>> There might be a concern about volatility -- when an RBridge with > >>> numerically low priority goes down, it might cause: > >>> a) a change to the total number of trees to be computed > by everyone > >>> (since the next best might be configured with a different number) > >>> b) a change to the list of "tree roots I will choose" announced by > >>> > > RB2 > > > >>> when one of the roots for the k best (cost to me, > priority, ID) goes > >>> down. > >>> > >>> @@@ There are plenty of other possible causes for > volatility. Like a > >>> high priority-to-be-tree-root Rbridge coming up or an Rbridge's > >>> priority-to-be-tree-root being reconfigured. But the solution to > >>> them all is the same. An Rbridge has to keep calculating (or at > >>> least keep > >>> around) trees for old roots as long as their reasonably might be > >>> > > frames > > > >>> in transit specifying those roots. It has to calculate > trees for any > >>> > > new > > > >>> roots right away and, if appropriate, start advertising that it > >>> might use them. What root (or from what set of roots) to > choose for > >>> new > >>> > > native > > > >>> multi-destination frames an Rbridge is encapsulating is a bit > >>> > > messier. > > > >>> Seems to me that until it is reasonably sure that information has > >>> propagated concerning new roots, it should only use those in the > >>> intersection of the sets of old and new roots. If that > intersection > >>> > > is > > > >>> null, something only likely to occur when there are a very small > >>> > > number > > > >>> of tree roots, you have a bit of a problem and might as > well use the > >>> > > new > > > >>> root(s). But this is no worse than under the previous scheme if > >>> RequestTree was FALSE for all Rbridges and the Rbridge with the > >>> > > lowest > > > >>> system ID, which had defaulted to being the only tree root, goes > >>> > > down. > > > >>> Other than that, I can't think of any possible problems. > >>> > >>> @@@ Overall, I like the proposal. > >>> > >>> Radia > >>> > >>> @@@ Thanks, > >>> @@@ Donald > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > >> > > > > > > -- > 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 > From ddutt at cisco.com Wed Apr 2 11:36:48 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 02 Apr 2008 11:36:48 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0139C328@HQ-EXCH-5.corp.brocade.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com><47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com><3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> <47F30C6D.8080605@cisco.com> <4C94DE2070B172459E4F1EE14BD2364E0139C328@HQ-EXCH-5.corp.brocade.com> Message-ID: <47F3D240.1070902@cisco.com> I'm fine with that, Dinesh Anoop Ghanwani wrote: > I would go even further and say that 1 tree is what > should be mandated. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt >> Sent: Tuesday, April 01, 2008 9:33 PM >> To: Eastlake III Donald-LDE008 >> Cc: Developing a hybrid router/bridge.; Radia Perlman >> Subject: Re: [rbridge] (slight) modification of how to choose >> mulitcast trees >> >> Why 8 ? I prefer something much less. But again, this isn't >> something I'd debate much about. Priority will be configured >> as users want predictablity and determinism. >> >> Dinesh >> Eastlake III Donald-LDE008 wrote: >> >>> Hi, >>> >>> See below at @@@ >>> >>> -----Original Message----- >>> From: Dinesh G Dutt [mailto:ddutt at cisco.com] >>> Sent: Tuesday, April 01, 2008 >>> To: Radia Perlman >>> Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. >>> Subject: Re: [rbridge] (slight) modification of how to choose >>> mulitcast trees >>> >>> Slight modification. I'd want the default to be smaller, >>> >> say 2 or 4. >> >>> But >>> >>> I won't quibble, >>> >>> Dinesh >>> >>> I agree with you Radia on both points, >>> >>> Dinesh >>> >>> Radia Perlman wrote: >>> >>> >>>> My only 2 comments on your comments: >>>> a) I don't see how there can be a default of square root >>>> >> of number of >> >>>> RBridges, since RBridges wouldn't know the number of >>>> >> bridges. I'd say >> >>>> we should pick a number like "10". >>>> >>>> >>> @@@ OK, so let's go with a recommended default of 8. >>> >>> >>> >>>> b) Sorry -- need to "think aloud" here for a bit. >>>> A few questions about "order": "ports" is known in advance and >>>> doesn't >>>> >>>> >>> >>> >>>> change. "adjacencies" is not known in advance . >>>> But then you really want "RBridge adjacencies" and not >>>> >> just ports to >> >>>> endnodes...so I'm not sure. Maybe it has to be "RBridge >>>> >> adjacencies". >> >>>> But does having a fluctuating "order" cause problems? In theory we >>>> might want a pseudonode to be a tree root, but pseudonodes >>>> >> don't get >> >>>> nicknames, and therefore can't be specified as a tree root in the >>>> TRILL header. >>>> >>>> And then using numerically largest works for "order" but not for >>>> "distance to me", so that has to be adjusted (shouldn't be hard, >>>> >>>> >>> perhaps >>> >>> >>>> making "order" be 1000 minus the number of RBridge >>>> >> adjacencies, going >> >>>> >>>> >>> no >>> >>> >>>> lower than "0"). And "order" can be calculated from the LSP -- it >>>> doesn't have to be separately announced. Though if you >>>> >>>> >>> are >>> >>> >>>> connected to a pseudonode do you have to remember to count all the >>>> RBridges connected to that pseudonode? >>>> >>>> It might be simpler to just have "order" feed into >>>> >> priority, as in, >> >>>> if >>>> >>>> >>> >>> >>>> your priority is not configured in advance, then if you have more >>>> than some number (say 2) RBridge adjacencies, you decrement your >>>> priority by 1 for every extra RBridge adjacency. If your >>>> >> priority is >> >>>> configured, you'd leave it at whatever it is configured to >>>> >>>> >>> be. >>> >>> @@@ I'm fine with order feeding into priority in some >>> >> fashion if your >> >>> priority is not configured. People who are configuring >>> >> ought to know >> >>> what they are doing and avoid ties. >>> >>> @@@ Thanks, >>> @@@ Donald >>> >>> >>> >>>> Radia >>>> >>>> >>>> >>>> >>>> Eastlake III Donald-LDE008 wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I agree that the present requirement that all Rbridges default to >>>>> >>>>> >>> having >>> >>> >>>>> the RequestTree be TRUE probably results in Rbridges >>>>> >> being required >> >>>>> >>>>> >>> to >>> >>> >>>>> calculate too many trees in a large campus. See comments below at >>>>> @@@ >>>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces at postel.org >>>>> >> [mailto:rbridge-bounces at postel.org] >> >>>>> >>>>> >>> On >>> >>> >>>>> Behalf Of Radia Perlman >>>>> Sent: Friday, March 28, 2008 10:55 PM >>>>> To: Developing a hybrid router/bridge. >>>>> Subject: [rbridge] (slight) modification of how to choose >>>>> >> mulitcast >> >>>>> trees >>>>> >>>>> Dinesh suggested the following, as a way of making configuration >>>>> >>>>> >>> easier >>> >>> >>>>> for how to choose multicast trees. >>>>> >>>>> 1) Each RBridge is configured with a priority for being >>>>> >> selected a >> >>>>> multicast tree root (with of course a default being a medium >>>>> >>>>> >>> priority) >>> >>> >>>>> 2) Each RBridge R1 is also configured with a parameter indicating >>>>> >>>>> >>> "total >>> >>> >>>>> number of trees in the campus", which R1 announces in its LSP. >>>>> >>>>> @@@ So what's the recommended default here? It might >>>>> >> sound a bit odd >> >>>>> >>>>> >>> but >>> >>> >>>>> I would suggest that the default be something like the >>>>> >> square root >> >>>>> of the number of Rbridges in the campus. (See comment below on >>>>> >>>>> >>> volatility.) >>> >>> >>>>> 3) RBridges are ranked by (priority, ID). The RBridge with the >>>>> numerically lowest priority, and then numerically lowest ID being >>>>> the tie breaker, dictates the total number of trees all the other >>>>> >>>>> >>> RBridges >>> >>> >>>>> must calculate (the number that R1 announces in its LSP >>>>> >> according to >> >>>>> rule 2 above. >>>>> >>>>> @@@ As long as you are generating a concatenated global priority >>>>> >>>>> >>> number >>> >>> >>>>> like (priority, ID), why not make it a little more clever >>>>> >> by having >> >>>>> >>>>> >>> it >>> >>> >>>>> be (priority, order, ID) or something like that? (Where "order" is >>>>> >>>>> >>> the >>> >>> >>>>> number of adjacencies the Rbridge has, so you'd have to >>>>> >> change the >> >>>>> ranking to be highest priority is numerically largest...). >>>>> >>>>> 4) An RBridge calculates n distribution trees, where n is >>>>> >> the number >> >>>>> announced by the lowest (priority, ID) RBridge R1, in >>>>> >> R1's LSP, as >> >>>>> the "total number of trees". The n trees computed are the ones >>>>> >>>>> >>> using >>> >>> >>>>> the n numerically lowest (priority, ID) RBridges as roots >>>>> >>>>> 5) if RB1 is ingress RBridge on port p, and (*note >>>>> >> another parameter >> >>>>> "k"*) is configured to do k-way path splitting on that port for >>>>> multidestination frames, the k tree roots that RB1 >>>>> >> chooses consist >> >>>>> of >>>>> >>>>> >>> >>> >>>>> the three for which the triple "(cost of root to me, >>>>> >> priority, ID)" >> >>>>> >>>>> >>> are >>> >>> >>>>> the k smallest. >>>>> >>>>> @@@ Of course the ranking has to be the same so if "order" were >>>>> added >>>>> >>>>> >>> as >>> >>> >>>>> above, it would have to be added here also. >>>>> >>>>> Intuition: suppose there is a topology with a lot of "leaf" >>>>> >>>>> >>> RBridges., >>> >>> >>>>> and "next level" RBridges that the leaf RBridges connect to. >>>>> If there are m leaf RBridges connected to next level RBridge RBx, >>>>> >>>>> >>> then >>> >>> >>>>> there is no reason to compute trees with any of the leaf >>>>> >> RBridges as >> >>>>> root -- the tree rooted at RBx will be the same tree, and >>>>> >>>>> >>> >>> >>>>> will indeed be a shortest path tree for each of the attached leaf >>>>> RBridges. If a leaf RBridge is attached to several next-level >>>>> RBridges, the most significant number in the triple -- >>>>> >> "cost of root >> >>>>> to me" will cause the leaf RBridge to multipath the multicast >>>>> >>>>> >>> >>> >>>>> among multiple shortest-path trees. >>>>> >>>>> @@@ That's all true but the special case of an Rbridge of order 1 >>>>> connected to an Rbridge of order >1 seems so simple to check for >>>>> that you could just rule them out. Or, if "order" were >>>>> >> added to the >> >>>>> comparison tuple as above, in the default case where all Rbridges >>>>> >>>>> >>> have >>> >>> >>>>> the default priority, order 1 Rbridges would automatically have >>>>> >>>>> >>> lowest >>> >>> >>>>> priority. (See also slides 8 and 9 of my presentation at >>>>> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >>>>> >>>>> This seems completely safe, and easier than configuring, for each >>>>> RBridge, the set of root RBridges to choose for multicast >>>>> >> tree roots. >> >>>>> It also means that you can configure in one place a total >>>>> >> number of >> >>>>> roots, rather than possibly having too many RBridges >>>>> >> volunteer for >> >>>>> being tree roots, and winding up with too much overhead >>>>> >> on RBridges >> >>>>> because they'll have to compute a tree for every RBridge >>>>> >> that says >> >>>>> it will want to be a tree root. >>>>> >>>>> There might be a concern about volatility -- when an RBridge with >>>>> numerically low priority goes down, it might cause: >>>>> a) a change to the total number of trees to be computed >>>>> >> by everyone >> >>>>> (since the next best might be configured with a different number) >>>>> b) a change to the list of "tree roots I will choose" announced by >>>>> >>>>> >>> RB2 >>> >>> >>>>> when one of the roots for the k best (cost to me, >>>>> >> priority, ID) goes >> >>>>> down. >>>>> >>>>> @@@ There are plenty of other possible causes for >>>>> >> volatility. Like a >> >>>>> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >>>>> priority-to-be-tree-root being reconfigured. But the solution to >>>>> them all is the same. An Rbridge has to keep calculating (or at >>>>> least keep >>>>> around) trees for old roots as long as their reasonably might be >>>>> >>>>> >>> frames >>> >>> >>>>> in transit specifying those roots. It has to calculate >>>>> >> trees for any >> >>>>> >>>>> >>> new >>> >>> >>>>> roots right away and, if appropriate, start advertising that it >>>>> might use them. What root (or from what set of roots) to >>>>> >> choose for >> >>>>> new >>>>> >>>>> >>> native >>> >>> >>>>> multi-destination frames an Rbridge is encapsulating is a bit >>>>> >>>>> >>> messier. >>> >>> >>>>> Seems to me that until it is reasonably sure that information has >>>>> propagated concerning new roots, it should only use those in the >>>>> intersection of the sets of old and new roots. If that >>>>> >> intersection >> >>>>> >>>>> >>> is >>> >>> >>>>> null, something only likely to occur when there are a very small >>>>> >>>>> >>> number >>> >>> >>>>> of tree roots, you have a bit of a problem and might as >>>>> >> well use the >> >>>>> >>>>> >>> new >>> >>> >>>>> root(s). But this is no worse than under the previous scheme if >>>>> RequestTree was FALSE for all Rbridges and the Rbridge with the >>>>> >>>>> >>> lowest >>> >>> >>>>> system ID, which had defaulted to being the only tree root, goes >>>>> >>>>> >>> down. >>> >>> >>>>> Other than that, I can't think of any possible problems. >>>>> >>>>> @@@ Overall, I like the proposal. >>>>> >>>>> Radia >>>>> >>>>> @@@ Thanks, >>>>> @@@ Donald >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> >>> >>> >> -- >> 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 >> >> > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Donald.Eastlake at motorola.com Fri Apr 4 14:27:40 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 4 Apr 2008 17:27:40 -0400 Subject: [rbridge] Consensus Check: Decapsulation check optional In-Reply-To: <4784F127.6020603@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8AF1@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* Keep the reporting by RBridges in the link state database of root bridge IDs observed mandatory, as in the current (-07) draft, but make the "decapsulation" check optional. If no particular controversy arises over this in the next two weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Fri Apr 4 14:39:09 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 4 Apr 2008 17:39:09 -0400 Subject: [rbridge] Consensus Check: Test for VLAN mapping References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8B01@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* The Outer VLAN ID will be duplicated in a TLV inside TRILL IS-IS Hellos to test for VLAN mapping. If no particular controversy arises over this in the next two weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Fri Apr 4 14:44:01 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 4 Apr 2008 17:44:01 -0400 Subject: [rbridge] Consensus Check: Text trumps pseudocode References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* Change the base protocol draft so that where the pseudocode and text conflict, the text is normative. If no particular controversy arises over this in the next two weeks, We will declare it to be the working group consensus. Thanks, Donald & Erik From Radia.Perlman at sun.com Sat Apr 5 18:05:37 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sat, 05 Apr 2008 18:05:37 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0139C328@HQ-EXCH-5.corp.brocade.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com> <3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> <47F30C6D.8080605@cisco.com> <4C94DE2070B172459E4F1EE14BD2364E0139C328@HQ-EXCH-5.corp.brocade.com> Message-ID: <47F821E1.7000109@sun.com> I don't understand. What do you mean by "mandated"? Do you mean "recommended default=1"? That probably wouldn't be controversial. But if you mean "mandated" as in, "only do one tree" (which was my original assumption, by the way), I'm sure that would be controversial. I'm almost certain you meant "recommended default=1", rather than "mandate one tree" but it would be good to clarify what you meant. Radia Anoop Ghanwani wrote: > I would go even further and say that 1 tree is what > should be mandated. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt >> Sent: Tuesday, April 01, 2008 9:33 PM >> To: Eastlake III Donald-LDE008 >> Cc: Developing a hybrid router/bridge.; Radia Perlman >> Subject: Re: [rbridge] (slight) modification of how to choose >> mulitcast trees >> >> Why 8 ? I prefer something much less. But again, this isn't >> something I'd debate much about. Priority will be configured >> as users want predictablity and determinism. >> >> Dinesh >> Eastlake III Donald-LDE008 wrote: >> >>> Hi, >>> >>> See below at @@@ >>> >>> -----Original Message----- >>> From: Dinesh G Dutt [mailto:ddutt at cisco.com] >>> Sent: Tuesday, April 01, 2008 >>> To: Radia Perlman >>> Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. >>> Subject: Re: [rbridge] (slight) modification of how to choose >>> mulitcast trees >>> >>> Slight modification. I'd want the default to be smaller, >>> >> say 2 or 4. >> >>> But >>> >>> I won't quibble, >>> >>> Dinesh >>> >>> I agree with you Radia on both points, >>> >>> Dinesh >>> >>> Radia Perlman wrote: >>> >>> >>>> My only 2 comments on your comments: >>>> a) I don't see how there can be a default of square root >>>> >> of number of >> >>>> RBridges, since RBridges wouldn't know the number of >>>> >> bridges. I'd say >> >>>> we should pick a number like "10". >>>> >>>> >>> @@@ OK, so let's go with a recommended default of 8. >>> >>> >>> >>>> b) Sorry -- need to "think aloud" here for a bit. >>>> A few questions about "order": "ports" is known in advance and >>>> doesn't >>>> >>>> >>> >>> >>>> change. "adjacencies" is not known in advance . >>>> But then you really want "RBridge adjacencies" and not >>>> >> just ports to >> >>>> endnodes...so I'm not sure. Maybe it has to be "RBridge >>>> >> adjacencies". >> >>>> But does having a fluctuating "order" cause problems? In theory we >>>> might want a pseudonode to be a tree root, but pseudonodes >>>> >> don't get >> >>>> nicknames, and therefore can't be specified as a tree root in the >>>> TRILL header. >>>> >>>> And then using numerically largest works for "order" but not for >>>> "distance to me", so that has to be adjusted (shouldn't be hard, >>>> >>>> >>> perhaps >>> >>> >>>> making "order" be 1000 minus the number of RBridge >>>> >> adjacencies, going >> >>>> >>>> >>> no >>> >>> >>>> lower than "0"). And "order" can be calculated from the LSP -- it >>>> doesn't have to be separately announced. Though if you >>>> >>>> >>> are >>> >>> >>>> connected to a pseudonode do you have to remember to count all the >>>> RBridges connected to that pseudonode? >>>> >>>> It might be simpler to just have "order" feed into >>>> >> priority, as in, >> >>>> if >>>> >>>> >>> >>> >>>> your priority is not configured in advance, then if you have more >>>> than some number (say 2) RBridge adjacencies, you decrement your >>>> priority by 1 for every extra RBridge adjacency. If your >>>> >> priority is >> >>>> configured, you'd leave it at whatever it is configured to >>>> >>>> >>> be. >>> >>> @@@ I'm fine with order feeding into priority in some >>> >> fashion if your >> >>> priority is not configured. People who are configuring >>> >> ought to know >> >>> what they are doing and avoid ties. >>> >>> @@@ Thanks, >>> @@@ Donald >>> >>> >>> >>>> Radia >>>> >>>> >>>> >>>> >>>> Eastlake III Donald-LDE008 wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I agree that the present requirement that all Rbridges default to >>>>> >>>>> >>> having >>> >>> >>>>> the RequestTree be TRUE probably results in Rbridges >>>>> >> being required >> >>>>> >>>>> >>> to >>> >>> >>>>> calculate too many trees in a large campus. See comments below at >>>>> @@@ >>>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces at postel.org >>>>> >> [mailto:rbridge-bounces at postel.org] >> >>>>> >>>>> >>> On >>> >>> >>>>> Behalf Of Radia Perlman >>>>> Sent: Friday, March 28, 2008 10:55 PM >>>>> To: Developing a hybrid router/bridge. >>>>> Subject: [rbridge] (slight) modification of how to choose >>>>> >> mulitcast >> >>>>> trees >>>>> >>>>> Dinesh suggested the following, as a way of making configuration >>>>> >>>>> >>> easier >>> >>> >>>>> for how to choose multicast trees. >>>>> >>>>> 1) Each RBridge is configured with a priority for being >>>>> >> selected a >> >>>>> multicast tree root (with of course a default being a medium >>>>> >>>>> >>> priority) >>> >>> >>>>> 2) Each RBridge R1 is also configured with a parameter indicating >>>>> >>>>> >>> "total >>> >>> >>>>> number of trees in the campus", which R1 announces in its LSP. >>>>> >>>>> @@@ So what's the recommended default here? It might >>>>> >> sound a bit odd >> >>>>> >>>>> >>> but >>> >>> >>>>> I would suggest that the default be something like the >>>>> >> square root >> >>>>> of the number of Rbridges in the campus. (See comment below on >>>>> >>>>> >>> volatility.) >>> >>> >>>>> 3) RBridges are ranked by (priority, ID). The RBridge with the >>>>> numerically lowest priority, and then numerically lowest ID being >>>>> the tie breaker, dictates the total number of trees all the other >>>>> >>>>> >>> RBridges >>> >>> >>>>> must calculate (the number that R1 announces in its LSP >>>>> >> according to >> >>>>> rule 2 above. >>>>> >>>>> @@@ As long as you are generating a concatenated global priority >>>>> >>>>> >>> number >>> >>> >>>>> like (priority, ID), why not make it a little more clever >>>>> >> by having >> >>>>> >>>>> >>> it >>> >>> >>>>> be (priority, order, ID) or something like that? (Where "order" is >>>>> >>>>> >>> the >>> >>> >>>>> number of adjacencies the Rbridge has, so you'd have to >>>>> >> change the >> >>>>> ranking to be highest priority is numerically largest...). >>>>> >>>>> 4) An RBridge calculates n distribution trees, where n is >>>>> >> the number >> >>>>> announced by the lowest (priority, ID) RBridge R1, in >>>>> >> R1's LSP, as >> >>>>> the "total number of trees". The n trees computed are the ones >>>>> >>>>> >>> using >>> >>> >>>>> the n numerically lowest (priority, ID) RBridges as roots >>>>> >>>>> 5) if RB1 is ingress RBridge on port p, and (*note >>>>> >> another parameter >> >>>>> "k"*) is configured to do k-way path splitting on that port for >>>>> multidestination frames, the k tree roots that RB1 >>>>> >> chooses consist >> >>>>> of >>>>> >>>>> >>> >>> >>>>> the three for which the triple "(cost of root to me, >>>>> >> priority, ID)" >> >>>>> >>>>> >>> are >>> >>> >>>>> the k smallest. >>>>> >>>>> @@@ Of course the ranking has to be the same so if "order" were >>>>> added >>>>> >>>>> >>> as >>> >>> >>>>> above, it would have to be added here also. >>>>> >>>>> Intuition: suppose there is a topology with a lot of "leaf" >>>>> >>>>> >>> RBridges., >>> >>> >>>>> and "next level" RBridges that the leaf RBridges connect to. >>>>> If there are m leaf RBridges connected to next level RBridge RBx, >>>>> >>>>> >>> then >>> >>> >>>>> there is no reason to compute trees with any of the leaf >>>>> >> RBridges as >> >>>>> root -- the tree rooted at RBx will be the same tree, and >>>>> >>>>> >>> >>> >>>>> will indeed be a shortest path tree for each of the attached leaf >>>>> RBridges. If a leaf RBridge is attached to several next-level >>>>> RBridges, the most significant number in the triple -- >>>>> >> "cost of root >> >>>>> to me" will cause the leaf RBridge to multipath the multicast >>>>> >>>>> >>> >>> >>>>> among multiple shortest-path trees. >>>>> >>>>> @@@ That's all true but the special case of an Rbridge of order 1 >>>>> connected to an Rbridge of order >1 seems so simple to check for >>>>> that you could just rule them out. Or, if "order" were >>>>> >> added to the >> >>>>> comparison tuple as above, in the default case where all Rbridges >>>>> >>>>> >>> have >>> >>> >>>>> the default priority, order 1 Rbridges would automatically have >>>>> >>>>> >>> lowest >>> >>> >>>>> priority. (See also slides 8 and 9 of my presentation at >>>>> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >>>>> >>>>> This seems completely safe, and easier than configuring, for each >>>>> RBridge, the set of root RBridges to choose for multicast >>>>> >> tree roots. >> >>>>> It also means that you can configure in one place a total >>>>> >> number of >> >>>>> roots, rather than possibly having too many RBridges >>>>> >> volunteer for >> >>>>> being tree roots, and winding up with too much overhead >>>>> >> on RBridges >> >>>>> because they'll have to compute a tree for every RBridge >>>>> >> that says >> >>>>> it will want to be a tree root. >>>>> >>>>> There might be a concern about volatility -- when an RBridge with >>>>> numerically low priority goes down, it might cause: >>>>> a) a change to the total number of trees to be computed >>>>> >> by everyone >> >>>>> (since the next best might be configured with a different number) >>>>> b) a change to the list of "tree roots I will choose" announced by >>>>> >>>>> >>> RB2 >>> >>> >>>>> when one of the roots for the k best (cost to me, >>>>> >> priority, ID) goes >> >>>>> down. >>>>> >>>>> @@@ There are plenty of other possible causes for >>>>> >> volatility. Like a >> >>>>> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >>>>> priority-to-be-tree-root being reconfigured. But the solution to >>>>> them all is the same. An Rbridge has to keep calculating (or at >>>>> least keep >>>>> around) trees for old roots as long as their reasonably might be >>>>> >>>>> >>> frames >>> >>> >>>>> in transit specifying those roots. It has to calculate >>>>> >> trees for any >> >>>>> >>>>> >>> new >>> >>> >>>>> roots right away and, if appropriate, start advertising that it >>>>> might use them. What root (or from what set of roots) to >>>>> >> choose for >> >>>>> new >>>>> >>>>> >>> native >>> >>> >>>>> multi-destination frames an Rbridge is encapsulating is a bit >>>>> >>>>> >>> messier. >>> >>> >>>>> Seems to me that until it is reasonably sure that information has >>>>> propagated concerning new roots, it should only use those in the >>>>> intersection of the sets of old and new roots. If that >>>>> >> intersection >> >>>>> >>>>> >>> is >>> >>> >>>>> null, something only likely to occur when there are a very small >>>>> >>>>> >>> number >>> >>> >>>>> of tree roots, you have a bit of a problem and might as >>>>> >> well use the >> >>>>> >>>>> >>> new >>> >>> >>>>> root(s). But this is no worse than under the previous scheme if >>>>> RequestTree was FALSE for all Rbridges and the Rbridge with the >>>>> >>>>> >>> lowest >>> >>> >>>>> system ID, which had defaulted to being the only tree root, goes >>>>> >>>>> >>> down. >>> >>> >>>>> Other than that, I can't think of any possible problems. >>>>> >>>>> @@@ Overall, I like the proposal. >>>>> >>>>> Radia >>>>> >>>>> @@@ Thanks, >>>>> @@@ Donald >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> >>> >>> >> -- >> 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 >> >> From anoop at brocade.com Sun Apr 6 19:28:51 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Sun, 6 Apr 2008 19:28:51 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees References: <47EDAF9C.7070000@sun.com><3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com><47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com><3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com><47F30C6D.8080605@cisco.com><4C94DE2070B172459E4F1EE14BD2364E0139C328@HQ-EXCH-5.corp.brocade.com> <47F821E1.7000109@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E07E44D@HQ-EXCH-5.corp.brocade.com> Yes, I meant recommended default=1. To me, that would mandate that my implementation be capable of computing at least that many trees, hence the choice of language. Anoop -----Original Message----- From: rbridge-bounces at postel.org on behalf of Radia Perlman Sent: Sat 4/5/2008 6:05 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] (slight) modification of how to choose mulitcast trees I don't understand. What do you mean by "mandated"? Do you mean "recommended default=1"? That probably wouldn't be controversial. But if you mean "mandated" as in, "only do one tree" (which was my original assumption, by the way), I'm sure that would be controversial. I'm almost certain you meant "recommended default=1", rather than "mandate one tree" but it would be good to clarify what you meant. Radia Anoop Ghanwani wrote: > I would go even further and say that 1 tree is what > should be mandated. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt >> Sent: Tuesday, April 01, 2008 9:33 PM >> To: Eastlake III Donald-LDE008 >> Cc: Developing a hybrid router/bridge.; Radia Perlman >> Subject: Re: [rbridge] (slight) modification of how to choose >> mulitcast trees >> >> Why 8 ? I prefer something much less. But again, this isn't >> something I'd debate much about. Priority will be configured >> as users want predictablity and determinism. >> >> Dinesh >> Eastlake III Donald-LDE008 wrote: >> >>> Hi, >>> >>> See below at @@@ >>> >>> -----Original Message----- >>> From: Dinesh G Dutt [mailto:ddutt at cisco.com] >>> Sent: Tuesday, April 01, 2008 >>> To: Radia Perlman >>> Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. >>> Subject: Re: [rbridge] (slight) modification of how to choose >>> mulitcast trees >>> >>> Slight modification. I'd want the default to be smaller, >>> >> say 2 or 4. >> >>> But >>> >>> I won't quibble, >>> >>> Dinesh >>> >>> I agree with you Radia on both points, >>> >>> Dinesh >>> >>> Radia Perlman wrote: >>> >>> >>>> My only 2 comments on your comments: >>>> a) I don't see how there can be a default of square root >>>> >> of number of >> >>>> RBridges, since RBridges wouldn't know the number of >>>> >> bridges. I'd say >> >>>> we should pick a number like "10". >>>> >>>> >>> @@@ OK, so let's go with a recommended default of 8. >>> >>> >>> >>>> b) Sorry -- need to "think aloud" here for a bit. >>>> A few questions about "order": "ports" is known in advance and >>>> doesn't >>>> >>>> >>> >>> >>>> change. "adjacencies" is not known in advance . >>>> But then you really want "RBridge adjacencies" and not >>>> >> just ports to >> >>>> endnodes...so I'm not sure. Maybe it has to be "RBridge >>>> >> adjacencies". >> >>>> But does having a fluctuating "order" cause problems? In theory we >>>> might want a pseudonode to be a tree root, but pseudonodes >>>> >> don't get >> >>>> nicknames, and therefore can't be specified as a tree root in the >>>> TRILL header. >>>> >>>> And then using numerically largest works for "order" but not for >>>> "distance to me", so that has to be adjusted (shouldn't be hard, >>>> >>>> >>> perhaps >>> >>> >>>> making "order" be 1000 minus the number of RBridge >>>> >> adjacencies, going >> >>>> >>>> >>> no >>> >>> >>>> lower than "0"). And "order" can be calculated from the LSP -- it >>>> doesn't have to be separately announced. Though if you >>>> >>>> >>> are >>> >>> >>>> connected to a pseudonode do you have to remember to count all the >>>> RBridges connected to that pseudonode? >>>> >>>> It might be simpler to just have "order" feed into >>>> >> priority, as in, >> >>>> if >>>> >>>> >>> >>> >>>> your priority is not configured in advance, then if you have more >>>> than some number (say 2) RBridge adjacencies, you decrement your >>>> priority by 1 for every extra RBridge adjacency. If your >>>> >> priority is >> >>>> configured, you'd leave it at whatever it is configured to >>>> >>>> >>> be. >>> >>> @@@ I'm fine with order feeding into priority in some >>> >> fashion if your >> >>> priority is not configured. People who are configuring >>> >> ought to know >> >>> what they are doing and avoid ties. >>> >>> @@@ Thanks, >>> @@@ Donald >>> >>> >>> >>>> Radia >>>> >>>> >>>> >>>> >>>> Eastlake III Donald-LDE008 wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I agree that the present requirement that all Rbridges default to >>>>> >>>>> >>> having >>> >>> >>>>> the RequestTree be TRUE probably results in Rbridges >>>>> >> being required >> >>>>> >>>>> >>> to >>> >>> >>>>> calculate too many trees in a large campus. See comments below at >>>>> @@@ >>>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces at postel.org >>>>> >> [mailto:rbridge-bounces at postel.org] >> >>>>> >>>>> >>> On >>> >>> >>>>> Behalf Of Radia Perlman >>>>> Sent: Friday, March 28, 2008 10:55 PM >>>>> To: Developing a hybrid router/bridge. >>>>> Subject: [rbridge] (slight) modification of how to choose >>>>> >> mulitcast >> >>>>> trees >>>>> >>>>> Dinesh suggested the following, as a way of making configuration >>>>> >>>>> >>> easier >>> >>> >>>>> for how to choose multicast trees. >>>>> >>>>> 1) Each RBridge is configured with a priority for being >>>>> >> selected a >> >>>>> multicast tree root (with of course a default being a medium >>>>> >>>>> >>> priority) >>> >>> >>>>> 2) Each RBridge R1 is also configured with a parameter indicating >>>>> >>>>> >>> "total >>> >>> >>>>> number of trees in the campus", which R1 announces in its LSP. >>>>> >>>>> @@@ So what's the recommended default here? It might >>>>> >> sound a bit odd >> >>>>> >>>>> >>> but >>> >>> >>>>> I would suggest that the default be something like the >>>>> >> square root >> >>>>> of the number of Rbridges in the campus. (See comment below on >>>>> >>>>> >>> volatility.) >>> >>> >>>>> 3) RBridges are ranked by (priority, ID). The RBridge with the >>>>> numerically lowest priority, and then numerically lowest ID being >>>>> the tie breaker, dictates the total number of trees all the other >>>>> >>>>> >>> RBridges >>> >>> >>>>> must calculate (the number that R1 announces in its LSP >>>>> >> according to >> >>>>> rule 2 above. >>>>> >>>>> @@@ As long as you are generating a concatenated global priority >>>>> >>>>> >>> number >>> >>> >>>>> like (priority, ID), why not make it a little more clever >>>>> >> by having >> >>>>> >>>>> >>> it >>> >>> >>>>> be (priority, order, ID) or something like that? (Where "order" is >>>>> >>>>> >>> the >>> >>> >>>>> number of adjacencies the Rbridge has, so you'd have to >>>>> >> change the >> >>>>> ranking to be highest priority is numerically largest...). >>>>> >>>>> 4) An RBridge calculates n distribution trees, where n is >>>>> >> the number >> >>>>> announced by the lowest (priority, ID) RBridge R1, in >>>>> >> R1's LSP, as >> >>>>> the "total number of trees". The n trees computed are the ones >>>>> >>>>> >>> using >>> >>> >>>>> the n numerically lowest (priority, ID) RBridges as roots >>>>> >>>>> 5) if RB1 is ingress RBridge on port p, and (*note >>>>> >> another parameter >> >>>>> "k"*) is configured to do k-way path splitting on that port for >>>>> multidestination frames, the k tree roots that RB1 >>>>> >> chooses consist >> >>>>> of >>>>> >>>>> >>> >>> >>>>> the three for which the triple "(cost of root to me, >>>>> >> priority, ID)" >> >>>>> >>>>> >>> are >>> >>> >>>>> the k smallest. >>>>> >>>>> @@@ Of course the ranking has to be the same so if "order" were >>>>> added >>>>> >>>>> >>> as >>> >>> >>>>> above, it would have to be added here also. >>>>> >>>>> Intuition: suppose there is a topology with a lot of "leaf" >>>>> >>>>> >>> RBridges., >>> >>> >>>>> and "next level" RBridges that the leaf RBridges connect to. >>>>> If there are m leaf RBridges connected to next level RBridge RBx, >>>>> >>>>> >>> then >>> >>> >>>>> there is no reason to compute trees with any of the leaf >>>>> >> RBridges as >> >>>>> root -- the tree rooted at RBx will be the same tree, and >>>>> >>>>> >>> >>> >>>>> will indeed be a shortest path tree for each of the attached leaf >>>>> RBridges. If a leaf RBridge is attached to several next-level >>>>> RBridges, the most significant number in the triple -- >>>>> >> "cost of root >> >>>>> to me" will cause the leaf RBridge to multipath the multicast >>>>> >>>>> >>> >>> >>>>> among multiple shortest-path trees. >>>>> >>>>> @@@ That's all true but the special case of an Rbridge of order 1 >>>>> connected to an Rbridge of order >1 seems so simple to check for >>>>> that you could just rule them out. Or, if "order" were >>>>> >> added to the >> >>>>> comparison tuple as above, in the default case where all Rbridges >>>>> >>>>> >>> have >>> >>> >>>>> the default priority, order 1 Rbridges would automatically have >>>>> >>>>> >>> lowest >>> >>> >>>>> priority. (See also slides 8 and 9 of my presentation at >>>>> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.) >>>>> >>>>> This seems completely safe, and easier than configuring, for each >>>>> RBridge, the set of root RBridges to choose for multicast >>>>> >> tree roots. >> >>>>> It also means that you can configure in one place a total >>>>> >> number of >> >>>>> roots, rather than possibly having too many RBridges >>>>> >> volunteer for >> >>>>> being tree roots, and winding up with too much overhead >>>>> >> on RBridges >> >>>>> because they'll have to compute a tree for every RBridge >>>>> >> that says >> >>>>> it will want to be a tree root. >>>>> >>>>> There might be a concern about volatility -- when an RBridge with >>>>> numerically low priority goes down, it might cause: >>>>> a) a change to the total number of trees to be computed >>>>> >> by everyone >> >>>>> (since the next best might be configured with a different number) >>>>> b) a change to the list of "tree roots I will choose" announced by >>>>> >>>>> >>> RB2 >>> >>> >>>>> when one of the roots for the k best (cost to me, >>>>> >> priority, ID) goes >> >>>>> down. >>>>> >>>>> @@@ There are plenty of other possible causes for >>>>> >> volatility. Like a >> >>>>> high priority-to-be-tree-root Rbridge coming up or an Rbridge's >>>>> priority-to-be-tree-root being reconfigured. But the solution to >>>>> them all is the same. An Rbridge has to keep calculating (or at >>>>> least keep >>>>> around) trees for old roots as long as their reasonably might be >>>>> >>>>> >>> frames >>> >>> >>>>> in transit specifying those roots. It has to calculate >>>>> >> trees for any >> >>>>> >>>>> >>> new >>> >>> >>>>> roots right away and, if appropriate, start advertising that it >>>>> might use them. What root (or from what set of roots) to >>>>> >> choose for >> >>>>> new >>>>> >>>>> >>> native >>> >>> >>>>> multi-destination frames an Rbridge is encapsulating is a bit >>>>> >>>>> >>> messier. >>> >>> >>>>> Seems to me that until it is reasonably sure that information has >>>>> propagated concerning new roots, it should only use those in the >>>>> intersection of the sets of old and new roots. If that >>>>> >> intersection >> >>>>> >>>>> >>> is >>> >>> >>>>> null, something only likely to occur when there are a very small >>>>> >>>>> >>> number >>> >>> >>>>> of tree roots, you have a bit of a problem and might as >>>>> >> well use the >> >>>>> >>>>> >>> new >>> >>> >>>>> root(s). But this is no worse than under the previous scheme if >>>>> RequestTree was FALSE for all Rbridges and the Rbridge with the >>>>> >>>>> >>> lowest >>> >>> >>>>> system ID, which had defaulted to being the only tree root, goes >>>>> >>>>> >>> down. >>> >>> >>>>> Other than that, I can't think of any possible problems. >>>>> >>>>> @@@ Overall, I like the proposal. >>>>> >>>>> Radia >>>>> >>>>> @@@ Thanks, >>>>> @@@ Donald >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> >>> >>> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080406/0ef48ba0/attachment-0001.html From Donald.Eastlake at motorola.com Sun Apr 6 20:49:16 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 6 Apr 2008 23:49:16 -0400 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47F30C6D.8080605@cisco.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com> <3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> <47F30C6D.8080605@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8BC5@de01exm64.ds.mot.com> Hi, On "Why 8", or really why >1, as the recommended default number of distribution trees, my answer is as follows: Having more than one distribution tree has a bunch of benefits. + It probabilistically reduces the concentration of multi-destination traffic onto particular links and increases the aggregate capacity for them in much the same way that using IS-IS does in comparison with spanning tree. + By choosing a tree rooted nearby when you are encapsulating an unknown unicast frame, you reduce the probability of mis-ordering frames when the address become known. (In the limit, if you root a tree for every node, the probability of mis-ordering becomes very small.) + Finally, unless you do a tree for every node, there are things that can happen which will change the set of tree calculated. This can include nodes going down, coming up, having their priority or RequestTree flag or whatever you are using reconfigured, etc. If you have only one tree, you are guaranteed that when that one tree changes all multi-destination frames in flight now refer to a tree that is no longer supposed to be computed and all newly encapsulated frames need to refer to a new frame which may not yet have been calculated. Most methods of automatically choosing which nodes to use as tree roots are designed to be reasonably stable so the probability is low that the entire set of tree would change even if that set has only a few members. In fact, if you are calculating k trees, most commonly only 1 would lose its must-be-calculated status and k-1 would remain. Thus it is more likely that, after a change in the tree set, frames in flight still refer to trees that are being calculated. And it would be a reasonable strategy to, for a short time, use trees in the intersection of the old and new sets when frames are newly encapsulated so as to make it highly probably that nodes forwarding such frames will already have computed a tree for the root specified. The more tree the better, according to the above factors. So what's the disadvantage of having many distribution trees? There is no effect on the size of the link state database or volume of routing information. It's really just a local computational cost. Assuming building a tree with n nodes and L pair wise links, the effort is proportional to L + n*(log n). Thus building one for every node would be n*(L + n*(log n)) or n*L + (n**2)*(log n) effort. This is certainly a bit daunting for large n. So we seem to be looking for some k, the recommended default number of trees, such that k*(L + n*(log n)) is tolerable. Actually, in order to perform unicast forwarding, each node needs to, in effect, compute a tree rooted on itself. So it has to do n*(log n) even if there are zero multi-destination trees. So we are looking for a recommended default number of trees k such that (k+1)*(L + n*(log n)) is tolerable. (These are all approximations.) Numbers that have been suggested for k are 1, 2, 4, 8, and 10. I don't think that we have the data or the scoring criteria to calculate an optimal value. I think TRILL should be aiming several years out when Moore's law will have had further effect. People in the ISIS working group keep saying that Dijkstra calculations are cheap can be done quickly. Even with only one distribution tree, you still have to actually calculate two trees because you need, in effect, a self rooted one for unicast. While I certainly don't want to make the argument that if you can do N, you should be able to do N+1, and thus by induction could do an unbounded number, still, it seems to me that if you have to calculate at least 2 tree, making the recommended default 2 or 4 (i.e., so you end up calculating 3 or 5 distribution trees) just shouldn't be that hard and yields considerable benefits in multi-destination traffic capacity, reduced mis-ordering, and increased stability due to trees that remain valid across typical changes in the set of distribution trees to calculate. I still think 8 is reasonable and I don't see why you would set k to 1 unless you wanted to restrict the default campus performance for multi-destination traffic to be no better than that of bridges with a single spanning tree. Thanks, Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Wednesday, April 02, 2008 12:33 AM To: Eastlake III Donald-LDE008 Cc: Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] (slight) modification of how to choose mulitcast trees Why 8 ? I prefer something much less. But again, this isn't something I'd debate much about. Priority will be configured as users want predictablity and determinism. Dinesh Eastlake III Donald-LDE008 wrote: > Hi, > > See below at @@@ > > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Tuesday, April 01, 2008 > To: Radia Perlman > Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. > Subject: Re: [rbridge] (slight) modification of how to choose mulitcast > trees > > Slight modification. I'd want the default to be smaller, say 2 or 4. But > > I won't quibble, > > Dinesh > > I agree with you Radia on both points, > > Dinesh > > Radia Perlman wrote: > >> My only 2 comments on your comments: >> a) I don't see how there can be a default of square root of number of >> RBridges, since RBridges wouldn't know the number >> of bridges. I'd say we should pick a number like "10". > > @@@ OK, so let's go with a recommended default of 8. > >> b) Sorry -- need to "think aloud" here for a bit. >> A few questions about "order": "ports" is known in advance and doesn't >> change. "adjacencies" is not known in advance . >> But then you really want "RBridge adjacencies" and not just ports to >> endnodes...so I'm not sure. Maybe >> it has to be "RBridge adjacencies". But does having a fluctuating >> "order" cause problems? In theory we might want a pseudonode >> to be a tree root, but pseudonodes don't get nicknames, and therefore >> can't be specified as a tree root in the TRILL header. >> >> And then using numerically largest works for "order" but not for >> "distance to me", so that has to be adjusted (shouldn't be hard, perhaps >> making "order" be 1000 minus the number of RBridge adjacencies, going no >> lower than "0"). And "order" can be calculated from >> the LSP -- it doesn't have to be separately announced. Though if you are >> connected to a pseudonode do you have to remember >> to count all the RBridges connected to that pseudonode? >> >> It might be simpler to just have "order" feed into priority, as in, if >> your priority is not configured in advance, then if you have more >> than some number (say 2) RBridge adjacencies, you decrement your >> priority by 1 for every extra RBridge adjacency. If your >> priority is configured, you'd leave it at whatever it is configured to be. > > @@@ I'm fine with order feeding into priority in some fashion if your > priority is not configured. People who are configuring ought to know > what they are doing and avoid ties. > > @@@ Thanks, > @@@ Donald > >> Radia From sgai at nuovasystems.com Mon Apr 7 07:01:35 2008 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 7 Apr 2008 07:01:35 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8BC5@de01exm64.ds.mot.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com><47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com><3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com><47F30C6D.8080605@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8BC5@de01exm64.ds.mot.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA203C0F591@nuova-ex1.hq.nuovaimpresa.com> 8 is too much, I will prefer 1, I can accept 2. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Sunday, April 06, 2008 8:49 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] (slight) modification of how to choose mulitcast > trees > > Hi, > > On "Why 8", or really why >1, as the recommended default number of > distribution trees, my answer is as follows: > > Having more than one distribution tree has a bunch of benefits. > + It probabilistically reduces the concentration of multi-destination > traffic onto particular links and increases the aggregate capacity for > them in much the same way that using IS-IS does in comparison with > spanning tree. > + By choosing a tree rooted nearby when you are encapsulating an > unknown unicast frame, you reduce the probability of mis-ordering frames > when the address become known. (In the limit, if you root a tree for > every node, the probability of mis-ordering becomes very small.) > + Finally, unless you do a tree for every node, there are things that > can happen which will change the set of tree calculated. This can > include nodes going down, coming up, having their priority or > RequestTree flag or whatever you are using reconfigured, etc. If you > have only one tree, you are guaranteed that when that one tree changes > all multi-destination frames in flight now refer to a tree that is no > longer supposed to be computed and all newly encapsulated frames need to > refer to a new frame which may not yet have been calculated. Most > methods of automatically choosing which nodes to use as tree roots are > designed to be reasonably stable so the probability is low that the > entire set of tree would change even if that set has only a few members. > In fact, if you are calculating k trees, most commonly only 1 would lose > its must-be-calculated status and k-1 would remain. Thus it is more > likely that, after a change in the tree set, frames in flight still > refer to trees that are being calculated. And it would be a reasonable > strategy to, for a short time, use trees in the intersection of the old > and new sets when frames are newly encapsulated so as to make it highly > probably that nodes forwarding such frames will already have computed a > tree for the root specified. > > The more tree the better, according to the above factors. So what's the > disadvantage of having many distribution trees? There is no effect on > the size of the link state database or volume of routing information. > It's really just a local computational cost. Assuming building a tree > with n nodes and L pair wise links, the effort is proportional to L + > n*(log n). Thus building one for every node would be n*(L + n*(log n)) > or n*L + (n**2)*(log n) effort. This is certainly a bit daunting for > large n. So we seem to be looking for some k, the recommended default > number of trees, such that k*(L + n*(log n)) is tolerable. Actually, in > order to perform unicast forwarding, each node needs to, in effect, > compute a tree rooted on itself. So it has to do n*(log n) even if there > are zero multi-destination trees. So we are looking for a recommended > default number of trees k such that (k+1)*(L + n*(log n)) is tolerable. > (These are all approximations.) > > Numbers that have been suggested for k are 1, 2, 4, 8, and 10. I don't > think that we have the data or the scoring criteria to calculate an > optimal value. I think TRILL should be aiming several years out when > Moore's law will have had further effect. People in the ISIS working > group keep saying that Dijkstra calculations are cheap can be done > quickly. Even with only one distribution tree, you still have to > actually calculate two trees because you need, in effect, a self rooted > one for unicast. While I certainly don't want to make the argument that > if you can do N, you should be able to do N+1, and thus by induction > could do an unbounded number, still, it seems to me that if you have to > calculate at least 2 tree, making the recommended default 2 or 4 (i.e., > so you end up calculating 3 or 5 distribution trees) just shouldn't be > that hard and yields considerable benefits in multi-destination traffic > capacity, reduced mis-ordering, and increased stability due to trees > that remain valid across typical changes in the set of distribution > trees to calculate. I still think 8 is reasonable and I don't see why > you would set k to 1 unless you wanted to restrict the default campus > performance for multi-destination traffic to be no better than that of > bridges with a single spanning tree. > > Thanks, > Donald > > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, April 02, 2008 12:33 AM > To: Eastlake III Donald-LDE008 > Cc: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] (slight) modification of how to choose mulitcast > trees > > Why 8 ? I prefer something much less. But again, this isn't something > I'd debate much about. Priority will be configured as users want > predictablity and determinism. > > Dinesh > Eastlake III Donald-LDE008 wrote: > > Hi, > > > > See below at @@@ > > > > -----Original Message----- > > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > > Sent: Tuesday, April 01, 2008 > > To: Radia Perlman > > Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] (slight) modification of how to choose > mulitcast > > trees > > > > Slight modification. I'd want the default to be smaller, say 2 or 4. > But > > > > I won't quibble, > > > > Dinesh > > > > I agree with you Radia on both points, > > > > Dinesh > > > > Radia Perlman wrote: > > > >> My only 2 comments on your comments: > >> a) I don't see how there can be a default of square root of number of > > >> RBridges, since RBridges wouldn't know the number > >> of bridges. I'd say we should pick a number like "10". > > > > @@@ OK, so let's go with a recommended default of 8. > > > >> b) Sorry -- need to "think aloud" here for a bit. > >> A few questions about "order": "ports" is known in advance and > doesn't > >> change. "adjacencies" is not known in advance . > >> But then you really want "RBridge adjacencies" and not just ports to > >> endnodes...so I'm not sure. Maybe > >> it has to be "RBridge adjacencies". But does having a fluctuating > >> "order" cause problems? In theory we might want a pseudonode > >> to be a tree root, but pseudonodes don't get nicknames, and therefore > > >> can't be specified as a tree root in the TRILL header. > >> > >> And then using numerically largest works for "order" but not for > >> "distance to me", so that has to be adjusted (shouldn't be hard, > perhaps > >> making "order" be 1000 minus the number of RBridge adjacencies, going > no > >> lower than "0"). And "order" can be calculated from > >> the LSP -- it doesn't have to be separately announced. Though if you > are > >> connected to a pseudonode do you have to remember > >> to count all the RBridges connected to that pseudonode? > >> > >> It might be simpler to just have "order" feed into priority, as in, > if > >> your priority is not configured in advance, then if you have more > >> than some number (say 2) RBridge adjacencies, you decrement your > >> priority by 1 for every extra RBridge adjacency. If your > >> priority is configured, you'd leave it at whatever it is configured > to be. > > > > @@@ I'm fine with order feeding into priority in some fashion if your > > priority is not configured. People who are configuring ought to know > > what they are doing and avoid ties. > > > > @@@ Thanks, > > @@@ Donald > > > >> Radia > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Mon Apr 7 08:04:27 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 07 Apr 2008 08:04:27 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8BC5@de01exm64.ds.mot.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> <47EFD523.4000303@sun.com> <47F2E4A8.7010200@cisco.com> <3870C46029D1F945B1472F170D2D979003A95C95@de01exm64.ds.mot.com> <47F30C6D.8080605@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8BC5@de01exm64.ds.mot.com> Message-ID: <47FA37FB.1070402@cisco.com> Donald, We're talking about defaults here, not what is the maximum. I hear your arguments but 8 is too much for smaller networks. I know of one large customer who's thinking of 16, but most prefer 2-4. Dinesh Eastlake III Donald-LDE008 wrote: > Hi, > > On "Why 8", or really why >1, as the recommended default number of > distribution trees, my answer is as follows: > > Having more than one distribution tree has a bunch of benefits. > + It probabilistically reduces the concentration of multi-destination > traffic onto particular links and increases the aggregate capacity for > them in much the same way that using IS-IS does in comparison with > spanning tree. > + By choosing a tree rooted nearby when you are encapsulating an > unknown unicast frame, you reduce the probability of mis-ordering frames > when the address become known. (In the limit, if you root a tree for > every node, the probability of mis-ordering becomes very small.) > + Finally, unless you do a tree for every node, there are things that > can happen which will change the set of tree calculated. This can > include nodes going down, coming up, having their priority or > RequestTree flag or whatever you are using reconfigured, etc. If you > have only one tree, you are guaranteed that when that one tree changes > all multi-destination frames in flight now refer to a tree that is no > longer supposed to be computed and all newly encapsulated frames need to > refer to a new frame which may not yet have been calculated. Most > methods of automatically choosing which nodes to use as tree roots are > designed to be reasonably stable so the probability is low that the > entire set of tree would change even if that set has only a few members. > In fact, if you are calculating k trees, most commonly only 1 would lose > its must-be-calculated status and k-1 would remain. Thus it is more > likely that, after a change in the tree set, frames in flight still > refer to trees that are being calculated. And it would be a reasonable > strategy to, for a short time, use trees in the intersection of the old > and new sets when frames are newly encapsulated so as to make it highly > probably that nodes forwarding such frames will already have computed a > tree for the root specified. > > The more tree the better, according to the above factors. So what's the > disadvantage of having many distribution trees? There is no effect on > the size o