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 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 > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From sgai at nuovasystems.com Mon Apr 7 09:45:07 2008 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 7 Apr 2008 09:45:07 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47FA37FB.1070402@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><3870C46029D1F945B1472F170D2D979003AD8BC5@de01exm64.ds.mot.com> <47FA37FB.1070402@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA203C0F6D9@nuova-ex1.hq.nuovaimpresa.com> I agree with Dinesh, we are discussing the default. One should be the default, you can config as high as you like -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Monday, April 07, 2008 8:04 AM > To: Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] (slight) modification of how to choose mulitcast > trees > > 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 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 > > > > > > -- > 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 Donald.Eastlake at motorola.com Mon Apr 7 13:36:54 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 7 Apr 2008 16:36:54 -0400 Subject: [rbridge] Consensus Check: Critical Option Summary Bits In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8F8A@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* Leave the provisions in the base protocol (version 07) draft for critical option summary bits if the options area has non-zero length and leave further details about options to another document or documents. 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 Mon Apr 7 13:41:07 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 7 Apr 2008 16:41:07 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* The TRILL Base Protocol draft should only mention and use IEEE 802.1 C-tags. It should not mention or use S-tags, except possibly to distinguish them from C-tags, state that they are not used, or the like. 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 ddutt at cisco.com Mon Apr 7 14:18:12 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 07 Apr 2008 14:18:12 -0700 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> Message-ID: <47FA8F94.9060906@cisco.com> Why did we decide this ? Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Philadelphia meeting: > > > ******* The TRILL Base Protocol draft should only mention and use IEEE > 802.1 C-tags. It should not mention or use S-tags, except possibly to > distinguish them from C-tags, state that they are not used, or the like. > > > 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 > > _______________________________________________ > 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 Mon Apr 7 14:35:41 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 7 Apr 2008 17:35:41 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <47FA8F94.9060906@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FA8F94.9060906@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD8FE5@de01exm64.ds.mot.com> In short, read the minutes: http://www.ietf.org/proceedings/08mar/minutes/trill.txt At slightly greater length: I brought up the change that Q-tag had been replaced by C-tag in the protocol draft, which I thought was purely editorial. This lead to a bunch of discussion which Erik and I judge to have produced this consensus at the meeting. Thanks, Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Monday, April 07, 2008 5:18 PM To: Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: C-Tags Why did we decide this ? Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Philadelphia meeting: > > > ******* The TRILL Base Protocol draft should only mention and use IEEE > 802.1 C-tags. It should not mention or use S-tags, except possibly to > distinguish them from C-tags, state that they are not used, or the like. > > > 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 > > _______________________________________________ > 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 Caitlin.Bestler at neterion.com Mon Apr 7 15:03:03 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 7 Apr 2008 18:03:03 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <47FA8F94.9060906@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FA8F94.9060906@cisco.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703564272@nekter> > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Monday, April 07, 2008 2:18 PM > To: Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: C-Tags > > Why did we decide this ? > I wasn't present, but the most obvious reason is that a forwarding database that supported both C-Tags and S-Tags would be unpleasantly complicated. From james.d.carlson at sun.com Mon Apr 7 14:44:23 2008 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 7 Apr 2008 17:44:23 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <47FA8F94.9060906@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FA8F94.9060906@cisco.com> Message-ID: <18426.38327.532188.999945@gargle.gargle.HOWL> Dinesh G Dutt writes: > Why did we decide this ? S-tags are for provider backbone bridges (802.1AH), and we won't have support for service instances. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Mon Apr 7 18:25:57 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 07 Apr 2008 18:25:57 -0700 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> Message-ID: <47FAC9A5.5080905@cisco.com> I'm fine with stating only about C-tags and not mention anything about S-tags. I wouldn't want the spec to explicitly prohibit the use of S-tags. Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Philadelphia meeting: > > > ******* The TRILL Base Protocol draft should only mention and use IEEE > 802.1 C-tags. It should not mention or use S-tags, except possibly to > distinguish them from C-tags, state that they are not used, or the like. > > > 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 > > _______________________________________________ > 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 Caitlin.Bestler at neterion.com Mon Apr 7 18:59:10 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 7 Apr 2008 21:59:10 -0400 Subject: [rbridge] Consensus Check: C-Tags References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FAC9A5.5080905@cisco.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C134@nekter> -----Dinesh Dutt wrote ---- Sent: Mon 4/7/2008 6:25 PM Subject: Re: [rbridge] Consensus Check: C-Tags I'm fine with stating only about C-tags and not mention anything about S-tags. I wouldn't want the spec to explicitly prohibit the use of S-tags. ---------------------------- Nothing constricts the 802.1 service that an RBridge uses to access a given LAN (and its VLANs). The actual physical port could use S-Tags, just as long as the RBridge does not. But within the RBridge itself, its Forward Databases and the information shared between RBridges, I don't see how you can mix C-Tag and S-Tag domains without requiring *every* RBridge to fully understand Provider Backbones. I don't see any benefit for that even approaches the complexity required. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080407/bcadc45e/attachment.html From Donald.Eastlake at motorola.com Mon Apr 7 19:16:08 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 7 Apr 2008 22:16:08 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <47FAC9A5.5080905@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FAC9A5.5080905@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> Hi Dinesh, I'm not sure exactly what you mean by "explicitly prohibit the use of S-tags" but wherever the protocol spec requires a VLAN tag (Outer or Inner), it currently specifies the use of the C-tag Ethertype. It is my impression that people are thinking that the current protocol spec is for customer Rbridges and that, perhaps, at some point in the future a separate "provider Rbridge" document could be written which talks about S-tags, etc. Thanks, Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Monday, April 07, 2008 9:26 PM To: Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: C-Tags I'm fine with stating only about C-tags and not mention anything about S-tags. I wouldn't want the spec to explicitly prohibit the use of S-tags. Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Philadelphia meeting: > > > ******* The TRILL Base Protocol draft should only mention and use IEEE > 802.1 C-tags. It should not mention or use S-tags, except possibly to > distinguish them from C-tags, state that they are not used, or the like. > > > 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 > > _______________________________________________ > 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 eric.gray at ericsson.com Tue Apr 8 05:31:22 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 07:31:22 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> As a response to the general question - together with a response to the follow-on response so far - I would like to make the following points: 1) I am very uncomfortable with explicitly limiting the applicability of RBridges to the case where "Enterprise" is defined specifically to exclude service provider networks (remember that an SP is also an "Enterprise" - unless explicitly excluded). 2) I agree with Dinesh that we should not explicitly exclude S-TAGs, even though it is (as Donald points out) necessary to be specific in a protocol specification. A key reason for this is that - in the case where a SP might want to use RBridges to support their own use of an Ethernet (or Ethernet-like) infratructure (which very-well might include both C-TAGs and S-TAGs). 3) One way to get around this is to state - up-front - that the use of C-TAGs is assumed in the protocol specification, but there is no intention to prohibit use of S-TAGs, and probably further say that any additional specification required to support S-TAGs is out of scope in this protocol specification. 4) The concerns expressed by Caitlin are not - and should not be - relevant to the protocol specification (especailly if scoped as I suggest above), since they are very explicitly related to an implementation (or assumptions about implementations) that may not be true for every implementation, and could very well be avoided entirely by simply making the implementation choice to onyl support C-TAGs. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Monday, April 07, 2008 10:16 PM > To: Dinesh G Dutt > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: C-Tags > > Hi Dinesh, > > I'm not sure exactly what you mean by "explicitly prohibit the use of > S-tags" but wherever the protocol spec requires a VLAN tag (Outer or > Inner), it currently specifies the use of the C-tag Ethertype. > > It is my impression that people are thinking that the current protocol > spec is for customer Rbridges and that, perhaps, at some point in the > future a separate "provider Rbridge" document could be written which > talks about S-tags, etc. > > Thanks, > Donald > > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Monday, April 07, 2008 9:26 PM > To: Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: C-Tags > > I'm fine with stating only about C-tags and not mention > anything about > S-tags. I wouldn't want the spec to explicitly prohibit the use of > S-tags. > > Dinesh > Eastlake III Donald-LDE008 wrote: > > This is a check via the mailing list to confirm or refute > an apparent > > consensus at the Philadelphia meeting: > > > > > > ******* The TRILL Base Protocol draft should only mention > and use IEEE > > 802.1 C-tags. It should not mention or use S-tags, except > possibly to > > distinguish them from C-tags, state that they are not used, or the > like. > > > > > > 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 > > > > _______________________________________________ > > 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 Caitlin.Bestler at neterion.com Tue Apr 8 07:57:11 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 8 Apr 2008 10:57:11 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703564444@nekter> Eric Gray wrote: > As a response to the general question - together with a response to > the follow-on response so far - I would like to make the following > points: > > 1) I am very uncomfortable with explicitly limiting the applicability > of RBridges to the case where "Enterprise" is defined specifically > to exclude service provider networks (remember that an SP is also > an "Enterprise" - unless explicitly excluded). > 2) I agree with Dinesh that we should not explicitly exclude S-TAGs, > even though it is (as Donald points out) necessary to be specific > in a protocol specification. A key reason for this is that - in > the case where a SP might want to use RBridges to support their > own use of an Ethernet (or Ethernet-like) infratructure (which > very-well might include both C-TAGs and S-TAGs). > 3) One way to get around this is to state - up-front - that the use > of C-TAGs is assumed in the protocol specification, but there is > no intention to prohibit use of S-TAGs, and probably further say > that any additional specification required to support S-TAGs is > out of scope in this protocol specification. > 4) The concerns expressed by Caitlin are not - and should not be - > relevant to the protocol specification (especailly if scoped as > I suggest above), since they are very explicitly related to an > implementation (or assumptions about implementations) that may > not be true for every implementation, and could very well be > avoided entirely by simply making the implementation choice to > onyl support C-TAGs. A set of RBridges collectively implement a single distributed database of VLAN IDs and end station addresses (FID + MAC Address). Depending on what semantics are expected with "supporting S-Tags" that means that the VLAN IDs being tracked either become 13 or 24 bits rather than 12. Because this information is shared it is *not* limited to any single implementation unless there is a clear definition that allows RBRidges to be explicitly customer scoped, and only the "Provider RBridges" would have to deal with the issues of S-Tags. Stating that for *this* document, the only form of Q-Tag supported is a C-Tag does that. And yes, somebody could define how a Provider RBridge would work in a separate document. From james.d.carlson at sun.com Tue Apr 8 07:23:33 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 8 Apr 2008 10:23:33 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> Message-ID: <18427.32741.585320.43032@gargle.gargle.HOWL> Eric Gray writes: > 3) One way to get around this is to state - up-front - that the use > of C-TAGs is assumed in the protocol specification, but there is > no intention to prohibit use of S-TAGs, and probably further say > that any additional specification required to support S-TAGs is > out of scope in this protocol specification. It sounds like we're in violent agreement: this specification uses C-tags, and S-tags are just out of scope. A future document might address them. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From eric.gray at ericsson.com Tue Apr 8 09:27:51 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 11:27:51 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18427.32741.585320.43032@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com><3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <18427.32741.585320.43032@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1D27@eusrcmw721.eamcs.ericsson.se> James, Not exactly. It is my opinion that support for the use of S-TAGs _requires_ no further specification. Consider the following quote from 802.1Q-2006: "The semantics and structure of the S-TAG is identical to that of the C-TAG, with the exception that bit 5 in octet 1, the Drop Eligible Indicator (DEI) bit, does not convey a CFI (9.6). The priority and drop_eligible parameters are conveyed in the 3-bit PCP field and the DEI bit as specified in 6.7.3." Given this description of the differences between C-TAGs and S-TAGs, it seems quite reasonable to me to suppose that any one wanting to support S-TAGs should be able to without further specification in either the TRILL WG, or in the IETF. However, it is possible that additional specification may be needed. Any such additional specification could be treated as out of scope (for now). To tell the truth, I am unconvinced of the need to do that - but I can live with a WG decision to do so. But it is essentially wrong - IMHO - to assert that S-TAG use cannot be done without further specification. With this subtle distinction, we are probably otherwise in agreement. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, April 08, 2008 10:24 AM > To: Eric Gray > Cc: Eastlake III Donald-LDE008; Dinesh G Dutt; Caitlin > Bestler; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: C-Tags > Importance: High > > Eric Gray writes: > > 3) One way to get around this is to state - up-front - that the use > > of C-TAGs is assumed in the protocol specification, but there is > > no intention to prohibit use of S-TAGs, and probably further say > > that any additional specification required to support S-TAGs is > > out of scope in this protocol specification. > > It sounds like we're in violent agreement: this specification uses > C-tags, and S-tags are just out of scope. A future document might > address them. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > From eric.gray at ericsson.com Tue Apr 8 10:06:20 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 12:06:20 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703564444@nekter> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <78C9135A3D2ECE4B8162EBDCE82CAD7703564444@nekter> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1DB5@eusrcmw721.eamcs.ericsson.se> Caitlin, I think it is obvious that the issues you raise only exist if the protocol specification is already over-specifying details of TRILL's use of Ethernet as a transport mechanism. In other specifications - within the IETF - where we have needed to interface with Ethernet encapsulation, we have used a common "interface" model that allows implementations to use any form of defined Ethernet encapsulation available (provided they can conform at the protocol level with a common interface model). On the specific potential conflict instance you point out - i.e. - the possibility that an S-TAG may be associated with a larger number of VIDs than a C-TAG, I think you may be confusing S-TAGs with the combination of S-TAGs and I-TAGs (defined in IEEE 802.1ah - which is not yet a standard, though it soon will be). See the quote from 802.1Q-2006 that I provided in my response to James Carlson, to see why it is obvious that the actual S-TAG does not itself provide a larger VID space. I-TAGs are used in conjunction with S-TAGs only at the PBB ingress and egress (I-component, in IEEE-ese). It is possible that defining how an RBridge might also be an I-Component may require additional specification. I doubt it - but this may be the case if we over-specify requirements in TRILL for using any specific Ethernet technologies. Part of the reason I doubt further explicit specification is need in TRILL, is because the issue you are raising is not only limited to a specific implementation - it also would only apply to a specific deployment and configuration (i.e. - one in which 12 bits of VID is insufficient to provide unambiguous differentiation of backbone services using the S-TAG). Given that the size of a network (whether SP or Enterprise), for which this would be true, would probably overwhelm IS-IS routing scalability flat-out from the start, I question the reason why we should base our discussion on this case. In any case, the discussion is on whether or not S-TAGs should be explicitly disallowed in TRILL protocol specification - not whether or not PBB (802.1ah) should be. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] > Sent: Tuesday, April 08, 2008 10:57 AM > To: Eric Gray; Eastlake III Donald-LDE008; Dinesh G Dutt > Cc: Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: C-Tags > Importance: High > > Eric Gray wrote: > > > As a response to the general question - together with a response to > > the follow-on response so far - I would like to make the following > > points: > > > > 1) I am very uncomfortable with explicitly limiting the > applicability > > of RBridges to the case where "Enterprise" is defined > specifically > > to exclude service provider networks (remember that an SP is also > > an "Enterprise" - unless explicitly excluded). > > 2) I agree with Dinesh that we should not explicitly exclude S-TAGs, > > even though it is (as Donald points out) necessary to be specific > > in a protocol specification. A key reason for this is that - in > > the case where a SP might want to use RBridges to support their > > own use of an Ethernet (or Ethernet-like) infratructure (which > > very-well might include both C-TAGs and S-TAGs). > > 3) One way to get around this is to state - up-front - that the use > > of C-TAGs is assumed in the protocol specification, but there is > > no intention to prohibit use of S-TAGs, and probably further say > > that any additional specification required to support S-TAGs is > > out of scope in this protocol specification. > > 4) The concerns expressed by Caitlin are not - and should not be - > > relevant to the protocol specification (especailly if scoped as > > I suggest above), since they are very explicitly related to an > > implementation (or assumptions about implementations) that may > > not be true for every implementation, and could very well be > > avoided entirely by simply making the implementation choice to > > onyl support C-TAGs. > > A set of RBridges collectively implement a single distributed database > of VLAN IDs and end station addresses (FID + MAC Address). > > Depending on what semantics are expected with "supporting S-Tags" that > means that the VLAN IDs being tracked either become 13 or 24 bits > rather than 12. > > Because this information is shared it is *not* limited to any > single implementation unless there is a clear definition that > allows RBRidges to be explicitly customer scoped, and only the > "Provider RBridges" would have to deal with the issues of S-Tags. > > Stating that for *this* document, the only form of Q-Tag supported > is a C-Tag does that. And yes, somebody could define how a Provider > RBridge would work in a separate document. > > From eric.gray at ericsson.com Tue Apr 8 10:54:08 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 12:54:08 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18427.42721.339019.133334@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com><3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se><18427.32741.585320.43032@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF02CE1D27@eusrcmw721.eamcs.ericsson.se> <18427.42721.339019.133334@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1EF5@eusrcmw721.eamcs.ericsson.se> James, Perhaps the subtlety was lost on you, or perhaps I am reading something into the proposed consensus suggested by Donald. Part of what Donald proposed as a consensus was: "[The protocol specification] should not mention or use S-tags, except possibly to distinguish them from C-tags, state that they are not used, or the like." I believe it was the statement "they are not used" that formed the basis of Dinesh' comments: "Why did we decide this ?" - and - "I'm fine with stating only about C-tags and not mention anything about S-tags. I wouldn't want the spec to explicitly prohibit the use of S-tags." Donald responded to this with: "I'm not sure exactly what you mean by 'explicitly prohibit the use of S-tags' but wherever the protocol spec requires a VLAN tag (Outer or Inner), it currently specifies the use of the C-tag Ethertype. "It is my impression that people are thinking that the current protocol spec is for customer Rbridges and that, perhaps, at some point in the future a separate 'provider Rbridge' document could be written which talks about S-tags, etc." Hence the subtle issue is that - while I can agree with a statement that use of S-TAGs is out of scope in this version of the protocol specification - I agree with what I believe Dinesh was saying when he indicated that we should not prohibit use of S-TAGs in this specification by including a statement to the effect that S-TAGs are not used. Any statement such as "S-TAGs are not used" is innappropriate. Further, I suggested using a phrase to the effect that while the specification assumes use of C-TAGS, it does not explicitly prohibit the use of S-TAGs. While S-TAG use may be out of scope for this specification, it may or may not require further specification (which means it is also out-of-scope to make any assertion about whether, or not, additional specification is needed). -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, April 08, 2008 1:10 PM > To: Eric Gray > Cc: Eastlake III Donald-LDE008; Dinesh G Dutt; Caitlin > Bestler; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: C-Tags > Importance: High > > Eric Gray writes: > > However, it is possible that additional specification may > > be needed. Any such additional specification could be treated > > as out of scope (for now). To tell the truth, I am unconvinced > > of the need to do that - but I can live with a WG decision to > > do so. > > > > But it is essentially wrong - IMHO - to assert that S-TAG > > use cannot be done without further specification. > > Out of scope == not addressed by this specification. > > Once we've called it "out of scope," I don't really care whether an > additional document is _needed_ to complete that effort. I suspect > one will be needed, and you seem to be asserting that one will not, > but I also think that it's completely immaterial for this document. > > Ruling it out of scope means that we don't have to have the discussion > about what (if anything) to do about provider bridging _now_. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > From eric.gray at ericsson.com Tue Apr 8 10:57:20 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 12:57:20 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18426.38327.532188.999945@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FA8F94.9060906@cisco.com> <18426.38327.532188.999945@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se> James, As a not-so-subtle distinction, I-TAGs are used to identify service instances - not S-TAGs. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson > Sent: Monday, April 07, 2008 5:44 PM > To: Dinesh G Dutt > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: C-Tags > > Dinesh G Dutt writes: > > Why did we decide this ? > > S-tags are for provider backbone bridges (802.1AH), and we won't have > support for service instances. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From james.d.carlson at sun.com Tue Apr 8 10:09:53 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 8 Apr 2008 13:09:53 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1D27@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <18427.32741.585320.43032@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1D27@eusrcmw721.eamcs.ericsson.se> Message-ID: <18427.42721.339019.133334@gargle.gargle.HOWL> Eric Gray writes: > However, it is possible that additional specification may > be needed. Any such additional specification could be treated > as out of scope (for now). To tell the truth, I am unconvinced > of the need to do that - but I can live with a WG decision to > do so. > > But it is essentially wrong - IMHO - to assert that S-TAG > use cannot be done without further specification. Out of scope == not addressed by this specification. Once we've called it "out of scope," I don't really care whether an additional document is _needed_ to complete that effort. I suspect one will be needed, and you seem to be asserting that one will not, but I also think that it's completely immaterial for this document. Ruling it out of scope means that we don't have to have the discussion about what (if anything) to do about provider bridging _now_. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Tue Apr 8 11:08:58 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 08 Apr 2008 11:08:58 -0700 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> Message-ID: <47FBB4BA.5020100@cisco.com> I agree with all points that Eric makes here. Consider the following scenarios: - Rbridges are used within the provider backbone that isn't interested in doing much with ISIDs - Rbridges are used within the enterprise but using S-Tags to carry the DEI bit. I understand that there are complications if you attempt to mix C-Tags and S-Tags. That is why I'm fine with Rbridges stating that they're talking about C-Tags only. I don't want it to explicitly state that S-Tags are prohibited. As Caitlin pointed out in an earlier email, STag is merely the ethertype to carry the VLAN info (same size, 12b since that is how big the field is in the Stag as well) Dinesh Eric Gray wrote: > As a response to the general question - together with a response to > the follow-on response so far - I would like to make the following > points: > > 1) I am very uncomfortable with explicitly limiting the applicability > of RBridges to the case where "Enterprise" is defined specifically > to exclude service provider networks (remember that an SP is also > an "Enterprise" - unless explicitly excluded). > 2) I agree with Dinesh that we should not explicitly exclude S-TAGs, > even though it is (as Donald points out) necessary to be specific > in a protocol specification. A key reason for this is that - in > the case where a SP might want to use RBridges to support their > own use of an Ethernet (or Ethernet-like) infratructure (which > very-well might include both C-TAGs and S-TAGs). > 3) One way to get around this is to state - up-front - that the use > of C-TAGs is assumed in the protocol specification, but there is > no intention to prohibit use of S-TAGs, and probably further say > that any additional specification required to support S-TAGs is > out of scope in this protocol specification. > 4) The concerns expressed by Caitlin are not - and should not be - > relevant to the protocol specification (especailly if scoped as > I suggest above), since they are very explicitly related to an > implementation (or assumptions about implementations) that may > not be true for every implementation, and could very well be > avoided entirely by simply making the implementation choice to > onyl support C-TAGs. > > -- > Eric Gray > Principal Engineer > Ericsson > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III >> Donald-LDE008 >> Sent: Monday, April 07, 2008 10:16 PM >> To: Dinesh G Dutt >> Cc: Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: C-Tags >> >> Hi Dinesh, >> >> I'm not sure exactly what you mean by "explicitly prohibit the use of >> S-tags" but wherever the protocol spec requires a VLAN tag (Outer or >> Inner), it currently specifies the use of the C-tag Ethertype. >> >> It is my impression that people are thinking that the current protocol >> spec is for customer Rbridges and that, perhaps, at some point in the >> future a separate "provider Rbridge" document could be written which >> talks about S-tags, etc. >> >> Thanks, >> Donald >> >> -----Original Message----- >> From: Dinesh G Dutt [mailto:ddutt at cisco.com] >> Sent: Monday, April 07, 2008 9:26 PM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: C-Tags >> >> I'm fine with stating only about C-tags and not mention >> anything about >> S-tags. I wouldn't want the spec to explicitly prohibit the use of >> S-tags. >> >> Dinesh >> Eastlake III Donald-LDE008 wrote: >> >>> This is a check via the mailing list to confirm or refute >>> >> an apparent >> >>> consensus at the Philadelphia meeting: >>> >>> >>> ******* The TRILL Base Protocol draft should only mention >>> >> and use IEEE >> >>> 802.1 C-tags. It should not mention or use S-tags, except >>> >> possibly to >> >>> distinguish them from C-tags, state that they are not used, or the >>> >> like. >> >>> 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 >>> >>> _______________________________________________ >>> 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 james.d.carlson at sun.com Tue Apr 8 11:04:05 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 8 Apr 2008 14:04:05 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FA8F94.9060906@cisco.com> <18426.38327.532188.999945@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se> Message-ID: <18427.45973.132322.375477@gargle.gargle.HOWL> Eric Gray writes: > James, > > As a not-so-subtle distinction, I-TAGs are used to identify > service instances - not S-TAGs. Right. We won't have support for I-tags, so what are we doing specifying any S-tag behavior? I fail to see the usefulness of that. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Caitlin.Bestler at neterion.com Tue Apr 8 11:28:10 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 8 Apr 2008 14:28:10 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <47FBB4BA.5020100@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <47FBB4BA.5020100@cisco.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77035645B0@nekter> Dinesh Dutt wrote: > > I agree with all points that Eric makes here. Consider the following > scenarios: > - Rbridges are used within the provider backbone that isn't interested > in doing much with ISIDs > - Rbridges are used within the enterprise but using S-Tags to carry the > DEI bit. > > I understand that there are complications if you attempt to mix C-Tags > and S-Tags. That is why I'm fine with Rbridges stating that they're > talking about C-Tags only. I don't want it to explicitly state that > S-Tags are prohibited. > > As Caitlin pointed out in an earlier email, STag is merely the > ethertype to carry the VLAN info (same size, 12b since that is > how big the field is in the Stag as well) > To tie this in with some other recent threads, if we view RBridge as a consumer of 802.1 services then the encapsulated 802.3 frame shown in the protocol document is merely illustrative of how we presume those 802.1 and 802.3 services will generate the frame. Technically, all the RBridge specifies is the *information* that goes in the outer Ethernet frame and then the enclosed payload (with the TRILL Header, Inner Etherent Header and Ethernet Payload). Perhaps we need some language that clarifies that *any* 802.1 service the conveys the Trill Frame to the next hop RBridge meets the needs of this document. With that approach actual products would be totally free to make use of S-Tags, just a long as S-Tag semantics did not penetrate the shared RBridge forwarding information. Two RBridges are "adjacent" is there is an 802.1 service that allows them to exchange encapsulated TRILL frames. We can illustrate an 802.3 encapsulation using the C-TAG ethertype without explicitly listing all other possible 802.1 services that could deliver TRILL frames (such as using S-Tags, 802.11, metro Ethernet, etc.). That would let us focus on RBridge semantics, and let 802.1 focus on C-Tags vs. S-Tags, etc. From ddutt at cisco.com Tue Apr 8 11:34:48 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 08 Apr 2008 11:34:48 -0700 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77035645B0@nekter> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <47FBB4BA.5020100@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD77035645B0@nekter> Message-ID: <47FBBAC8.9070802@cisco.com> Well put, Caitlin. I agree, Dinesh Caitlin Bestler wrote: > Dinesh Dutt wrote: > >> I agree with all points that Eric makes here. Consider the following >> scenarios: >> - Rbridges are used within the provider backbone that isn't interested >> in doing much with ISIDs >> - Rbridges are used within the enterprise but using S-Tags to carry >> > the > >> DEI bit. >> >> I understand that there are complications if you attempt to mix C-Tags >> and S-Tags. That is why I'm fine with Rbridges stating that they're >> talking about C-Tags only. I don't want it to explicitly state that >> S-Tags are prohibited. >> >> As Caitlin pointed out in an earlier email, STag is merely the >> ethertype to carry the VLAN info (same size, 12b since that is >> how big the field is in the Stag as well) >> >> > > To tie this in with some other recent threads, if we view RBridge as > a consumer of 802.1 services then the encapsulated 802.3 frame shown > in the protocol document is merely illustrative of how we presume > those 802.1 and 802.3 services will generate the frame. > > Technically, all the RBridge specifies is the *information* that goes > in the outer Ethernet frame and then the enclosed payload (with the > TRILL Header, Inner Etherent Header and Ethernet Payload). > > Perhaps we need some language that clarifies that *any* 802.1 service > the conveys the Trill Frame to the next hop RBridge meets the needs > of this document. > > With that approach actual products would be totally free to make use > of S-Tags, just a long as S-Tag semantics did not penetrate the shared > RBridge forwarding information. Two RBridges are "adjacent" is there is > an 802.1 service that allows them to exchange encapsulated TRILL frames. > We can illustrate an 802.3 encapsulation using the C-TAG ethertype > without explicitly listing all other possible 802.1 services that could > deliver TRILL frames (such as using S-Tags, 802.11, metro Ethernet, > etc.). > > That would let us focus on RBridge semantics, and let 802.1 focus on > C-Tags vs. S-Tags, etc. > > > > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From eric.gray at ericsson.com Tue Apr 8 11:36:34 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 13:36:34 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18427.45931.45028.227277@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com><3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se><18427.32741.585320.43032@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF02CE1D27@eusrcmw721.eamcs.ericsson.se><18427.42721.339019.133334@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF02CE1EF5@eusrcmw721.eamcs.ericsson.se> <18427.45931.45028.227277@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1FBD@eusrcmw721.eamcs.ericsson.se> James, I think there is still something missing in your view; S-TAGs are defined in 802.1Q, I-TAGs are defined in 802.1ah. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, April 08, 2008 2:03 PM > To: Eric Gray > Cc: Eastlake III Donald-LDE008; Dinesh G Dutt; Caitlin > Bestler; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: C-Tags > Importance: High > > Eric Gray writes: > > Hence the subtle issue is that - while I can agree with a > > statement that use of S-TAGs is out of scope in this version of > > the protocol specification - I agree with what I believe Dinesh > > was saying when he indicated that we should not prohibit use of > > S-TAGs in this specification by including a statement to the > > effect that S-TAGs are not used. Any statement such as "S-TAGs > > are not used" is innappropriate. Further, I suggested using a > > phrase to the effect that while the specification assumes use > > of C-TAGS, it does not explicitly prohibit the use of S-TAGs. > > While S-TAG use may be out of scope for this specification, it > > may or may not require further specification (which means it is > > also out-of-scope to make any assertion about whether, or not, > > additional specification is needed). > > At the level that you're describing S-tags, any equipment that > understands an ordinary C-tag would perform the right functions, > leaving the issue essentially moot. > > I read Donald's comments differently. Equipment that processes what > are *known* to be S-tags should be dealing with the 'I' bits as well > and should know about provider-based bridging. The current RBridges > specification does not do that. > > So, sure, if you have packets on the wire that happens to look like > they have C-tags, and you don't tell an RBridge otherwise, then it'll > just do the right thing with respect to interpreting it as a VLAN. It > won't look for the nested headers, though. > > For that reason, I think our current spec leaves S-tags out of scope. > You're on your own if you use them with RBridges. If someone cares > enough about S-tags to do them right, a future document _should_ > discuss how to do that. It shouldn't be the base document, though, > and we shouldn't discuss how to use them in that text. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > From eric.gray at ericsson.com Tue Apr 8 11:40:44 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 13:40:44 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18427.45973.132322.375477@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FA8F94.9060906@cisco.com><18426.38327.532188.999945@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se> <18427.45973.132322.375477@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02CE1FC9@eusrcmw721.eamcs.ericsson.se> James, See Dinesh' point (as well as my own point on the context in which S-TAGs are defined); S-TAGs may be used without I-TAGs. A somewhat larger point is that even if I-TAGs are used, intermediate bridges do not see them. I believe S-TAGs are deliberately defined in such a way as to make it quite easy to have basic Q-Bridges forward frames with S-TAGs instead of C-TAGs. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, April 08, 2008 2:04 PM > To: Eric Gray > Cc: Dinesh G Dutt; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: C-Tags > Importance: High > > Eric Gray writes: > > James, > > > > As a not-so-subtle distinction, I-TAGs are used to identify > > service instances - not S-TAGs. > > Right. We won't have support for I-tags, so what are we doing > specifying any S-tag behavior? > > I fail to see the usefulness of that. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > From james.d.carlson at sun.com Tue Apr 8 11:03:23 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 8 Apr 2008 14:03:23 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1EF5@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FAC9A5.5080905@cisco.com> <3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <18427.32741.585320.43032@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1D27@eusrcmw721.eamcs.ericsson.se> <18427.42721.339019.133334@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1EF5@eusrcmw721.eamcs.ericsson.se> Message-ID: <18427.45931.45028.227277@gargle.gargle.HOWL> Eric Gray writes: > Hence the subtle issue is that - while I can agree with a > statement that use of S-TAGs is out of scope in this version of > the protocol specification - I agree with what I believe Dinesh > was saying when he indicated that we should not prohibit use of > S-TAGs in this specification by including a statement to the > effect that S-TAGs are not used. Any statement such as "S-TAGs > are not used" is innappropriate. Further, I suggested using a > phrase to the effect that while the specification assumes use > of C-TAGS, it does not explicitly prohibit the use of S-TAGs. > While S-TAG use may be out of scope for this specification, it > may or may not require further specification (which means it is > also out-of-scope to make any assertion about whether, or not, > additional specification is needed). At the level that you're describing S-tags, any equipment that understands an ordinary C-tag would perform the right functions, leaving the issue essentially moot. I read Donald's comments differently. Equipment that processes what are *known* to be S-tags should be dealing with the 'I' bits as well and should know about provider-based bridging. The current RBridges specification does not do that. So, sure, if you have packets on the wire that happens to look like they have C-tags, and you don't tell an RBridge otherwise, then it'll just do the right thing with respect to interpreting it as a VLAN. It won't look for the nested headers, though. For that reason, I think our current spec leaves S-tags out of scope. You're on your own if you use them with RBridges. If someone cares enough about S-tags to do them right, a future document _should_ discuss how to do that. It shouldn't be the base document, though, and we shouldn't discuss how to use them in that text. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From james.d.carlson at sun.com Tue Apr 8 11:57:36 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 8 Apr 2008 14:57:36 -0400 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02CE1FC9@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FA8F94.9060906@cisco.com> <18426.38327.532188.999945@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se> <18427.45973.132322.375477@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1FC9@eusrcmw721.eamcs.ericsson.se> Message-ID: <18427.49184.510435.701588@gargle.gargle.HOWL> Eric Gray writes: > A somewhat larger point is that even if I-TAGs are > used, intermediate bridges do not see them. I believe > S-TAGs are deliberately defined in such a way as to make > it quite easy to have basic Q-Bridges forward frames with > S-TAGs instead of C-TAGs. And nobody will be able to stop that from happening, even if the RBridges specification were to say "we don't support S-tags." There's nothing in the document or proposed for the document that will somehow cause S-tags to stop working on any network, so I don't see what the complaint is about. If it's purely about the wording, then let's just delete every instance of "S-tag" from the document (to be replaced by C-tag), and say *NOTHING* about S-tags one way or the other. I believe that to be exactly what the original consensus proposal said. And, as best I can tell, it does nothing to prohibit anyone from doing whatever he wants with S-tags. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Tue Apr 8 12:32:02 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 08 Apr 2008 12:32:02 -0700 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18427.49184.510435.701588@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <47FA8F94.9060906@cisco.com> <18426.38327.532188.999945@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se> <18427.45973.132322.375477@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF02CE1FC9@eusrcmw721.eamcs.ericsson.se> <18427.49184.510435.701588@gargle.gargle.HOWL> Message-ID: <47FBC832.3060001@cisco.com> Agreed, that is all I asked for, to not explicitly prohibit S-Tag, Dinesh James Carlson wrote: > Eric Gray writes: > >> A somewhat larger point is that even if I-TAGs are >> used, intermediate bridges do not see them. I believe >> S-TAGs are deliberately defined in such a way as to make >> it quite easy to have basic Q-Bridges forward frames with >> S-TAGs instead of C-TAGs. >> > > And nobody will be able to stop that from happening, even if the > RBridges specification were to say "we don't support S-tags." > > There's nothing in the document or proposed for the document that will > somehow cause S-tags to stop working on any network, so I don't see > what the complaint is about. > > If it's purely about the wording, then let's just delete every > instance of "S-tag" from the document (to be replaced by C-tag), and > say *NOTHING* about S-tags one way or the other. > > I believe that to be exactly what the original consensus proposal > said. And, as best I can tell, it does nothing to prohibit anyone > from doing whatever he wants with S-tags. > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From eric.gray at ericsson.com Tue Apr 8 16:23:01 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 8 Apr 2008 18:23:01 -0500 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <18427.49184.510435.701588@gargle.gargle.HOWL> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FA8F94.9060906@cisco.com><18426.38327.532188.999945@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF02CE1F0B@eusrcmw721.eamcs.ericsson.se><18427.45973.132322.375477@gargle.gargle.HOWL><941D5DCD8C42014FAF70FB7424686DCF02CE1FC9@eusrcmw721.eamcs.ericsson.se> <18427.49184.510435.701588@gargle.gargle.HOWL> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02D1A301@eusrcmw721.eamcs.ericsson.se> James, If the original consensus proposal were altered to remove the possibility of saying "[S-TAGs] are not used", then you'd be correct (at least in essence - the document currently does not include a single instance of the expression "S-TAG", so it would be unnecessary to replace those instances with "C-TAG" or "C-Tag" or "C-tag" as the case might be). It has not yet been so modified, so you are incorrect... If the currently proposed consensus is simply to omit any reference to S-TAGs, then I can live with that. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at sun.com] > Sent: Tuesday, April 08, 2008 2:58 PM > To: Eric Gray > Cc: Dinesh G Dutt; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: C-Tags > Importance: High > > Eric Gray writes: > > A somewhat larger point is that even if I-TAGs are > > used, intermediate bridges do not see them. I believe > > S-TAGs are deliberately defined in such a way as to make > > it quite easy to have basic Q-Bridges forward frames with > > S-TAGs instead of C-TAGs. > > And nobody will be able to stop that from happening, even if the > RBridges specification were to say "we don't support S-tags." > > There's nothing in the document or proposed for the document that will > somehow cause S-tags to stop working on any network, so I don't see > what the complaint is about. > > If it's purely about the wording, then let's just delete every > instance of "S-tag" from the document (to be replaced by C-tag), and > say *NOTHING* about S-tags one way or the other. > > I believe that to be exactly what the original consensus proposal > said. And, as best I can tell, it does nothing to prohibit anyone > from doing whatever he wants with S-tags. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > From anoop at brocade.com Tue Apr 8 17:41:10 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 8 Apr 2008 17:41:10 -0700 Subject: [rbridge] Consensus Check: C-Tags In-Reply-To: <47FBB4BA.5020100@cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><47FAC9A5.5080905@cisco.com><3870C46029D1F945B1472F170D2D979003AD9092@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF02CE1A43@eusrcmw721.eamcs.ericsson.se> <47FBB4BA.5020100@cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0139CE62@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt > Sent: Tuesday, April 08, 2008 11:09 AM > To: Eric Gray > Cc: Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: C-Tags > > > I understand that there are complications if you attempt to > mix C-Tags > and S-Tags. That is why I'm fine with Rbridges stating that they're > talking about C-Tags only. I don't want it to explicitly state that > S-Tags are prohibited. I agree with this. Anoop From Donald.Eastlake at motorola.com Thu Apr 10 13:31:44 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 10 Apr 2008 16:31:44 -0400 Subject: [rbridge] Consensus Check [modified]: C-Tags In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> Based on the discussion on the list, please consider the consensus statement below to have been modified by replacing "used" with "in scope" so it now reads: ******* The TRILL Base Protocol draft should only mention and use IEEE 802.1 C-tags. It should not mention or use S-tags, except possibly to distinguish them from C-tags, state that they are not in scope, or the like. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, April 07, 2008 4:41 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check [modified]: C-Tags This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* The TRILL Base Protocol draft should only mention and use IEEE 802.1 C-tags. It should not mention or use S-tags, except possibly to distinguish them from C-tags, state that they are not used, or the like. 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 _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Tue Apr 15 11:48:01 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 15 Apr 2008 11:48:01 -0700 Subject: [rbridge] Updating input fliters before output filters after a toplogy change Message-ID: <4804F861.1090404@sun.com> Dinesh pointed out that temporary loops are less likely to be formed for multidestination traffic if after a topology change RBridge R updates its input filtering tables on all its ports for all trees before updating its output filtering tables. Note by "input filtering" I mean the RPF (reverse path forwarding) check that it makes sense to receive a packet from that ingress RBridge on that port for that tree. In other words, for each port, and for each tree, it is the set of ingress RBridges that traffic on that tree can be received from, on that port. By "output filtering", I mean the set of output ports in that tree, along with the set of VLANs, multicast addresses, and reachability of IP routers, etc., on that branch. Intuitively it seems safer to have your first action after a topology change be to stop receiving on ports that are no longer in the tree. If everyone does this, then being slower about updating which ports you output to will be less problematic. Anyway, it also seems safer if all RBridges update in the same order. So I think it's a good idea to say in the spec that the input filters MUST be updated before the output filters. Radia From Caitlin.Bestler at neterion.com Tue Apr 15 13:02:36 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Tue, 15 Apr 2008 16:02:36 -0400 Subject: [rbridge] Updating input fliters before output filters after atoplogy change In-Reply-To: <4804F861.1090404@sun.com> References: <4804F861.1090404@sun.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD770367AEA8@nekter> Radia wrote: > > So I think it's a good idea to say in the spec that the input filters > MUST be updated before the output filters. > To be strictly minimalistic "the input filters MUST NOT be updated after the output filters". That allows an implementation to use a single critical write to enable both updates. From Radia.Perlman at sun.com Tue Apr 15 13:29:35 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 15 Apr 2008 13:29:35 -0700 Subject: [rbridge] Updating input fliters before output filters after atoplogy change In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD770367AEA8@nekter> References: <4804F861.1090404@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD770367AEA8@nekter> Message-ID: <4805102F.8000904@sun.com> Right. With my wording, it would have precluded doing them simultaneously, and simultaneous would be even better, and we clearly don't want to preclude that. So thanks for that wording. Radia Caitlin Bestler wrote: > Radia wrote: > >> So I think it's a good idea to say in the spec that the input filters >> MUST be updated before the output filters. >> >> > > To be strictly minimalistic "the input filters MUST NOT be updated > after the output filters". That allows an implementation to use a > single critical write to enable both updates. > > > From ddutt at cisco.com Tue Apr 15 13:58:09 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 15 Apr 2008 13:58:09 -0700 Subject: [rbridge] Updating input fliters before output filters after atoplogy change In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD770367AEA8@nekter> References: <4804F861.1090404@sun.com> <78C9135A3D2ECE4B8162EBDCE82CAD770367AEA8@nekter> Message-ID: <480516E1.2090609@cisco.com> Works for me. Dinesh Caitlin Bestler wrote: > Radia wrote: > >> So I think it's a good idea to say in the spec that the input filters >> MUST be updated before the output filters. >> >> > > To be strictly minimalistic "the input filters MUST NOT be updated > after the output filters". That allows an implementation to use a > single critical write to enable both updates. > > > > _______________________________________________ > 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 15 20:16:18 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 15 Apr 2008 23:16:18 -0400 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com> This is the last of the consensus checks via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting. ******* The VLANs on which an Rbridge sends TRILL IS-IS Hellos is expanded to include those for which it is an appointed forwarder except to the extent that it is configured not to send these additional Hellos. 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 PS: There was not complete agreement on this although there did appear to be a rough consensus at the meeting. However, in light of the other consensus from that meeting to no longer require the "decapsulation check" (see http://www.postel.org/pipermail/rbridge/2008-April/002939.html) and the discussions of the trade-offs, perhaps the consensus should be that, by default, Rbridges MUST either (1) send these additional Hellos if they are an appointed forwarder or (2) perform the decapsulation check. From anoop at brocade.com Wed Apr 16 15:43:00 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 16 Apr 2008 15:43:00 -0700 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> I had a problem with the general wording and had sent an email to the list about this a while back. While I think it's OK to have the designated forwarder send hellos on all VLANs, I would prefer it be worded such that: (a) We clearly state that the intent for this is to detect connectivity issues. In other words, this will not be used for forming adjacencies (and there we will have something in the hello that distinguishes it from the hellos that are actually used to form adjacencies). (b) That this behavior is optional because there are other ways to detect connectivity issues such as 802.1ag. There is also the L2 Gateway Protocol defined in 802.1ah that we can look into. As such, I prefer that the default be to _not_ send such messages unless explicitly configured to do so. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, April 15, 2008 10:16 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Hellos > > This is the last of the consensus checks via the mailing list > to confirm or refute an apparent consensus at the > Philadelphia meeting. > > > ******* The VLANs on which an Rbridge sends TRILL IS-IS > Hellos is expanded to include those for which it is an > appointed forwarder except to the extent that it is > configured not to send these additional Hellos. > > > 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 > > PS: There was not complete agreement on this although there > did appear to be a rough consensus at the meeting. However, > in light of the other consensus from that meeting to no > longer require the "decapsulation check" (see > http://www.postel.org/pipermail/rbridge/2008-April/002939.html ) and the discussions of the trade-offs, perhaps the consensus > should be that, by default, Rbridges MUST either (1) send > these additional Hellos if they are an appointed forwarder or > (2) perform the decapsulation check. > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From james.d.carlson at sun.com Thu Apr 17 05:10:02 2008 From: james.d.carlson at sun.com (James Carlson) Date: Thu, 17 Apr 2008 08:10:02 -0400 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com> <4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> Message-ID: <18439.15898.728312.218591@gargle.gargle.HOWL> Anoop Ghanwani writes: > (a) We clearly state that the intent for this > is to detect connectivity issues. In other > words, this will not be used for forming > adjacencies (and there we will have something > in the hello that distinguishes it from the > hellos that are actually used to form adjacencies). I agree that's the intent, but I see no reason to "have something" in the hello to distinguish it. Merely omitting the peer system IDs will have the desired effect, and we shouldn't need any special changes. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From eric.gray at ericsson.com Thu Apr 17 16:51:12 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 17 Apr 2008 18:51:12 -0500 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02E3C7A1@eusrcmw721.eamcs.ericsson.se> Anoop, As I recall, the reason for having this behavior was not at all - or at least not primarily - for detecting missing connectivity. As I recall, it was (primarily) about preventing looping as a result of not detecting that there was more than one designated forwarder. See in particular Radia's discussion on "TRILL things" in the minutes at http://www.ietf.org/proceedings/08mar/minutes/trill.txt. Even if your assumption about why we might want to do it was correct, I don't see how you could argue that we should have default behavior that assumes the existence (and use) of some unspecified alternative for detecting connectivity issues. Hence the default should rely on the use of hellos as Donald's note suggests. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, April 16, 2008 6:43 PM > To: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Hellos > > > I had a problem with the general wording and > had sent an email to the list about this a > while back. > > While I think it's OK to have the designated > forwarder send hellos on all VLANs, I would > prefer it be worded such that: > > (a) We clearly state that the intent for this > is to detect connectivity issues. In other > words, this will not be used for forming > adjacencies (and there we will have something > in the hello that distinguishes it from the > hellos that are actually used to form adjacencies). > > (b) That this behavior is optional because there > are other ways to detect connectivity issues > such as 802.1ag. There is also the L2 Gateway > Protocol defined in 802.1ah that we can look into. > As such, I prefer that the default be to _not_ > send such messages unless explicitly configured > to do so. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, April 15, 2008 10:16 PM > > To: Rbridge at postel.org > > Subject: [rbridge] Consensus Check: Hellos > > > > This is the last of the consensus checks via the mailing list > > to confirm or refute an apparent consensus at the > > Philadelphia meeting. > > > > > > ******* The VLANs on which an Rbridge sends TRILL IS-IS > > Hellos is expanded to include those for which it is an > > appointed forwarder except to the extent that it is > > configured not to send these additional Hellos. > > > > > > 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 > > > > PS: There was not complete agreement on this although there > > did appear to be a rough consensus at the meeting. However, > > in light of the other consensus from that meeting to no > > longer require the "decapsulation check" (see > > http://www.postel.org/pipermail/rbridge/2008-April/002939.html > ) and the discussions of the trade-offs, perhaps the > consensus > should > be that, by default, Rbridges MUST either (1) send > > these additional Hellos if they are an appointed forwarder or > > (2) perform the decapsulation check. > > > > _______________________________________________ > > 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 > From ayabaner at cisco.com Mon Apr 21 10:52:45 2008 From: ayabaner at cisco.com (Ayan Banerjee (ayabaner)) Date: Mon, 21 Apr 2008 10:52:45 -0700 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF02E3C7A1@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF02E3C7A1@eusrcmw721.eamcs.ericsson.se> Message-ID: <4C76BEA6DA349A4EBE240D97BBE4546403AA1668@xmb-sjc-22b.amer.cisco.com> I have a few questions on these: Does this mean that there is a single IS-IS adjacency on the LAN among all nodes (assuming that K identical VLANs are configured on each node) ? Alternatively, are there K adjacencies per vlan among the IS-IS members on the VLAN? Is the DRB being run per VLAN? Thanks, Ayan -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray Sent: Thursday, April 17, 2008 4:51 PM To: Anoop Ghanwani; Eastlake III Donald-LDE008; Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: Hellos Anoop, As I recall, the reason for having this behavior was not at all - or at least not primarily - for detecting missing connectivity. As I recall, it was (primarily) about preventing looping as a result of not detecting that there was more than one designated forwarder. See in particular Radia's discussion on "TRILL things" in the minutes at http://www.ietf.org/proceedings/08mar/minutes/trill.txt. Even if your assumption about why we might want to do it was correct, I don't see how you could argue that we should have default behavior that assumes the existence (and use) of some unspecified alternative for detecting connectivity issues. Hence the default should rely on the use of hellos as Donald's note suggests. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, April 16, 2008 6:43 PM > To: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Hellos > > > I had a problem with the general wording and had sent an email to the > list about this a while back. > > While I think it's OK to have the designated forwarder send hellos on > all VLANs, I would prefer it be worded such that: > > (a) We clearly state that the intent for this is to detect > connectivity issues. In other words, this will not be used for > forming adjacencies (and there we will have something in the hello > that distinguishes it from the hellos that are actually used to form > adjacencies). > > (b) That this behavior is optional because there are other ways to > detect connectivity issues such as 802.1ag. There is also the L2 > Gateway Protocol defined in 802.1ah that we can look into. > As such, I prefer that the default be to _not_ send such messages > unless explicitly configured to do so. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, April 15, 2008 10:16 PM > > To: Rbridge at postel.org > > Subject: [rbridge] Consensus Check: Hellos > > > > This is the last of the consensus checks via the mailing list to > > confirm or refute an apparent consensus at the Philadelphia meeting. > > > > > > ******* The VLANs on which an Rbridge sends TRILL IS-IS > > Hellos is expanded to include those for which it is an > > appointed forwarder except to the extent that it is > > configured not to send these additional Hellos. > > > > > > 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 > > > > PS: There was not complete agreement on this although there > > did appear to be a rough consensus at the meeting. However, > > in light of the other consensus from that meeting to no > > longer require the "decapsulation check" (see > > http://www.postel.org/pipermail/rbridge/2008-April/002939.html > ) and the discussions of the trade-offs, perhaps the > consensus > should > be that, by default, Rbridges MUST either (1) send > > these additional Hellos if they are an appointed forwarder or > > (2) perform the decapsulation check. > > > > _______________________________________________ > > 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 > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Mon Apr 21 12:55:05 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 21 Apr 2008 15:55:05 -0400 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546403AA1668@xmb-sjc-22b.amer.cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF02E3C7A1@eusrcmw721.eamcs.ericsson.se> <4C76BEA6DA349A4EBE240D97BBE4546403AA1668@xmb-sjc-22b.amer.cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003B9151C@de01exm64.ds.mot.com> See below at @@@ -----Original Message----- From: Ayan Banerjee (ayabaner) [mailto:ayabaner at cisco.com] Sent: Monday, April 21, 2008 1:53 PM To: Eric Gray; Anoop Ghanwani; Eastlake III Donald-LDE008; Rbridge at postel.org Subject: RE: [rbridge] Consensus Check: Hellos I have a few questions on these: Does this mean that there is a single IS-IS adjacency on the LAN among all nodes (assuming that K identical VLANs are configured on each node) ? @@@ If by LAN you mean a possibly bridged LAN bounded by Rbridges and end stations, then there would be a single core instance IS-IS adjacency in the case your describe. Alternatively, are there K adjacencies per vlan among the IS-IS members on the VLAN? @@@ "K adjacencies per vlan"? Perhaps you are asking if core IS-IS instance adjacencies are per VLAN. The answer is no. Is the DRB being run per VLAN? @@@ No. Thanks, Ayan @@@ Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray Sent: Thursday, April 17, 2008 4:51 PM To: Anoop Ghanwani; Eastlake III Donald-LDE008; Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: Hellos Anoop, As I recall, the reason for having this behavior was not at all - or at least not primarily - for detecting missing connectivity. As I recall, it was (primarily) about preventing looping as a result of not detecting that there was more than one designated forwarder. See in particular Radia's discussion on "TRILL things" in the minutes at http://www.ietf.org/proceedings/08mar/minutes/trill.txt. Even if your assumption about why we might want to do it was correct, I don't see how you could argue that we should have default behavior that assumes the existence (and use) of some unspecified alternative for detecting connectivity issues. Hence the default should rely on the use of hellos as Donald's note suggests. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, April 16, 2008 6:43 PM > To: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Hellos > > > I had a problem with the general wording and had sent an email to the > list about this a while back. > > While I think it's OK to have the designated forwarder send hellos on > all VLANs, I would prefer it be worded such that: > > (a) We clearly state that the intent for this is to detect > connectivity issues. In other words, this will not be used for > forming adjacencies (and there we will have something in the hello > that distinguishes it from the hellos that are actually used to form > adjacencies). > > (b) That this behavior is optional because there are other ways to > detect connectivity issues such as 802.1ag. There is also the L2 > Gateway Protocol defined in 802.1ah that we can look into. > As such, I prefer that the default be to _not_ send such messages > unless explicitly configured to do so. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, April 15, 2008 10:16 PM > > To: Rbridge at postel.org > > Subject: [rbridge] Consensus Check: Hellos > > > > This is the last of the consensus checks via the mailing list to > > confirm or refute an apparent consensus at the Philadelphia meeting. > > > > > > ******* The VLANs on which an Rbridge sends TRILL IS-IS > > Hellos is expanded to include those for which it is an > > appointed forwarder except to the extent that it is > > configured not to send these additional Hellos. > > > > > > 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 > > > > PS: There was not complete agreement on this although there > > did appear to be a rough consensus at the meeting. However, > > in light of the other consensus from that meeting to no > > longer require the "decapsulation check" (see > > http://www.postel.org/pipermail/rbridge/2008-April/002939.html > ) and the discussions of the trade-offs, perhaps the > consensus > should > be that, by default, Rbridges MUST either (1) send > > these additional Hellos if they are an appointed forwarder or > > (2) perform the decapsulation check. > > > > _______________________________________________ > > 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 > _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Mon Apr 21 13:28:36 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 21 Apr 2008 13:28:36 -0700 Subject: [rbridge] Consensus Check: Hellos In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546403AA1668@xmb-sjc-22b.amer.cisco.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003B57D59@de01exm64.ds.mot.com><4C94DE2070B172459E4F1EE14BD2364E01447075@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF02E3C7A1@eusrcmw721.eamcs.ericsson.se> <4C76BEA6DA349A4EBE240D97BBE4546403AA1668@xmb-sjc-22b.amer.cisco.com> Message-ID: <480CF8F4.9040704@cisco.com> Ayan, Ayan Banerjee (ayabaner) wrote: > I have a few questions on these: > > Does this mean that there is a single IS-IS adjacency on the LAN among > all nodes (assuming that K identical VLANs are configured on each node) > ? > Yes. > Alternatively, are there K adjacencies per vlan among the IS-IS members > on the VLAN? > > No. > Is the DRB being run per VLAN? > No, Dinesh > Thanks, > Ayan > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eric Gray > Sent: Thursday, April 17, 2008 4:51 PM > To: Anoop Ghanwani; Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Hellos > > Anoop, > > As I recall, the reason for having this behavior was not at all > - or at least not primarily - for detecting missing connectivity. > As I recall, it was (primarily) about preventing looping as a result of > not detecting that there was more than one designated forwarder. > > See in particular Radia's discussion on "TRILL things" in the > minutes at http://www.ietf.org/proceedings/08mar/minutes/trill.txt. > > Even if your assumption about why we might want to do it was > correct, I don't see how you could argue that we should have default > behavior that assumes the existence (and use) of some unspecified > alternative for detecting connectivity issues. > > Hence the default should rely on the use of hellos as Donald's > note suggests. > > -- > Eric Gray > Principal Engineer > Ericsson > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani >> Sent: Wednesday, April 16, 2008 6:43 PM >> To: Eastlake III Donald-LDE008; Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: Hellos >> >> >> I had a problem with the general wording and had sent an email to the >> list about this a while back. >> >> While I think it's OK to have the designated forwarder send hellos on >> all VLANs, I would prefer it be worded such that: >> >> (a) We clearly state that the intent for this is to detect >> connectivity issues. In other words, this will not be used for >> forming adjacencies (and there we will have something in the hello >> that distinguishes it from the hellos that are actually used to form >> adjacencies). >> >> (b) That this behavior is optional because there are other ways to >> detect connectivity issues such as 802.1ag. There is also the L2 >> Gateway Protocol defined in 802.1ah that we can look into. >> As such, I prefer that the default be to _not_ send such messages >> unless explicitly configured to do so. >> >> Anoop >> >> >>> -----Original Message----- >>> From: rbridge-bounces at postel.org >>> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III >>> Donald-LDE008 >>> Sent: Tuesday, April 15, 2008 10:16 PM >>> To: Rbridge at postel.org >>> Subject: [rbridge] Consensus Check: Hellos >>> >>> This is the last of the consensus checks via the mailing list to >>> confirm or refute an apparent consensus at the Philadelphia meeting. >>> >>> >>> ******* The VLANs on which an Rbridge sends TRILL IS-IS >>> Hellos is expanded to include those for which it is an >>> appointed forwarder except to the extent that it is >>> configured not to send these additional Hellos. >>> >>> >>> 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 >>> >>> PS: There was not complete agreement on this although there >>> did appear to be a rough consensus at the meeting. However, >>> in light of the other consensus from that meeting to no >>> longer require the "decapsulation check" (see >>> http://www.postel.org/pipermail/rbridge/2008-April/002939.html >>> >> ) and the discussions of the trade-offs, perhaps the >> consensus > should >> be that, by default, Rbridges MUST either (1) send >> >>> these additional Hellos if they are an appointed forwarder or >>> (2) perform the decapsulation check. >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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 Thu Apr 24 20:19:47 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 24 Apr 2008 23:19:47 -0400 Subject: [rbridge] Consensus Confirmed: Text trumps pseudocode In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003BDA3BE@de01exm64.ds.mot.com> The following consensus has been confirmed. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Friday, April 04, 2008 5:44 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Text trumps pseudocode 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 Donald.Eastlake at motorola.com Thu Apr 24 20:20:41 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 24 Apr 2008 23:20:41 -0400 Subject: [rbridge] Consensus Confirmed: Decapsulation check optional In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8AF1@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8AF1@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003BDA3BF@de01exm64.ds.mot.com> The following consensus has been confirmed. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Friday, April 04, 2008 5:28 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Decapsulation check optional 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 Thu Apr 24 20:21:25 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Thu, 24 Apr 2008 23:21:25 -0400 Subject: [rbridge] Consensus Confirmed: Test for VLAN mapping In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8B01@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com> <3870C46029D1F945B1472F170D2D979003AD8B01@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003BDA3C0@de01exm64.ds.mot.com> The following consensus has been confirmed. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Friday, April 04, 2008 5:39 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Test for VLAN mapping 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 Radia.Perlman at sun.com Fri Apr 25 09:52:57 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 25 Apr 2008 09:52:57 -0700 Subject: [rbridge] How many "priorities" are there? Message-ID: <48120C69.9010600@sun.com> Is there just a single priority for an RBridge, that is used for all the priorities, or are there separate ones for: a) priority for becoming DRB on a layer 2 cloud b) priority for becoming the "CSNP-generator" for announcing VLAN x endnodes? And if so, is there a separate priority per VLAN, so you can have low priority for one, and high for another? c) priority for becoming a tree root? d) priority for owning a chosen (as opposed to configured) nickname? There might even be more cases where we use the term "priority". I'd guess that a) and c) might be things that customers would want to configure. I think that b) is something that should be just a flag "I implement endnode advertisements (learning from and advertising)", though perhaps the flag should be per VLAN. I don't think d) matters, and we could just use the same priority as for DRB. Radia From ayabaner at cisco.com Fri Apr 25 13:23:40 2008 From: ayabaner at cisco.com (Ayan Banerjee (ayabaner)) Date: Fri, 25 Apr 2008 13:23:40 -0700 Subject: [rbridge] How many "priorities" are there? In-Reply-To: <48120C69.9010600@sun.com> References: <48120C69.9010600@sun.com> Message-ID: <4C76BEA6DA349A4EBE240D97BBE4546403B039A5@xmb-sjc-22b.amer.cisco.com> Radia, I believe that a (IIH-Priority in base IS-IS), c (Root priority TLV in draft-ward-l2isis), and d (Section 3.7.3 of draft-ietf-trill-rbridge-protocol, Device ID TLV of draft-ward-l2isis) are already defined. I would think that the customer may want to configure all of them separately. Thanks, Ayan -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Friday, April 25, 2008 9:53 AM To: Developing a hybrid router/bridge. Subject: [rbridge] How many "priorities" are there? Is there just a single priority for an RBridge, that is used for all the priorities, or are there separate ones for: a) priority for becoming DRB on a layer 2 cloud b) priority for becoming the "CSNP-generator" for announcing VLAN x endnodes? And if so, is there a separate priority per VLAN, so you can have low priority for one, and high for another? c) priority for becoming a tree root? d) priority for owning a chosen (as opposed to configured) nickname? There might even be more cases where we use the term "priority". I'd guess that a) and c) might be things that customers would want to configure. I think that b) is something that should be just a flag "I implement endnode advertisements (learning from and advertising)", though perhaps the flag should be per VLAN. I don't think d) matters, and we could just use the same priority as for DRB. Radia _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Fri Apr 25 16:56:36 2008 From: Radia.Perlman at sun.com (Radia.Perlman@sun.com) Date: Fri, 25 Apr 2008 16:56:36 -0700 Subject: [rbridge] Proposed details for announcing endnodes Message-ID: <99f1ccaf6f3b.48120d44@sunlabs.com> The unfortunate choice of the words ('per-VLAN instance of IS-IS") for the protocol in which endnodes would be announced has definitely confused people, so let me give details about how I think it should work. What we want to accomplish: If R1 is a VLAN-A forwarder on at least one link, R1 wants to inform other VLAN-A forwarders about at R1's attached VLAN-A endnodes. The proposal: a) R1 multicasts a packet throughout the campus, directed at VLAN-A. This packet is encoded as a link state packet, with a sequence number. If it is too large to fit into a single packet IS-IS allows LSP "fragments", where each fragment is separately flooded, and has its own sequence number. If data in one fragment changes, that fragment needs to be flooded, but unchanged fragments do not need to be. b) An RBridge that is not a VLAN-A forwarder on any of its links participates in the flooding of the packet on the tree chosen by ingress R1, but does not otherwise process the packet. c) If R2 is a VLAN-A forwarder on at least one of its ports, it stores R1's most recently generated packet, in order to fold the information into its endnode learning table (to know that those endnodes should be forwarded to R1) d) To ensure reliable delivery of R1's announcement, we need for one of the VLAN-A forwarders to take on the responsibility of sending an IS-IS CSNP periodically. e) Traditionally, IS-IS would choose which switch is responsible for sending a CSNP, by sending Hello messages and doing a DR election. However, in this case, the LSPs in the "core instance" of IS-IS gives enough information for all the RBridges to know which RBridge should be issuing the CSNP. The necessary information is for R1 to announce (in its core LSP), which VLANs R1 is VLAN forwarder for. Note: This information is already in the protocol spec. However, since generating and processing VLAN A endnodes announcements is optional, we should add a flag that says "I participate in the endnode announcement protocol for VLAN A". There are two reasons for this flag: one is that if R1 is the only VLAN-A forwarder that participates, then R1 should not make announcements (since they'll just be ignored). The other reason is to elect (without further protocol message", the VLAN-A forwarder that will periodically send CSNPs. f) Based on (priority, ID) one VLAN-A forwarder will be elected to periodically issue CSNPs. However, if any VLAN-A forwarder hasn't seen a CSNP recently, it is not problem for it to send a CSNP. ******************** So...what is the cost of this? Already we have the information in R1's LSP about which VLANs R1 is forwarder for. I'm not sure whether we already have the flag "I participate in endnode announcements for VLAN A". The information about attached endnodes is in the format of IS-IS endnode announcements. No other information appears. The endnode announcement LSP gets flooded like any VLAN A multicast/unknown destination data packet, so that it will be delivered to all RBridges that are VLAN A forwarders. One of the VLAN A forwarders sends periodic CSNPs so that if any RBridges miss any of the announcements, this will be detected and corrected. Radia From Donald.Eastlake at motorola.com Fri Apr 25 20:40:45 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 25 Apr 2008 23:40:45 -0400 Subject: [rbridge] Consensus Confirmed: Critical Option Summary Bits In-Reply-To: <3870C46029D1F945B1472F170D2D979003AD8F8A@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003AD8F8A@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003BDA751@de01exm64.ds.mot.com> The following consensus is confirmed. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, April 07, 2008 4:37 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Critical Option Summary Bits This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* Leave the provisions in the base protocol (version 07) draft for critical option summary bits if the options area has non-zero length and leave further details about options to another document or documents. 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 Sun Apr 27 18:41:19 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 27 Apr 2008 21:41:19 -0400 Subject: [rbridge] Consensus Confirmed [modified]: C-Tags In-Reply-To: <3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003622703@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003622E10@de01exm64.ds.mot.com><4784F127.6020603@cisco.com><3870C46029D1F945B1472F170D2D979003AD8B05@de01exm64.ds.mot.com><3870C46029D1F945B1472F170D2D979003AD8F93@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D979003B1CC30@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D979003BDA827@de01exm64.ds.mot.com> The consensus below is confirmed as modified. Thanks, Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Thursday, April 10, 2008 4:32 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check [modified]: C-Tags Based on the discussion on the list, please consider the consensus statement below to have been modified by replacing "used" with "in scope" so it now reads: ******* The TRILL Base Protocol draft should only mention and use IEEE 802.1 C-tags. It should not mention or use S-tags, except possibly to distinguish them from C-tags, state that they are not in scope, or the like. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, April 07, 2008 4:41 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check [modified]: C-Tags This is a check via the mailing list to confirm or refute an apparent consensus at the Philadelphia meeting: ******* The TRILL Base Protocol draft should only mention and use IEEE 802.1 C-tags. It should not mention or use S-tags, except possibly to distinguish them from C-tags, state that they are not used, or the like. 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 _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Sun Apr 27 20:28:48 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 27 Apr 2008 23:28:48 -0400 Subject: [rbridge] What to do about VLAN mapping Message-ID: <3870C46029D1F945B1472F170D2D979003BDA83A@de01exm64.ds.mot.com> Hi, We have decided (see below) that the outer VLAN ID on TRILL IS-IS Hellos will be included inside the Hello and they will be compared on receipt of the Hello to test for VLAN mapping. However, at the Philadelphia meeting, decided what to do when VLAN mapping was detected was deferred to the mailing list. Something has to be done since if, on a bridged LAN, VLAN-x where an Rbridge is attached is being mapped to VLAN-y where an Rbridge is attached, if they are respective appointed forwarders for VLAN x and y, you have a loop. Two possibilities that were mentioned at the Philadelphia meeting were approximately as follows: (1) An Rbridge receiving a Hello on a port that show VLAN-x being mapped to VLAN-y should report this to the DRB on that link. The DRB should assure that there is a forwarder appointed for at most one of VLAN-x and VLAN-y on that link. (2) An Rbridge receiving a Hello on a port that shows VLAN-x being mapped to VLAN-y should disable service to both VLANs on that port. Part of the idea with this possibility was to cause a hard failure so the problem would be noticed and the bridge configurations fixed. Thanks, Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Thursday, April 24, 2008 11:21 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Confirmed: Test for VLAN mapping The following consensus has been confirmed. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Friday, April 04, 2008 5:39 PM To: Rbridge at postel.org Subject: [rbridge] Consensus Check: Test for VLAN mapping 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 anoop at brocade.com Mon Apr 28 16:36:30 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 28 Apr 2008 16:36:30 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <99f1ccaf6f3b.48120d44@sunlabs.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> Although I don't think I would be interested in implementing this aspect of the protocol, I think this is a reasonable proposal. There is one concern - how do we deal with moves? A move would mean that there are 2 forwarders that think they own the address so how would they resolve the conflict? Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com > Sent: Friday, April 25, 2008 4:57 PM > To: rbridge at postel.org > Subject: [rbridge] Proposed details for announcing endnodes > > The unfortunate choice of the words ('per-VLAN instance of > IS-IS") for the protocol in which endnodes would be announced > has definitely confused people, so let me give details about > how I think it should work. > > What we want to accomplish: If R1 is a VLAN-A forwarder on at > least one link, R1 wants to inform other VLAN-A forwarders > about at R1's attached VLAN-A endnodes. > > The proposal: > > a) R1 multicasts a packet throughout the campus, directed at > VLAN-A. This packet is encoded as a link state packet, with a > sequence number. If it is too large to fit into a single > packet IS-IS allows LSP "fragments", where each fragment is > separately flooded, and has its own sequence number. If data > in one fragment changes, that fragment needs to be flooded, > but unchanged fragments do not need to be. > > b) An RBridge that is not a VLAN-A forwarder on any of its > links participates in the flooding of the packet on the tree > chosen by ingress R1, but does not otherwise process the packet. > > c) If R2 is a VLAN-A forwarder on at least one of its ports, > it stores R1's most recently generated packet, in order to > fold the information into its endnode learning table (to know > that those endnodes should be forwarded to R1) > > d) To ensure reliable delivery of R1's announcement, we need > for one of the VLAN-A forwarders to take on the > responsibility of sending an IS-IS CSNP periodically. > > e) Traditionally, IS-IS would choose which switch is > responsible for sending a CSNP, by sending Hello messages and > doing a DR election. However, in this case, the LSPs in the > "core instance" of IS-IS gives enough information for all the > RBridges to know which RBridge should be issuing the CSNP. > The necessary information is for R1 to announce (in its core > LSP), which VLANs R1 is VLAN forwarder for. Note: This > information is already in the protocol spec. > > However, since generating and processing VLAN A endnodes > announcements is optional, we should add a flag that says "I > participate in the endnode announcement protocol for VLAN A". > There are two reasons for this flag: one is that if R1 is the > only VLAN-A forwarder that participates, then R1 should not > make announcements (since they'll just be ignored). The other > reason is to elect (without further protocol message", the > VLAN-A forwarder that will periodically send CSNPs. > > f) Based on (priority, ID) one VLAN-A forwarder will be > elected to periodically issue CSNPs. However, if any VLAN-A > forwarder hasn't seen a CSNP recently, it is not problem for > it to send a CSNP. > > ******************** > So...what is the cost of this? > > Already we have the information in R1's LSP about which VLANs > R1 is forwarder for. I'm not sure whether we already have the > flag "I participate in endnode announcements for VLAN A". > > The information about attached endnodes is in the format of > IS-IS endnode announcements. No other information appears. > The endnode announcement LSP gets flooded like any VLAN A > multicast/unknown destination data packet, so that it will be > delivered to all RBridges that are VLAN A forwarders. > > One of the VLAN A forwarders sends periodic CSNPs so that if > any RBridges miss any of the announcements, this will be > detected and corrected. > > Radia > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Mon Apr 28 16:37:39 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 28 Apr 2008 16:37:39 -0700 Subject: [rbridge] How many "priorities" are there? In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546403B039A5@xmb-sjc-22b.amer.cisco.com> References: <48120C69.9010600@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546403B039A5@xmb-sjc-22b.amer.cisco.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0153F1D7@HQ-EXCH-5.corp.brocade.com> I think it's reasonable to have all of them be separate. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Ayan > Banerjee (ayabaner) > Sent: Friday, April 25, 2008 1:24 PM > To: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] How many "priorities" are there? > > Radia, > > I believe that a (IIH-Priority in base IS-IS), c (Root > priority TLV in draft-ward-l2isis), and d (Section 3.7.3 of > draft-ietf-trill-rbridge-protocol, Device ID TLV of > draft-ward-l2isis) are already defined. I would think that > the customer may want to configure all of them separately. > > Thanks, > Ayan > > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Friday, April 25, 2008 9:53 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] How many "priorities" are there? > > Is there just a single priority for an RBridge, that is used > for all the priorities, or are there separate ones for: > a) priority for becoming DRB on a layer 2 cloud > b) priority for becoming the "CSNP-generator" for announcing > VLAN x endnodes? And if so, is there a separate priority per > VLAN, so you can have low priority for one, and high for another? > c) priority for becoming a tree root? > d) priority for owning a chosen (as opposed to configured) nickname? > > There might even be more cases where we use the term "priority". > > I'd guess that a) and c) might be things that customers would > want to configure. I think that b) is something that should > be just a flag "I implement endnode advertisements (learning > from and advertising)", though perhaps the flag should be per > VLAN. I don't think d) matters, and we could just use the > same priority as for DRB. > > Radia > _______________________________________________ > 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 > From Radia.Perlman at sun.com Mon Apr 28 20:53:54 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 28 Apr 2008 20:53:54 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> Message-ID: <48169BD2.5060309@sun.com> Yeah. Moving endnodes is always an issue. Even with bridges. The problem with having R1 (the one announcing that endnode E is attached to R1) having a very short learning cache is that makes R1's endnode announcement LSP information annoyingly volatile. The problem with the learning cache timer being long is that R1 can be a black hole, sucking traffic away from where E really is. There are some layer 2 protocols, I believe, with explicit registration and keep-alives. (anyone care to chime in about which protocols these are?). Endnodes learned that way are good candidates for explicitly advertising. For attached IP endnodes, R1 could do something like, if it seems someone else advertise E, R1 could do an ARP to see if E is still there. And there might be similar purely layer 2 "pings". (are there?) Also, if R1 is the only one advertising E, it doesn't really matter if E isn't there, so long as nobody is trying to send traffic to E. So R1 could delay attempting to see if E is there until someone tries to talk to it. Radia Anoop Ghanwani wrote: > Although I don't think I would be interested > in implementing this aspect of the protocol, I think > this is a reasonable proposal. > > There is one concern - how do we deal > with moves? A move would mean that there are > 2 forwarders that think they own the address so > how would they resolve the conflict? > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com >> Sent: Friday, April 25, 2008 4:57 PM >> To: rbridge at postel.org >> Subject: [rbridge] Proposed details for announcing endnodes >> >> The unfortunate choice of the words ('per-VLAN instance of >> IS-IS") for the protocol in which endnodes would be announced >> has definitely confused people, so let me give details about >> how I think it should work. >> >> What we want to accomplish: If R1 is a VLAN-A forwarder on at >> least one link, R1 wants to inform other VLAN-A forwarders >> about at R1's attached VLAN-A endnodes. >> >> The proposal: >> >> a) R1 multicasts a packet throughout the campus, directed at >> VLAN-A. This packet is encoded as a link state packet, with a >> sequence number. If it is too large to fit into a single >> packet IS-IS allows LSP "fragments", where each fragment is >> separately flooded, and has its own sequence number. If data >> in one fragment changes, that fragment needs to be flooded, >> but unchanged fragments do not need to be. >> >> b) An RBridge that is not a VLAN-A forwarder on any of its >> links participates in the flooding of the packet on the tree >> chosen by ingress R1, but does not otherwise process the packet. >> >> c) If R2 is a VLAN-A forwarder on at least one of its ports, >> it stores R1's most recently generated packet, in order to >> fold the information into its endnode learning table (to know >> that those endnodes should be forwarded to R1) >> >> d) To ensure reliable delivery of R1's announcement, we need >> for one of the VLAN-A forwarders to take on the >> responsibility of sending an IS-IS CSNP periodically. >> >> e) Traditionally, IS-IS would choose which switch is >> responsible for sending a CSNP, by sending Hello messages and >> doing a DR election. However, in this case, the LSPs in the >> "core instance" of IS-IS gives enough information for all the >> RBridges to know which RBridge should be issuing the CSNP. >> The necessary information is for R1 to announce (in its core >> LSP), which VLANs R1 is VLAN forwarder for. Note: This >> information is already in the protocol spec. >> >> However, since generating and processing VLAN A endnodes >> announcements is optional, we should add a flag that says "I >> participate in the endnode announcement protocol for VLAN A". >> There are two reasons for this flag: one is that if R1 is the >> only VLAN-A forwarder that participates, then R1 should not >> make announcements (since they'll just be ignored). The other >> reason is to elect (without further protocol message", the >> VLAN-A forwarder that will periodically send CSNPs. >> >> f) Based on (priority, ID) one VLAN-A forwarder will be >> elected to periodically issue CSNPs. However, if any VLAN-A >> forwarder hasn't seen a CSNP recently, it is not problem for >> it to send a CSNP. >> >> ******************** >> So...what is the cost of this? >> >> Already we have the information in R1's LSP about which VLANs >> R1 is forwarder for. I'm not sure whether we already have the >> flag "I participate in endnode announcements for VLAN A". >> >> The information about attached endnodes is in the format of >> IS-IS endnode announcements. No other information appears. >> The endnode announcement LSP gets flooded like any VLAN A >> multicast/unknown destination data packet, so that it will be >> delivered to all RBridges that are VLAN A forwarders. >> >> One of the VLAN A forwarders sends periodic CSNPs so that if >> any RBridges miss any of the announcements, this will be >> detected and corrected. >> >> Radia >> >> >> >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> From touch at ISI.EDU Mon Apr 28 22:10:23 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 28 Apr 2008 22:10:23 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <48169BD2.5060309@sun.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com> Message-ID: <4816ADBF.3070205@isi.edu> Radia Perlman wrote: > Yeah. Moving endnodes is always an issue. Even with bridges. The problem > with having R1 (the one announcing that endnode E is > attached to R1) having a very short learning cache is that makes R1's > endnode announcement LSP information annoyingly volatile. The problem > with the learning > cache timer being long is that R1 can be a black hole, sucking traffic > away from where E really is. > > There are some layer 2 protocols, I believe, with explicit registration > and keep-alives. (anyone care to chime in about which protocols > these are?). Endnodes learned that way are good candidates for > explicitly advertising. > > For attached IP endnodes, R1 could do something like, if it seems > someone else advertise E, R1 could do an ARP to see if E is > still there. And there might be similar purely layer 2 "pings". (are there?) I do not believe rbridges should ever issue ARPs. Silent movement is a known problem with existing bridges; this is not an issue we should be solving. 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/20080428/a1d26a19/signature.bin From sdalberg at marchex.com Tue Apr 29 07:32:33 2008 From: sdalberg at marchex.com (Steve Dalberg) Date: Tue, 29 Apr 2008 07:32:33 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <4816ADBF.3070205@isi.edu> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com><48169BD2.5060309@sun.com> <4816ADBF.3070205@isi.edu> Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> > Radia Perlman wrote: > > Yeah. Moving endnodes is always an issue. Even with bridges. The > > problem with having R1 (the one announcing that endnode E > is attached > > to R1) having a very short learning cache is that makes > R1's endnode > > announcement LSP information annoyingly volatile. The > problem with the > > learning cache timer being long is that R1 can be a black hole, > > sucking traffic away from where E really is. > > > > There are some layer 2 protocols, I believe, with explicit > > registration and keep-alives. (anyone care to chime in about which > > protocols these are?). Endnodes learned that way are good > candidates > > for explicitly advertising. > > > > For attached IP endnodes, R1 could do something like, if it seems > > someone else advertise E, R1 could do an ARP to see if E is still > > there. And there might be similar purely layer 2 "pings". > (are there?) > > I do not believe rbridges should ever issue ARPs. Silent > movement is a known problem with existing bridges; this is > not an issue we should be solving. > > Joe I agree, although from a protocol level, what is the fallout from conflicting MAC's? Will it cause protocol thrashing in any way? As for the Layer 2 "pings" question, you'd be better off just looking for traffic sourced by the MAC in question over a couple of second period. Not sure what you would want to do with that, but if you don't see anything you can safely clear your forwarding table Steve From touch at ISI.EDU Tue Apr 29 07:51:09 2008 From: touch at ISI.EDU (Joe Touch) Date: Tue, 29 Apr 2008 07:51:09 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com><48169BD2.5060309@sun.com> <4816ADBF.3070205@isi.edu> <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> Message-ID: <481735DD.9010005@isi.edu> Steve Dalberg wrote: >> Radia Perlman wrote: >>> Yeah. Moving endnodes is always an issue. Even with bridges. The >>> problem with having R1 (the one announcing that endnode E >> is attached >>> to R1) having a very short learning cache is that makes >> R1's endnode >>> announcement LSP information annoyingly volatile. The >> problem with the >>> learning cache timer being long is that R1 can be a black hole, >>> sucking traffic away from where E really is. >>> >>> There are some layer 2 protocols, I believe, with explicit >>> registration and keep-alives. (anyone care to chime in about which >>> protocols these are?). Endnodes learned that way are good >> candidates >>> for explicitly advertising. >>> >>> For attached IP endnodes, R1 could do something like, if it seems >>> someone else advertise E, R1 could do an ARP to see if E is still >>> there. And there might be similar purely layer 2 "pings". >> (are there?) >> >> I do not believe rbridges should ever issue ARPs. Silent >> movement is a known problem with existing bridges; this is >> not an issue we should be solving. >> >> Joe > > I agree, although from a protocol level, what is the fallout from > conflicting MAC's? Will it cause protocol thrashing in any way? Radia noted it above - it black-holes traffic to the true MAC location. > As for the Layer 2 "pings" question, you'd be better off just looking > for traffic sourced by the MAC in question over a couple of second > period. Not sure what you would want to do with that, but if you don't > see anything you can safely clear your forwarding table That works only for bidirectional traffic. Silent listeners that move always cause problems - and, as I onted, we shouldn't propose to fix that issue. 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/20080429/a7df8108/signature.bin From james.d.carlson at sun.com Tue Apr 29 08:50:52 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 29 Apr 2008 11:50:52 -0400 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <481735DD.9010005@isi.edu> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com> <4816ADBF.3070205@isi.edu> <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> <481735DD.9010005@isi.edu> Message-ID: <18455.17372.639428.116172@gargle.gargle.HOWL> Joe Touch writes: > Steve Dalberg wrote: > > As for the Layer 2 "pings" question, you'd be better off just looking > > for traffic sourced by the MAC in question over a couple of second > > period. Not sure what you would want to do with that, but if you don't > > see anything you can safely clear your forwarding table > > That works only for bidirectional traffic. Silent listeners that move > always cause problems - and, as I onted, we shouldn't propose to fix > that issue. If it's a truly silent listener, then it won't really cause us any problems. Absent special tricks (such as 802.11 in AP mode), we won't learn of its location by any means, and we thus will be forced to flood all packets sent to that receiver. No location-related problem should occur. If it's a listener that speaks once in a blue moon, then Steve's note holds: we'll time out the entry, stop using it, and revert back to flooding for an unknown destination. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From touch at ISI.EDU Tue Apr 29 09:38:23 2008 From: touch at ISI.EDU (Joe Touch) Date: Tue, 29 Apr 2008 09:38:23 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <18455.17372.639428.116172@gargle.gargle.HOWL> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com> <4816ADBF.3070205@isi.edu> <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> <481735DD.9010005@isi.edu> <18455.17372.639428.116172@gargle.gargle.HOWL> Message-ID: <48174EFF.8010200@isi.edu> James Carlson wrote: > Joe Touch writes: >> Steve Dalberg wrote: >>> As for the Layer 2 "pings" question, you'd be better off just looking >>> for traffic sourced by the MAC in question over a couple of second >>> period. Not sure what you would want to do with that, but if you don't >>> see anything you can safely clear your forwarding table >> That works only for bidirectional traffic. Silent listeners that move >> always cause problems - and, as I onted, we shouldn't propose to fix >> that issue. > > If it's a truly silent listener, then it won't really cause us any > problems. Absent special tricks (such as 802.11 in AP mode), we won't > learn of its location by any means, and we thus will be forced to > flood all packets sent to that receiver. No location-related problem > should occur. A silent listener that moves will never trigger broadcast, UNLESS we time-out entries. That might be desirable - and since truly silent liseners are an exception, that shouldn't cause a problem. I.e., a passive solution might be appropriate. > If it's a listener that speaks once in a blue moon, then Steve's note > holds: we'll time out the entry, stop using it, and revert back to > flooding for an unknown destination. Right - the speaking tells us when they move. 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/20080429/a36db3ec/signature.bin From ddutt at cisco.com Tue Apr 29 09:42:24 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 29 Apr 2008 09:42:24 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <4816ADBF.3070205@isi.edu> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com> <4816ADBF.3070205@isi.edu> Message-ID: <48174FF0.7020306@cisco.com> Agree with Joe, Dinesh Joe Touch wrote: > > > Radia Perlman wrote: >> Yeah. Moving endnodes is always an issue. Even with bridges. The >> problem with having R1 (the one announcing that endnode E is >> attached to R1) having a very short learning cache is that makes R1's >> endnode announcement LSP information annoyingly volatile. The problem >> with the learning >> cache timer being long is that R1 can be a black hole, sucking >> traffic away from where E really is. >> >> There are some layer 2 protocols, I believe, with explicit >> registration and keep-alives. (anyone care to chime in about which >> protocols >> these are?). Endnodes learned that way are good candidates for >> explicitly advertising. >> >> For attached IP endnodes, R1 could do something like, if it seems >> someone else advertise E, R1 could do an ARP to see if E is >> still there. And there might be similar purely layer 2 "pings". (are >> there?) > > I do not believe rbridges should ever issue ARPs. Silent movement is a > known problem with existing bridges; this is not an issue we should be > solving. > > Joe > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 29 18:30:14 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 29 Apr 2008 21:30:14 -0400 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <48174FF0.7020306@cisco.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu> <48174FF0.7020306@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> (1) I don't see any point in discussing ARP now since the working group has decided to move ARP and similar IP optimization out of the base protocol draft to another document which does not yet even exist. (2) The purpose of Rbridges is to do better than bridges. Arguments of the form 'X is a known problem with bridges so we shouldn't solve it' seem odd when the main premise of Rbridges is 'spanning tree is a known problem with bridges so we WILL solve it'. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt Sent: Tuesday, April 29, 2008 12:42 PM To: Joe Touch Cc: rbridge at postel.org; Radia Perlman Subject: Re: [rbridge] Proposed details for announcing endnodes Agree with Joe, Dinesh Joe Touch wrote: > > > Radia Perlman wrote: >> Yeah. Moving endnodes is always an issue. Even with bridges. The >> problem with having R1 (the one announcing that endnode E is >> attached to R1) having a very short learning cache is that makes R1's >> endnode announcement LSP information annoyingly volatile. The problem >> with the learning >> cache timer being long is that R1 can be a black hole, sucking >> traffic away from where E really is. >> >> There are some layer 2 protocols, I believe, with explicit >> registration and keep-alives. (anyone care to chime in about which >> protocols >> these are?). Endnodes learned that way are good candidates for >> explicitly advertising. >> >> For attached IP endnodes, R1 could do something like, if it seems >> someone else advertise E, R1 could do an ARP to see if E is >> still there. And there might be similar purely layer 2 "pings". (are >> there?) > > I do not believe rbridges should ever issue ARPs. Silent movement is a > known problem with existing bridges; this is not an issue we should be > solving. > > Joe > > ------------------------------------------------------------------------ -- 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 29 19:17:03 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 29 Apr 2008 22:17:03 -0400 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <48174EFF.8010200@isi.edu> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com> <4816ADBF.3070205@isi.edu> <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> <481735DD.9010005@isi.edu><18455.17372.639428.116172@gargle.gargle.HOWL> <48174EFF.8010200@isi.edu> Message-ID: <3870C46029D1F945B1472F170D2D979003C1636B@de01exm64.ds.mot.com> See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch Sent: Tuesday, April 29, 2008 12:38 PM To: James Carlson Cc: rbridge at postel.org Subject: Re: [rbridge] Proposed details for announcing endnodes James Carlson wrote: > Joe Touch writes: >> Steve Dalberg wrote: >>> As for the Layer 2 "pings" question, you'd be better off just looking >>> for traffic sourced by the MAC in question over a couple of second >>> period. Not sure what you would want to do with that, but if you don't >>> see anything you can safely clear your forwarding table >> That works only for bidirectional traffic. Silent listeners that move >> always cause problems - and, as I onted, we shouldn't propose to fix >> that issue. > > If it's a truly silent listener, then it won't really cause us any > problems. Absent special tricks (such as 802.11 in AP mode), we won't > learn of its location by any means, and we thus will be forced to > flood all packets sent to that receiver. No location-related problem > should occur. A silent listener that moves will never trigger broadcast, UNLESS we time-out entries. That might be desirable - and since truly silent liseners are an exception, that shouldn't cause a problem. I.e., a passive solution might be appropriate. @@@ Time out only matters if it got into the address cache somehow to begin with which wouldn't happen if it was always silent. And, we have decided that addresses learned at the data plane will be timed out in the same way as in an 802.1 bridge. See http://www.postel.org/pipermail/rbridge/2007-October/002507.html. @@@ Thanks, @@@ Donald > If it's a listener that speaks once in a blue moon, then Steve's note > holds: we'll time out the entry, stop using it, and revert back to > flooding for an unknown destination. Right - the speaking tells us when they move. Joe From Donald.Eastlake at motorola.com Tue Apr 29 20:44:50 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 29 Apr 2008 23:44:50 -0400 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com><48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu> <9B4191CF8F73B04BB4F437E1F7F86ED50CAF3216@exchbe1sea.windows.marchex.com> Message-ID: <3870C46029D1F945B1472F170D2D979003C16393@de01exm64.ds.mot.com> See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Steve Dalberg Sent: Tuesday, April 29, 2008 10:33 AM To: rbridge at postel.org Subject: Re: [rbridge] Proposed details for announcing endnodes ... I agree, although from a protocol level, what is the fallout from conflicting MAC's? Will it cause protocol thrashing in any way? @@@ If you are just doing data plane learning (i.e., learning from received frames and decapsulated frames), it's pretty much like 802.1 bridges. Frames addressed to a MAC address can get sent out the wrong port until an old learned MAC address that is no longer correct times out. If you are listening to the VLAN end station address IS-IS frames, there could be multiple other Rbridges advertising that the have the same end station MAC address attached. The various different sources of information as to what Rbridge an end station address is attached two all have a one byte unsigned confidence level associated with them. If there are more than one with the same confidence, the current spec does not say how to choose but it seems likely that most implementations would just end up using whatever information they had most recent processed as, in general, "newer" information of equal confidence to what an Rbridge is currently using over-rides older information. See Section 4.6 of the current base protocol specification draft-ietf-trill-rbridge-protocol-07.txt. In any case, there isn't anything I would call "thrashing". As for the Layer 2 "pings" question, you'd be better off just looking for traffic sourced by the MAC in question over a couple of second period. Not sure what you would want to do with that, but if you don't see anything you can safely clear your forwarding table @@@ I don't see how you can say that for all layer 2 interfaces. IEEE 802.11, for example, rapid movement of end stations from one network attachment point to another has always been an assumed part of the protocol. It has explicit association, disassociation, and re-association messages (although it is really a bit more complex with authentication and security ...). @@@ Thanks, @@@ Donald Steve From touch at ISI.EDU Tue Apr 29 20:58:33 2008 From: touch at ISI.EDU (Joe Touch) Date: Tue, 29 Apr 2008 20:58:33 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu> <48174FF0.7020306@cisco.com> <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> Message-ID: <4817EE69.6070209@isi.edu> Eastlake III Donald-LDE008 wrote: ... > (2) The purpose of Rbridges is to do better than bridges. Arguments of > the form 'X is a known problem with bridges so we shouldn't solve it' > seem odd when the main premise of Rbridges is 'spanning tree is a known > problem with bridges so we WILL solve it'. My understanding is that the WG was created with a number of assumptions that limit how and where rbridges do better than bridges. Specifically, they do better in replacing spanning tree with Internet-style routing protocols. Specifically, they do NOT: - scale better than bridges - handle dynamic endstation movement better - handle silent receiver movement better - fix any other deficiency in the 802 suite I.e., TRILL is focused on the spanning tree issue. We're not here to fix issues that are not created by our solution. We discussed this with respect to scale numerous times, but it seems like it's worth stating in general. 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/20080429/92e9d61f/signature.bin From eric.gray at ericsson.com Wed Apr 30 09:34:05 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 30 Apr 2008 11:34:05 -0500 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu><48174FF0.7020306@cisco.com> <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02F5C218@eusrcmw721.eamcs.ericsson.se> Donald, On your second point, this is a specious argument. The fact that we (collectively) have decided to take on a specific problem that we (or at least some of us) feel exists with bridges does not grant license to including all problems that we (definitely some of us this time) also feel exist. That is a recipe for closure of the working group, rather than the work... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, April 29, 2008 9:30 PM > To: Dinesh G Dutt; Joe Touch > Cc: rbridge at postel.org > Subject: Re: [rbridge] Proposed details for announcing endnodes > > (1) I don't see any point in discussing ARP now since the > working group > has decided to move ARP and similar IP optimization out of the base > protocol draft to another document which does not yet even exist. > > (2) The purpose of Rbridges is to do better than bridges. Arguments of > the form 'X is a known problem with bridges so we shouldn't solve it' > seem odd when the main premise of Rbridges is 'spanning tree > is a known > problem with bridges so we WILL solve it'. > > Donald > > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Tuesday, April 29, 2008 12:42 PM > To: Joe Touch > Cc: rbridge at postel.org; Radia Perlman > Subject: Re: [rbridge] Proposed details for announcing endnodes > > Agree with Joe, > > Dinesh > Joe Touch wrote: > > > > > > Radia Perlman wrote: > >> Yeah. Moving endnodes is always an issue. Even with bridges. The > >> problem with having R1 (the one announcing that endnode E is > >> attached to R1) having a very short learning cache is that > makes R1's > > >> endnode announcement LSP information annoyingly volatile. > The problem > >> with the learning > >> cache timer being long is that R1 can be a black hole, sucking > >> traffic away from where E really is. > >> > >> There are some layer 2 protocols, I believe, with explicit > >> registration and keep-alives. (anyone care to chime in about which > >> protocols > >> these are?). Endnodes learned that way are good candidates for > >> explicitly advertising. > >> > >> For attached IP endnodes, R1 could do something like, if it seems > >> someone else advertise E, R1 could do an ARP to see if E is > >> still there. And there might be similar purely layer 2 > "pings". (are > >> there?) > > > > I do not believe rbridges should ever issue ARPs. Silent > movement is a > > > known problem with existing bridges; this is not an issue > we should be > > > solving. > > > > Joe > > > > > -------------------------------------------------------------- > ---------- > > -- > 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 Donald.Eastlake at motorola.com Wed Apr 30 09:35:46 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 30 Apr 2008 12:35:46 -0400 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <4817EE69.6070209@isi.edu> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu> <48174FF0.7020306@cisco.com> <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> <4817EE69.6070209@isi.edu> Message-ID: <3870C46029D1F945B1472F170D2D979003C16562@de01exm64.ds.mot.com> Hi Joe, I partly agree with you and partly disagree. See below at @@@ -----Original Message----- From: Joe Touch [mailto:touch at ISI.EDU] Sent: Tuesday, April 29, 2008 11:59 PM To: Eastlake III Donald-LDE008 Cc: Dinesh G Dutt; rbridge at postel.org Subject: Re: [rbridge] Proposed details for announcing endnodes Eastlake III Donald-LDE008 wrote: ... > (2) The purpose of Rbridges is to do better than bridges. Arguments of > the form 'X is a known problem with bridges so we shouldn't solve it' > seem odd when the main premise of Rbridges is 'spanning tree is a known > problem with bridges so we WILL solve it'. My understanding is that the WG was created with a number of assumptions that limit how and where rbridges do better than bridges. @@@ Yes, there were assumptions. But I see these as simply setting goals for the WG. While they may limit those goals, they do not "limit how and where RBridges do better than bridges". That would be a limit on results, not on goals. Specifically, they do better in replacing spanning tree with Internet-style routing protocols. @@@ They do. But the charter says very little about other performance related goals or non-goals. It mostly speaks about scope in more general terms, such as prohibiting the working group from designing a new routing protocols. I would point out that the WG charter also specifically states that the starting point is draft-perlman-rbridge-03.txt which had extensive material on ARP optimization, etc. The working group has decided to remove such IP optimizations from the base protocol specification and make them into a separate document, which is fine, but the effort would also have been charter conformant if it had left such provisions in the base protocol document and refined them. Specifically, they do NOT: - scale better than bridges @@@ As I say, I do not agree that there has been a decision, by the TRILL working group or in its charter, that Rbridges MUST be no better than bridges in scaling. It is just not particularly a goal of the group to have them scale better. Quite possibly they will scale better due to some Rbridge routing tables scaling with the number of Rbridges rather than the number of MAC addresses or some other reason. - handle dynamic endstation movement better - handle silent receiver movement better - fix any other deficiency in the 802 suite @@@ I'd have no problem is you said "they need not" above instead of "they do NOT". To, in effect, say that it is forbidden to include any facet in the TRILL protocol which happens to improve scaling or the handling of dynamic end station movement or the like seems to me to be unsupported by either our charter or the discussions that have been held. @@@ Thanks, @@@ Donald I.e., TRILL is focused on the spanning tree issue. We're not here to fix issues that are not created by our solution. We discussed this with respect to scale numerous times, but it seems like it's worth stating in general. Joe From touch at ISI.EDU Wed Apr 30 10:25:26 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 30 Apr 2008 10:25:26 -0700 Subject: [rbridge] Proposed details for announcing endnodes In-Reply-To: <3870C46029D1F945B1472F170D2D979003C16562@de01exm64.ds.mot.com> References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu> <48174FF0.7020306@cisco.com> <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> <4817EE69.6070209@isi.edu> <3870C46029D1F945B1472F170D2D979003C16562@de01exm64.ds.mot.com> Message-ID: <4818AB86.9000604@isi.edu> Eastlake III Donald-LDE008 wrote: > Hi Joe, > > I partly agree with you and partly disagree. See below at @@@ ... > Specifically, they do NOT: > - scale better than bridges > > @@@ As I say, I do not agree that there has been a decision, by the > TRILL working group or in its charter, that Rbridges MUST be no better > than bridges in scaling. We agreed that they need not support scale in the PAS discussions a long time ago. (i.e., NEED NOT, not "NOT"). ... > - handle dynamic endstation movement better > - handle silent receiver movement better > - fix any other deficiency in the 802 suite > > @@@ I'd have no problem is you said "they need not" above instead of > "they do NOT". Agreed. > To, in effect, say that it is forbidden to include any > facet in the TRILL protocol which happens to improve scaling or the > handling of dynamic end station movement or the like seems to me to be > unsupported by either our charter or the discussions that have been > held. Yes, there's a big difference between: A- a decision happens to support scale B- a decision is motivated by support for scale I agree that A is in-scope, and I think we agree that B is not. I think that some of the discussions for optimization here for announcing end-nodes fall under B rather than A. 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/20080430/0c9a8081/signature.bin