From Donald.Eastlake at motorola.com Sun Mar 9 13:42:00 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 9 Mar 2008 16:42:00 -0400 Subject: [rbridge] Comments on draft-ietf-trill-prob-02 Message-ID: <3870C46029D1F945B1472F170D2D97900395BAE0@de01exm64.ds.mot.com> Hi Joe, I have some comments as an individual on the latest Problem and Applicability Statement draft. I think all the significant ones relate to the problem statement Section 2: Multipathing: bridge learning requires consistent symmetric paths. This prohibits multipathing which improves bandwidth. (This is mentioned but I think it deserves more emphasis.) Something which, for want of a better term, I will call "quadratic address lookup stress": The spanning tree (or each of them in the case of MSTP) has a centroid. One is tempted to say root but, technically, the root bridge can be anywhere in the tree, even at a leaf node. By centroid, I mean the "center-of-traffic", where you have the most flows. For most real world cases, I think, the one or two centroid nodes need to learn the most addresses and they also have the highest bandwidth of data. Thus they need to implement both the fastest and largest address lookup facility, that is their learned address lookup is under quadratic stress. Rapid failover: I believe that RSTP (which is also used for each of the trees in MSTP) determines a backup root port on each bridge so that it can rapidly fail over to it if the primary path fails. So I think 802.1 bridge have this, to some extent. Even if the attachment of a node is cryptographically authenticated, stale information from an earlier attachment by that node is not promptly updated but has to time out. Most of my other comments are more editorial in nature. I'll send them and some suggested text to you directly. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From cds at cisco.com Mon Mar 10 07:18:51 2008 From: cds at cisco.com (Claudio DeSanti) Date: Mon, 10 Mar 2008 07:18:51 -0700 Subject: [rbridge] Proposed replacement for a paragraph in section 2.3 of draft-ietf-trill-rbridge-protocol-07 Message-ID: <47D5434B.1020404@cisco.com> 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. 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. 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. From Radia.Perlman at sun.com Wed Mar 19 07:19:10 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 19 Mar 2008 07:19:10 -0700 Subject: [rbridge] Proposed replacement for a paragraph in section 2.3 of draft-ietf-trill-rbridge-protocol-07 In-Reply-To: <47D5434B.1020404@cisco.com> References: <47D5434B.1020404@cisco.com> Message-ID: <47E120DE.9000101@sun.com> Not sure what's wrong with the paragraph to be replaced, other than a) the last line says "VLAN-V" when it shbould be "VLAN-x", and b) it doesn't mention which VLANs to act as appointed forwarder on, though I think that is elsewhere in the spec. It would be easier to evaluate the replacement text if you explained what is being fixed. Is it a technical change? (I think not, but maybe there's something subtle there that you are trying to fix). Or is it only editorial, to make things more precise? Or is it to include the explanation of appointed VLAN forwarders? (which is already explained elsewhere in the base spec, I think, for instance, section 4.2.4, 4.2.5). But I could not find a section that talks about what is in IS-IS Hellos, where presumably we'd explain about the set of VLANs to volunteer to be VLAN forwarder for, and where the DRB appoints VLAN forwarders in its own Hello. As for the proposed replacement text...it is mostly fine, though it's harder to read I think, and certainly longer. Maybe it's more precise, but for instance: " c) Forwarding VLANs set: the set of VLANs for which an RBridge port is appointed VLAN forwarder on a link." implies that an RBridge forwards on that set regardless of what the DRB says. In fact, the DRB has to be the one to appoint the forwarder. Perhaps this should be called "Potential forwarding VLAN set" and later, in " b) act as a VLAN forwarder for the VLANs included in its Forwarding VLANs set; and" say "act as a VLAN forwarder for the VLANs which the DRB appoints it to be forwarder for" And also, a non-DRB must list, in its HEllo, the "potential forwarding set", and the DRB must specify somehow (logically in the IS-IS Hello, but in theory the DRB's Hello could get too large if the DRB has to appoint VLAN forwarders on a fairly random set of VLANs). We could say the DRB R1 can specify a range of VLANs for R2 to be appointed forwarder on, and it only means the set of VLANs in the range that R2 volunteered for when R2 announced, in its own Hello, its potential forwarding set. Radia Claudio DeSanti wrote: > 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. > > 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. > > 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. > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Wed Mar 19 07:28:34 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 19 Mar 2008 07:28:34 -0700 Subject: [rbridge] VLAN registration Message-ID: <47E12312.7090304@sun.com> Just noticed this section got added to the spec. Some people expressed privately to me (and I share their concern) a concern that if RBridges had to support every new feature and protocol that IEEE comes up with, that we'll never be finished. And that at the very least supporting most of these should be MAYs rather than MUSTs or even SHOULDs. As for the VLAN registration frame -- it seems like R2, if it is VLAN x forwarder, should only send a VLAN x registration frame if R2 sees, in its LSP database, that some other RBridge in the campus has a VLAN x receiver. If VLAN x is dynamic, then R2 should not announce VLAN x in its LSP unless there is a VLAN x receiver on the link. If we think that RBridges should be supporting this at all... Radia From sgai at nuovasystems.com Wed Mar 19 08:30:45 2008 From: sgai at nuovasystems.com (Silvano Gai) Date: Wed, 19 Mar 2008 08:30:45 -0700 Subject: [rbridge] Proposed replacement for a paragraph in section 2.3of draft-ietf-trill-rbridge-protocol-07 In-Reply-To: <47E120DE.9000101@sun.com> References: <47D5434B.1020404@cisco.com> <47E120DE.9000101@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2039374E3@nuova-ex1.hq.nuovaimpresa.com> Radia, There are many differences: 1) the old text is not "per port" 2) the "default case" of the old text is not what we have discussed 3) The old text does not specify the forwarder sending hello on the forwarded VLANs -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 19, 2008 7:19 AM > To: Claudio DeSanti > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Proposed replacement for a paragraph in section > 2.3of draft-ietf-trill-rbridge-protocol-07 > > Not sure what's wrong with the paragraph to be replaced, other than > a) the last line says "VLAN-V" when it shbould be "VLAN-x", and > b) it doesn't mention which VLANs to act as appointed forwarder on, > though I think that is > elsewhere in the spec. > > It would be easier to evaluate the replacement text if you explained > what is being fixed. Is it > a technical change? (I think not, but maybe there's something subtle > there that you are trying > to fix). Or is it only editorial, to make things more precise? Or is it > to include the > explanation of appointed VLAN forwarders? (which is already explained > elsewhere in > the base spec, I think, for instance, section 4.2.4, 4.2.5). But I > could not find a section > that talks about what is in IS-IS Hellos, where presumably we'd explain > about the set of > VLANs to volunteer to be VLAN forwarder for, and where the DRB appoints > VLAN forwarders > in its own Hello. > > > > As for the proposed replacement > text...it is mostly fine, though it's harder to read I think, and > certainly longer. Maybe it's > more precise, but for instance: > " > > c) Forwarding VLANs set: the set of VLANs for which an RBridge port is > appointed VLAN forwarder on a link." > > implies that an RBridge forwards on that set regardless of what the DRB > says. > In fact, the DRB has to be the one to appoint the forwarder. Perhaps this > should be called "Potential forwarding VLAN set" and later, in > > " > b) act as a VLAN forwarder for the VLANs included in its Forwarding > VLANs set; and" > > say "act as a VLAN forwarder for the VLANs which the DRB appoints it to be > forwarder for" > > And also, a non-DRB must list, in its HEllo, the "potential forwarding > set", > and the DRB must specify somehow (logically in the IS-IS Hello, but in > theory > the DRB's Hello could get too large if the DRB has to appoint VLAN > forwarders > on a fairly random set of VLANs). > > We could say the DRB R1 can specify a range of VLANs for > R2 to be appointed forwarder on, and it only means the set of > VLANs in the range that R2 volunteered for when R2 announced, in its own > Hello, > its potential forwarding set. > > Radia > > > Claudio DeSanti wrote: > > 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. > > > > 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. > > > > 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. > > _______________________________________________ > > 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 Wed Mar 19 14:44:45 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 19 Mar 2008 17:44:45 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <47E12312.7090304@sun.com> References: <47E12312.7090304@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> Hi Radia, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Wednesday, March 19, 2008 10:29 AM To: Developing a hybrid router/bridge. Subject: [rbridge] VLAN registration Just noticed this section got added to the spec. Some people expressed privately to me (and I share their concern) a concern that if RBridges had to support every new feature and protocol that IEEE comes up with, that we'll never be finished. And that at the very least supporting most of these should be MAYs rather than MUSTs or even SHOULDs. @@@ I agree that Rbridges don't have to support new 802.1 features and protocols and, if they do, it should generally be a separate document, rather than part of the base protocol specification. However, I don't think dynamic VLAN registration is a particularly recent 802.1 feature. I haven't tried tracing back all the way back but dynamic VLAN registration is certainly there five years ago in 802.1Q-2003 and I suspect that it was added at the time or very shortly after VLANs were added. It is true that 802.1 recently replaced GVRP with MVRP but, while not backward compatible, this logically is a minor change. It primarily replaces a frame which indicates registration for one VLAN with a frame which allows you to provide indications for multiple VLANs. @@@ I think that many of those to whom it had occurred at all believed that the previous provision, that all the 802.1 bridging registration protocol frames would just be treated as non-IP derived multicast, would do the trick. And, in fact, I still believe that provision works fine for the 802.1 bridge multicast address registration protocol frames and will probably work in the unlikely event that 802.1 specifies any additional registration protocols that use multicast addresses in the currently reserved block. @@@ But, the strategy of just treating as non-IP derived multicast is completely broken for VLAN registration frames. It doesn't work for Rbridge ports, which had been previously overlooked, and it doesn't work for remaining bridges in the campus. So I didn't think of this as adding support for a feature but rather fixing completely broken support that was there. I posted a preliminary discussion of the issue here http://www.postel.org/pipermail/rbridge/2008-February/002871.html and talked about it at the March TRILL meeting as a technical change (see http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt slide 5). @@@ I personally don't have much problem with making MVRP support a SHOULD but it really doesn't seem like that much of a burden. It only requires some additional local behavior at Rbridge ports. There is no additional inter-Rbridge traffic and no change, by current thinking, in the link state database. As for the VLAN registration frame -- it seems like R2, if it is VLAN x forwarder, should only send a VLAN x registration frame if R2 sees, in its LSP database, that some other RBridge in the campus has a VLAN x receiver. If VLAN x is dynamic, then R2 should not announce VLAN x in its LSP unless there is a VLAN x receiver on the link. @@@ Although you can generally tell if you have an IP-derived multicast listener, can you generally tell if you have a VLAN-x receiver? @@@ The current TRILL specification also says that, by default, you only send VLAN registration frames out a port if you see a bridge out that port, although the port can also be configured to always or never send VLAN registration frames (keeping in mind that if you are not appointed forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN registration frames that attempt to de-register all VLANS). @@@ Thanks, @@@ Donald If we think that RBridges should be supporting this at all... Radia _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From ddutt at cisco.com Wed Mar 19 17:10:09 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 19 Mar 2008 17:10:09 -0700 Subject: [rbridge] VLAN registration In-Reply-To: <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> Message-ID: <47E1AB61.5050101@cisco.com> I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have found no customers wanting it so far. I don't see why RBridge spec needs to say anything more than how VLANs are advertised. How they discover what VLANs to advertise is a specific RBridge implementation detail. Some may use MVRP, some may use some proprietary protocol (this is not the reason for my opposition) and some may use local configuration. MVRP support is not a MUST or a SHOULD and I don't want RBridge support to be so either. Dinesh Eastlake III Donald-LDE008 wrote: > Hi Radia, > > See below at @@@ > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 19, 2008 10:29 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] VLAN registration > > Just noticed this section got added to the spec. Some people expressed > privately to me (and I share > their concern) a concern that > if RBridges had to support every new feature and protocol that IEEE > comes up with, that we'll never be finished. > And that at the very least supporting most of these should be MAYs > rather than MUSTs or even SHOULDs. > > @@@ I agree that Rbridges don't have to support new 802.1 features and > protocols and, if they do, it should generally be a separate document, > rather than part of the base protocol specification. However, I don't > think dynamic VLAN registration is a particularly recent 802.1 feature. > I haven't tried tracing back all the way back but dynamic VLAN > registration is certainly there five years ago in 802.1Q-2003 and I > suspect that it was added at the time or very shortly after VLANs were > added. It is true that 802.1 recently replaced GVRP with MVRP but, while > not backward compatible, this logically is a minor change. It primarily > replaces a frame which indicates registration for one VLAN with a frame > which allows you to provide indications for multiple VLANs. > > @@@ I think that many of those to whom it had occurred at all believed > that the previous provision, that all the 802.1 bridging registration > protocol frames would just be treated as non-IP derived multicast, would > do the trick. And, in fact, I still believe that provision works fine > for the 802.1 bridge multicast address registration protocol frames and > will probably work in the unlikely event that 802.1 specifies any > additional registration protocols that use multicast addresses in the > currently reserved block. > > @@@ But, the strategy of just treating as non-IP derived multicast is > completely broken for VLAN registration frames. It doesn't work for > Rbridge ports, which had been previously overlooked, and it doesn't work > for remaining bridges in the campus. So I didn't think of this as adding > support for a feature but rather fixing completely broken support that > was there. I posted a preliminary discussion of the issue here > http://www.postel.org/pipermail/rbridge/2008-February/002871.html > and talked about it at the March TRILL meeting as a technical change > (see > http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt > slide 5). > > @@@ I personally don't have much problem with making MVRP support a > SHOULD but it really doesn't seem like that much of a burden. It only > requires some additional local behavior at Rbridge ports. There is no > additional inter-Rbridge traffic and no change, by current thinking, in > the link state database. > > As for the VLAN registration frame -- it seems like R2, if it is VLAN x > forwarder, should only send a VLAN x registration > frame if R2 sees, in its LSP database, that some other RBridge in the > campus has a VLAN x receiver. If VLAN x is > dynamic, then R2 should not announce VLAN x in its LSP unless there is a > > VLAN x receiver on the link. > > @@@ Although you can generally tell if you have an IP-derived multicast > listener, can you generally tell if you have a VLAN-x receiver? > > @@@ The current TRILL specification also says that, by default, you only > send VLAN registration frames out a port if you see a bridge out that > port, although the port can also be configured to always or never send > VLAN registration frames (keeping in mind that if you are not appointed > forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN > registration frames that attempt to de-register all VLANS). > > @@@ Thanks, > @@@ Donald > > If we think that RBridges should be supporting this at all... > > 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 > > -- 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 Wed Mar 19 17:22:38 2008 From: sgai at nuovasystems.com (Silvano Gai) Date: Wed, 19 Mar 2008 17:22:38 -0700 Subject: [rbridge] VLAN registration In-Reply-To: <47E1AB61.5050101@cisco.com> References: <47E12312.7090304@sun.com><3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> <47E1AB61.5050101@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA203937C15@nuova-ex1.hq.nuovaimpresa.com> I am ABSOLUTELY opposed to have MVRP as a SHOULD. Today MVRP has ZERO deployment -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Wednesday, March 19, 2008 5:10 PM > To: Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge.; Radia Perlman > Subject: Re: [rbridge] VLAN registration > > I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have > found no customers wanting it so far. I don't see why RBridge spec needs > to say anything more than how VLANs are advertised. How they discover > what VLANs to advertise is a specific RBridge implementation detail. > Some may use MVRP, some may use some proprietary protocol (this is not > the reason for my opposition) and some may use local configuration. MVRP > support is not a MUST or a SHOULD and I don't want RBridge support to be > so either. > > Dinesh > Eastlake III Donald-LDE008 wrote: > > Hi Radia, > > > > See below at @@@ > > > > -----Original Message----- > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > > Behalf Of Radia Perlman > > Sent: Wednesday, March 19, 2008 10:29 AM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] VLAN registration > > > > Just noticed this section got added to the spec. Some people expressed > > privately to me (and I share > > their concern) a concern that > > if RBridges had to support every new feature and protocol that IEEE > > comes up with, that we'll never be finished. > > And that at the very least supporting most of these should be MAYs > > rather than MUSTs or even SHOULDs. > > > > @@@ I agree that Rbridges don't have to support new 802.1 features and > > protocols and, if they do, it should generally be a separate document, > > rather than part of the base protocol specification. However, I don't > > think dynamic VLAN registration is a particularly recent 802.1 feature. > > I haven't tried tracing back all the way back but dynamic VLAN > > registration is certainly there five years ago in 802.1Q-2003 and I > > suspect that it was added at the time or very shortly after VLANs were > > added. It is true that 802.1 recently replaced GVRP with MVRP but, while > > not backward compatible, this logically is a minor change. It primarily > > replaces a frame which indicates registration for one VLAN with a frame > > which allows you to provide indications for multiple VLANs. > > > > @@@ I think that many of those to whom it had occurred at all believed > > that the previous provision, that all the 802.1 bridging registration > > protocol frames would just be treated as non-IP derived multicast, would > > do the trick. And, in fact, I still believe that provision works fine > > for the 802.1 bridge multicast address registration protocol frames and > > will probably work in the unlikely event that 802.1 specifies any > > additional registration protocols that use multicast addresses in the > > currently reserved block. > > > > @@@ But, the strategy of just treating as non-IP derived multicast is > > completely broken for VLAN registration frames. It doesn't work for > > Rbridge ports, which had been previously overlooked, and it doesn't work > > for remaining bridges in the campus. So I didn't think of this as adding > > support for a feature but rather fixing completely broken support that > > was there. I posted a preliminary discussion of the issue here > > http://www.postel.org/pipermail/rbridge/2008-February/002871.html > > and talked about it at the March TRILL meeting as a technical change > > (see > > http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt > > slide 5). > > > > @@@ I personally don't have much problem with making MVRP support a > > SHOULD but it really doesn't seem like that much of a burden. It only > > requires some additional local behavior at Rbridge ports. There is no > > additional inter-Rbridge traffic and no change, by current thinking, in > > the link state database. > > > > As for the VLAN registration frame -- it seems like R2, if it is VLAN x > > forwarder, should only send a VLAN x registration > > frame if R2 sees, in its LSP database, that some other RBridge in the > > campus has a VLAN x receiver. If VLAN x is > > dynamic, then R2 should not announce VLAN x in its LSP unless there is a > > > > VLAN x receiver on the link. > > > > @@@ Although you can generally tell if you have an IP-derived multicast > > listener, can you generally tell if you have a VLAN-x receiver? > > > > @@@ The current TRILL specification also says that, by default, you only > > send VLAN registration frames out a port if you see a bridge out that > > port, although the port can also be configured to always or never send > > VLAN registration frames (keeping in mind that if you are not appointed > > forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN > > registration frames that attempt to de-register all VLANS). > > > > @@@ Thanks, > > @@@ Donald > > > > If we think that RBridges should be supporting this at all... > > > > 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 > > > > > > -- > 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 Mar 19 18:08:35 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 19 Mar 2008 18:08:35 -0700 Subject: [rbridge] VLAN registration In-Reply-To: <47E1AB61.5050101@cisco.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> <47E1AB61.5050101@cisco.com> Message-ID: <47E1B913.90709@cisco.com> Typing with one hand is a pain. I meant to say MVRP support is not required in .1d bridges and so neither should it be in Rbridges, Dinesh Dinesh G Dutt wrote: > I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have > found no customers wanting it so far. I don't see why RBridge spec needs > to say anything more than how VLANs are advertised. How they discover > what VLANs to advertise is a specific RBridge implementation detail. > Some may use MVRP, some may use some proprietary protocol (this is not > the reason for my opposition) and some may use local configuration. MVRP > support is not a MUST or a SHOULD and I don't want RBridge support to be > so either. > > Dinesh > Eastlake III Donald-LDE008 wrote: > >> Hi Radia, >> >> See below at @@@ >> >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On >> Behalf Of Radia Perlman >> Sent: Wednesday, March 19, 2008 10:29 AM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] VLAN registration >> >> Just noticed this section got added to the spec. Some people expressed >> privately to me (and I share >> their concern) a concern that >> if RBridges had to support every new feature and protocol that IEEE >> comes up with, that we'll never be finished. >> And that at the very least supporting most of these should be MAYs >> rather than MUSTs or even SHOULDs. >> >> @@@ I agree that Rbridges don't have to support new 802.1 features and >> protocols and, if they do, it should generally be a separate document, >> rather than part of the base protocol specification. However, I don't >> think dynamic VLAN registration is a particularly recent 802.1 feature. >> I haven't tried tracing back all the way back but dynamic VLAN >> registration is certainly there five years ago in 802.1Q-2003 and I >> suspect that it was added at the time or very shortly after VLANs were >> added. It is true that 802.1 recently replaced GVRP with MVRP but, while >> not backward compatible, this logically is a minor change. It primarily >> replaces a frame which indicates registration for one VLAN with a frame >> which allows you to provide indications for multiple VLANs. >> >> @@@ I think that many of those to whom it had occurred at all believed >> that the previous provision, that all the 802.1 bridging registration >> protocol frames would just be treated as non-IP derived multicast, would >> do the trick. And, in fact, I still believe that provision works fine >> for the 802.1 bridge multicast address registration protocol frames and >> will probably work in the unlikely event that 802.1 specifies any >> additional registration protocols that use multicast addresses in the >> currently reserved block. >> >> @@@ But, the strategy of just treating as non-IP derived multicast is >> completely broken for VLAN registration frames. It doesn't work for >> Rbridge ports, which had been previously overlooked, and it doesn't work >> for remaining bridges in the campus. So I didn't think of this as adding >> support for a feature but rather fixing completely broken support that >> was there. I posted a preliminary discussion of the issue here >> http://www.postel.org/pipermail/rbridge/2008-February/002871.html >> and talked about it at the March TRILL meeting as a technical change >> (see >> http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt >> slide 5). >> >> @@@ I personally don't have much problem with making MVRP support a >> SHOULD but it really doesn't seem like that much of a burden. It only >> requires some additional local behavior at Rbridge ports. There is no >> additional inter-Rbridge traffic and no change, by current thinking, in >> the link state database. >> >> As for the VLAN registration frame -- it seems like R2, if it is VLAN x >> forwarder, should only send a VLAN x registration >> frame if R2 sees, in its LSP database, that some other RBridge in the >> campus has a VLAN x receiver. If VLAN x is >> dynamic, then R2 should not announce VLAN x in its LSP unless there is a >> >> VLAN x receiver on the link. >> >> @@@ Although you can generally tell if you have an IP-derived multicast >> listener, can you generally tell if you have a VLAN-x receiver? >> >> @@@ The current TRILL specification also says that, by default, you only >> send VLAN registration frames out a port if you see a bridge out that >> port, although the port can also be configured to always or never send >> VLAN registration frames (keeping in mind that if you are not appointed >> forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN >> registration frames that attempt to de-register all VLANS). >> >> @@@ Thanks, >> @@@ Donald >> >> If we think that RBridges should be supporting this at all... >> >> 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 >> >> >> > > -- 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 Wed Mar 19 19:50:10 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 19 Mar 2008 21:50:10 -0500 Subject: [rbridge] VLAN registration In-Reply-To: <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF02B1134C@eusrcmw721.eamcs.ericsson.se> Donald/Radia, I agree with Donald on all of his points in this mail. -- 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: Wednesday, March 19, 2008 5:45 PM > To: Radia Perlman > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] VLAN registration > > Hi Radia, > > See below at @@@ > > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 19, 2008 10:29 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] VLAN registration > > Just noticed this section got added to the spec. Some people > expressed > privately to me (and I share > their concern) a concern that > if RBridges had to support every new feature and protocol that IEEE > comes up with, that we'll never be finished. > And that at the very least supporting most of these should be MAYs > rather than MUSTs or even SHOULDs. > > @@@ I agree that Rbridges don't have to support new 802.1 features and > protocols and, if they do, it should generally be a separate document, > rather than part of the base protocol specification. However, I don't > think dynamic VLAN registration is a particularly recent > 802.1 feature. > I haven't tried tracing back all the way back but dynamic VLAN > registration is certainly there five years ago in 802.1Q-2003 and I > suspect that it was added at the time or very shortly after VLANs were > added. It is true that 802.1 recently replaced GVRP with MVRP > but, while > not backward compatible, this logically is a minor change. It > primarily > replaces a frame which indicates registration for one VLAN > with a frame > which allows you to provide indications for multiple VLANs. > > @@@ I think that many of those to whom it had occurred at all believed > that the previous provision, that all the 802.1 bridging registration > protocol frames would just be treated as non-IP derived > multicast, would > do the trick. And, in fact, I still believe that provision works fine > for the 802.1 bridge multicast address registration protocol > frames and > will probably work in the unlikely event that 802.1 specifies any > additional registration protocols that use multicast addresses in the > currently reserved block. > > @@@ But, the strategy of just treating as non-IP derived multicast is > completely broken for VLAN registration frames. It doesn't work for > Rbridge ports, which had been previously overlooked, and it > doesn't work > for remaining bridges in the campus. So I didn't think of > this as adding > support for a feature but rather fixing completely broken support that > was there. I posted a preliminary discussion of the issue here > http://www.postel.org/pipermail/rbridge/2008-February/002871.html > and talked about it at the March TRILL meeting as a technical change > (see > http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt > slide 5). > > @@@ I personally don't have much problem with making MVRP support a > SHOULD but it really doesn't seem like that much of a burden. It only > requires some additional local behavior at Rbridge ports. There is no > additional inter-Rbridge traffic and no change, by current > thinking, in > the link state database. > > As for the VLAN registration frame -- it seems like R2, if it > is VLAN x > forwarder, should only send a VLAN x registration > frame if R2 sees, in its LSP database, that some other RBridge in the > campus has a VLAN x receiver. If VLAN x is > dynamic, then R2 should not announce VLAN x in its LSP unless > there is a > > VLAN x receiver on the link. > > @@@ Although you can generally tell if you have an IP-derived > multicast > listener, can you generally tell if you have a VLAN-x receiver? > > @@@ The current TRILL specification also says that, by > default, you only > send VLAN registration frames out a port if you see a bridge out that > port, although the port can also be configured to always or never send > VLAN registration frames (keeping in mind that if you are not > appointed > forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN > registration frames that attempt to de-register all VLANS). > > @@@ Thanks, > @@@ Donald > > If we think that RBridges should be supporting this at all... > > 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 Caitlin.Bestler at neterion.com Thu Mar 20 05:36:33 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Thu, 20 Mar 2008 08:36:33 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77033BA55D@nekter> I think we need to de-couple TRILL compliance from any specific level of 802.1 compliance on any specific 802.1 cloud/protocol suite. 802.1 is in the process of defining various "clouds", such as Data Center (for Congestion Notification and other purposes) and AVB (audio-vide-bridging). The issue of where an RBridge should or even can extend those clouds is complex, and a rat hold best avoided by allowing implementers to do as litte or as much as they want and only dealing with issues that affect RBridge functionality. Participation in any of these clouds should clearly be optional (as in MAY). The draft should be clear that 802.1 documents will describe RBridge interactions with conventional bridges. Those documents already protect the right of end stations and bridges to upgrade or not upgrade at their own pace. That suggests the only extent to which TRILL needs to be involved is to allow a mechanism by which two RBridges can communicate their intent to extend a specific 802.1 cloud through the RBridge tunnel. Even that can be worked around. To the extent that standard signaling is required I think it can be added in later documents as additional TLVs in the discovery process. I certainly hope that RBridge functionality is considered as a superset of Bridge functionality, and not as an excuse for freezing Bridge features at a certain revision. But it's up to the market to determine which 802.1 protocols are relevant, not IETF. From james.d.carlson at Sun.COM Thu Mar 20 06:32:43 2008 From: james.d.carlson at Sun.COM (James Carlson) Date: Thu, 20 Mar 2008 09:32:43 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> Message-ID: <18402.26491.580828.950447@gargle.gargle.HOWL> Eastlake III Donald-LDE008 writes: > As for the VLAN registration frame -- it seems like R2, if it is VLAN x > forwarder, should only send a VLAN x registration > frame if R2 sees, in its LSP database, that some other RBridge in the > campus has a VLAN x receiver. That implies that RBridges need to manipulate MVRP messages in order to play at this game. The MVRP request that an RBridge sends out needs to be the bitwise sum of all of the requests received on all other LANs by the RBridge cloud plus the list of enabled VLANs known in the LSP database. > @@@ Although you can generally tell if you have an IP-derived multicast > listener, can you generally tell if you have a VLAN-x receiver? No, because of manual configuration. VLANs can lurk. I suspect that SHOULD for MVRP carries a bit too much force here. It's an optional part of the IEEE world, and, as best I can tell, it's not really used anywhere (yet?). SHOULD means that vendors need to have a very good reason to avoid implementing, and not just that their target markets use .1d bridging only. I think optional parts ought to be listed as MAY in the base specification or -- much better yet -- listed in a separate document (or documents) where you can be free with the MUSTs as needed. Things we list in the base document need to be the things that are required to build an implementation. Is MVRP really one of those things? -- 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 Radia.Perlman at sun.com Fri Mar 28 18:57:29 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 28 Mar 2008 18:57:29 -0700 Subject: [rbridge] "Inter-RBridge-only" port Message-ID: <47EDA209.6040902@sun.com> In this note I'll describe a feature that Anoop suggested (I think he originally suggested it). I think it is a good idea, since I believe it is completely safe, even with misconfiguration, and greatly lowers overhead for those ports so configured. The idea is as follows: If port p is configured to be inter-RBridge-only on RB1, then RB1: a) ignores all traffic that is not TRILL-encapsulated b) sends IS-IS Hellos only with one VLAN (can we say VLAN 1, unconfigurable?) c) sets a flag in its IS-IS Hello that RB1 considers this port to be inter-RBridge only Why this is a good idea 1) on port p, RB1 only has to send Hellos with one VLAN -- we don't have to be super careful about winding up with two DRBs 2) RB1 only has to listen for Hellos with one VLAN (the one it is configured to send on) -- again, it's not tragic if there are two DRBs -- RB1 just won't form adjacencies with other RBs on the cloud that are sending Hellos with a different VLAN tag 3) if all the RBridges on the cloud are so configured, then unknown destination and multicast traffic need not be decapsulated onto the link. Why this is not dangerous a) if R1 is configured this way, and neighbor R2 on the same cloud is not...then if R1 is elected DRB, no traffic will be encapsulated/decapsulated onto the link since R1 will not appoint R2 as VLAN forwarder for any VLANs (all the endnodes on the link will be orphaned) b) if R2 is configured as inter-RBridge-only on that port and R1, the DRB, is not, then again there is no issue -- R1 will not appoint R2 appointed VLAN forwarder (R1 will be the forwarder) c) if R1 and R2 are both configured as p=inter-RBridge-only, and R1 is configured to send Hellos on a different VLAN than R2 and they don't see each other's hellos, then they won't form an adjacency. But there will be no loops. I don't care what this feature is called. Proposals for other names have been "core", "trunk", "non-access". Radia From Radia.Perlman at sun.com Fri Mar 28 19:55:24 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 28 Mar 2008 19:55:24 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees Message-ID: <47EDAF9C.7070000@sun.com> 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 From Donald.Eastlake at motorola.com Sun Mar 30 10:24:55 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 13:24:55 -0400 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <47EDAF9C.7070000@sun.com> References: <47EDAF9C.7070000@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> 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 From Donald.Eastlake at motorola.com Sun Mar 30 10:40:15 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 13:40:15 -0400 Subject: [rbridge] "Inter-RBridge-only" port In-Reply-To: <47EDA209.6040902@sun.com> References: <47EDA209.6040902@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> Hi, I agree that being able to have such a "trunk port" is a good idea; however, I'm not sure it needs any special feature. In particular, we currently provide that an Rbridge port can be configured to provide no end station support, that is, to not decapsulate any native frames onto that link and to ignore any native frames it receives. And we currently provide that an Rbridge port can be configured as to what VLANs it sends Hellos on and what VLANs it listens on. So, as far as I can see, the only actual behavioral change proposed below is the addition of the "inter-Rbridge" flag in the Hello. This seems to only be useful in checking for misconfiguration. Perhaps the thing to do is to possibly re-name the existing "no end-station support" per port flag to be the "trunk" flag or whatever and report it in the Hello. See a few 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 9:57 PM To: Developing a hybrid router/bridge. Subject: [rbridge] "Inter-RBridge-only" port In this note I'll describe a feature that Anoop suggested (I think he originally suggested it). I think it is a good idea, since I believe it is completely safe, even with misconfiguration, and greatly lowers overhead for those ports so configured. The idea is as follows: If port p is configured to be inter-RBridge-only on RB1, then RB1: a) ignores all traffic that is not TRILL-encapsulated @@@ Actually, it still has to pay attention to control frames like PAUSE or, if implemented, local link discovery, etc. It just ignores native frames. b) sends IS-IS Hellos only with one VLAN (can we say VLAN 1, unconfigurable?) @@@ It might be that a point-to-point link between two Rbridges is obtained from some provider which just gives you a virtual link in an arbitrary VLAN, say VLAN 798, so your frames have to use that outer VLAN ID. c) sets a flag in its IS-IS Hello that RB1 considers this port to be inter-RBridge only Why this is a good idea 1) on port p, RB1 only has to send Hellos with one VLAN -- we don't have to be super careful about winding up with two DRBs 2) RB1 only has to listen for Hellos with one VLAN (the one it is configured to send on) -- again, it's not tragic if there are two DRBs -- RB1 just won't form adjacencies with other RBs on the cloud that are sending Hellos with a different VLAN tag 3) if all the RBridges on the cloud are so configured, then unknown destination and multicast traffic need not be decapsulated onto the link. Why this is not dangerous a) if R1 is configured this way, and neighbor R2 on the same cloud is not...then if R1 is elected DRB, no traffic will be encapsulated/decapsulated onto the link since R1 will not appoint R2 as VLAN forwarder for any VLANs (all the endnodes on the link will be orphaned) b) if R2 is configured as inter-RBridge-only on that port and R1, the DRB, is not, then again there is no issue -- R1 will not appoint R2 appointed VLAN forwarder (R1 will be the forwarder) c) if R1 and R2 are both configured as p=inter-RBridge-only, and R1 is configured to send Hellos on a different VLAN than R2 and they don't see each other's hellos, then they won't form an adjacency. But there will be no loops. I don't care what this feature is called. Proposals for other names have been "core", "trunk", "non-access". @@@ If this sort of port configuration needs a name, I think "trunk" would be best. Radia @@@ It occurs to me that if a port is configured to provide no end station support (ignore native frames and not decapsulate), then it should not contribute to the VLANs advertised by that RBridge in the link state database. The only reason to advertise the enablement of a VLAN on one or more ports at an Rbridge is to attract certain multi-destination encapsulated traffic to that Rbridge but such traffic will not be decapsulated out such a port. This needs to be mentioned in the base protocol document. @@@ We might want to add a note pointing out the desirability of such trunk port configuration under some circumstances and recommending that it be made easy to so configure a port. (Summary: enable only VLAN x, send Hellos only on VLAN x, disable end station support, turn on input VLAN filtering) @@@ Thanks, @@@ Donald From Donald.Eastlake at motorola.com Sun Mar 30 10:50:55 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 13:50:55 -0400 Subject: [rbridge] Philadelphia minutes have been uploaded Message-ID: <3870C46029D1F945B1472F170D2D979003A9521C@de01exm64.ds.mot.com> Hi, Minutes of the Philadelphia TRILL WG meeting earlier this month have been uploaded to the meeting materials page at http://www3.ietf.org/proceedings/08mar/minutes/trill.txt. Thanks, Donald ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Donald.Eastlake at motorola.com Sun Mar 30 10:52:25 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 13:52:25 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <47E1AB61.5050101@cisco.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> <47E1AB61.5050101@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A9521D@de01exm64.ds.mot.com> Hi Dinesh, There have been posts to this list stating that there are customers that want and use standards based dynamic VLAN registration. It seems to me that the completely broken state of dynamic VLAN registration that was in the TRILL base protocol draft version -06 needed to be fixed. If you have two 802.1Q bridges, say X and Z, and put an Rbridge conformant to the -06 spec between them or if you have three such bridges connected in sequence, say X - Y - Z, and replace Y with such an Rbridge, the Rbridge will generally break any dynamic VLAN registration going on between these bridges, whether you are using GVRP or the new MVRP. How can such network damage be consistent with our goals of incremental deployment and VLAN support? It seemed to me that Rbridges should be forward looking, so I thought they should support the newer MVRP, and Rbridges should be simple, so I didn't even bother to think much about how you could support both GVRP and MVRP (although you could do that as the frames seem to be easily distinguishable). That's why I just said MVRP in my earlier posting to the Rbridge list and in my presentation to the TRILL working group in Philadelphia. MVRP also appears to me to be technically superior to GVRP because you can sometimes replace thousands of GVRP frames with one MVRP frame. I assume by "advertise" VLANs below you mean propagate through the link state database. I've got no problem with there being additional methods to configure VLANs but I think we will need to say how to configure them with SNMP (even if that is mostly just a pointer to an existing bridge MIB) and say how they work with 802.1 dynamic VLAN registration. In a later message you clarified your statement that MVRP was not mandatory to implement by narrowing that claim to 802.1D bridges. Since 802.1D bridges are VLAN ignorant and do not support VLANs, it is hardly surprising that they do not mandate implementing dynamic VLAN registration. But the TRILL WG has decided that Rbridges will support VLANs and, in most cases, be incrementally deployable into 802.1Q bridged LANs. As I document in a separate message, as far as I can see, 802.1Q requires the implementation of dynamic VLAN registration. Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Wednesday, March 19, 2008 8:10 PM To: Eastlake III Donald-LDE008 Cc: Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] VLAN registration I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have found no customers wanting it so far. I don't see why RBridge spec needs to say anything more than how VLANs are advertised. How they discover what VLANs to advertise is a specific RBridge implementation detail. Some may use MVRP, some may use some proprietary protocol (this is not the reason for my opposition) and some may use local configuration. MVRP support is not a MUST or a SHOULD and I don't want RBridge support to be so either. Dinesh From Donald.Eastlake at motorola.com Sun Mar 30 10:54:24 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 13:54:24 -0400 Subject: [rbridge] Implementation requirements of dynamic VLAN registration in IEEE 802.1VLAN bridging standards Message-ID: <3870C46029D1F945B1472F170D2D979003A9521E@de01exm64.ds.mot.com> Hi, I just wanted to make crystal clear why I believe that the IEEE 802.1 VLAN bridging standards mandate support for dynamic VLAN registration. The current baseline IEEE 802.1 Virtual Bridged LAN standard document is IEEE 802.1Q-2005. Under that document, implementation of the GVRP VLAN registration protocol is mandatory. In particular, in 802.1Q-2005 general description Section 5.3, it says (where "shall" means mandatory): "An implementation of a VLAN-aware Bridge shall ... Allow automatic configuration and management of VLAN topology using the Generic Attribute Registration Protocol (GARP) VLAN Registration Protocol (GVRP) (Clause 11) on all Ports; ..." and in the conformance statement annex (PICS) whose purpose is to give levels of implementation requirement, the feature is expressed as: "Does the implementation support the ability to perform automatic configuration and management of VLAN topology information by means of GVRP on all Ports?" and the Status is M (mandatory). There are approved amendments that have been adopted to 802.1Q-2005, but not yet rolled into the base document, including IEEE 802.1ak-2007. This amendment blows away GARP and GVRP and substitutes MRP and MVRP. In particular, the corresponding general Section (now 5.4 due to another amendment) says: "An implementation of a VLAN-aware Bridge component shall ... Allow automatic configuration and management of VLAN topology using the Multiple VLAN Registration Protocol (MVRP) (5.4.2, Clause 11) on all Ports; ..." and in the 802.1ak-2007 PICS, the feature is expressed as "Is automatic configuration and management of VLAN topology using MVRP supported?" and the Status is M (mandatory). So, as far as I can see, any bridge that claims 802.1Q compliance is required to implement dynamic VLAN registration and if it claims compliance with the current standard, it is required to implement MVRP. Thanks, Donald Acronyms: GARP = General Attribute Registration Protocol GVRP = GARP VLAN Registration Protocol MRP = Multiple Registration Protocol MVRP = Multiple VLAN Registration Protocol PICS = Protocol Implementation Conformance Statement VLAN = Virtual Local Area Network ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake at motorola.com From Radia.Perlman at sun.com Sun Mar 30 11:00:03 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 30 Mar 2008 11:00:03 -0700 Subject: [rbridge] (slight) modification of how to choose mulitcast trees In-Reply-To: <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> References: <47EDAF9C.7070000@sun.com> <3870C46029D1F945B1472F170D2D979003A95216@de01exm64.ds.mot.com> Message-ID: <47EFD523.4000303@sun.com> 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 > From Radia.Perlman at sun.com Sun Mar 30 11:02:51 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 30 Mar 2008 11:02:51 -0700 Subject: [rbridge] "Inter-RBridge-only" port In-Reply-To: <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> References: <47EDA209.6040902@sun.com> <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> Message-ID: <47EFD5CB.5080508@sun.com> Eastlake III Donald-LDE008 wrote: > > @@@ It occurs to me that if a port is configured to provide no end > station support (ignore native frames and not decapsulate), then it > should not contribute to the VLANs advertised by that RBridge in the > link state database. The only reason to advertise the enablement of a > VLAN on one or more ports at an Rbridge is to attract certain > multi-destination encapsulated traffic to that Rbridge but such traffic > will not be decapsulated out such a port. This needs to be mentioned in > the base protocol document. > > Yes. Good point. From Donald.Eastlake at motorola.com Sun Mar 30 11:31:18 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 14:31:18 -0400 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: <3870C46029D1F945B1472F170D2D979003A95221@de01exm64.ds.mot.com> Hi Radia, See below at ### -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman at sun.com] Sent: Sunday, March 30, 2008 2:00 PM To: Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] (slight) modification of how to choose mulitcast trees 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". ### It's obviously simpler to use a fixed default but I don't see what's so hard about a computed default. To be really specific, you do something like pick a distinguished value, say zero, and if the highest priority Rbridge is advertising that zero trees should be computed then each Rbridge just counts the number of Rbridges in sees its link state database and takes the specified function of that number (square root in my suggestion) and computes that many trees. Or, alternatively, only the highest priority Rbridge does this calculation and promulgates the results. 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. ### No problem... That's why I said Rbridge adjacencies. As long as there is anything that can change, you have all the problems of volatility so you have to be able to handle transitions. Currently pseudonodes can't be tree roots so there are a number of adjustments to make if we change that. 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? ### Well, the LID option assumes you can't have more than about 64K ports :-) so you could just use two bytes for order and could invert all the bits in those bytes to get the right ordering of the multiprecision priority quantity. 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. ### Yes, you could do something like that. I would think you'd like RBridges to do a good job of selecting tree roots in relatively small unconfigured campuses which is mostly what this "order" think is about. In large heavily configured campuses, I would think that normally none of these tie breakers would make any difference. You would configure all your Rbridges to say you wanted N1 roots and would configure exactly N1 Rbridges with highest priority and some number N2 of your Rbridges as back-ups probably with priorities from (highest - 1) through (highest - N2). Or maybe you would have configured N1+N2 Rbridges with priority from 0 through N1+N2-1 or whatever... In these cases, only under rare circumstances where a couple of Rbridges tied due to unintended configuration would the tie breakers have any effect. Radia ### Thanks, ### Donald 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 > From Donald.Eastlake at motorola.com Sun Mar 30 11:52:35 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 14:52:35 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E011CB986@HQ-EXCH-5.corp.brocade.com> References: <47E12312.7090304@sun.com><3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com><47E1AB61.5050101@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA203937C15@nuova-ex1.hq.nuovaimpresa.com> <4C94DE2070B172459E4F1EE14BD2364E011CB986@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A95223@de01exm64.ds.mot.com> 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... Thanks, Donald -----Original Message----- From: Anoop Ghanwani [mailto:aghanwan at brocade.com] Sent: Thursday, March 20, 2008 10:54 AM To: Silvano Gai; Dinesh G Dutt; Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge.; Radia Perlman Subject: RE: [rbridge] VLAN registration While I'm not sure I agree with the "ZERO deployment" statement, I think it's OK to mention MVRP support as MAY. Anoop From Donald.Eastlake at motorola.com Sun Mar 30 20:19:21 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Sun, 30 Mar 2008 23:19:21 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <18402.26491.580828.950447@gargle.gargle.HOWL> References: <47E12312.7090304@sun.com><3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> <18402.26491.580828.950447@gargle.gargle.HOWL> Message-ID: <3870C46029D1F945B1472F170D2D979003A95273@de01exm64.ds.mot.com> See below at ### -----Original Message----- From: James Carlson [mailto:james.d.carlson at Sun.COM] Sent: Thursday, March 20, 2008 9:33 AM To: Eastlake III Donald-LDE008 Cc: Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] VLAN registration Eastlake III Donald-LDE008 writes: ### (Actually, the "> " prefixed lines immediately below were, I believe, from Radia Perlman. > As for the VLAN registration frame -- it seems like R2, if it is VLAN x > forwarder, should only send a VLAN x registration > frame if R2 sees, in its LSP database, that some other RBridge in the > campus has a VLAN x receiver. That implies that RBridges need to manipulate MVRP messages in order to play at this game. The MVRP request that an RBridge sends out needs to be the bitwise sum of all of the requests received on all other LANs by the RBridge cloud plus the list of enabled VLANs known in the LSP database. ### I don't think so. MVRPs can be handled locally at each port based on the configuration and state of that port and the link state database. I don't think there is a dependence on requests received except to the extent they change the state of a port and that in turn affects the link state database. Perhaps I should write up a more detailed description of how this would work. > @@@ Although you can generally tell if you have an IP-derived multicast > listener, can you generally tell if you have a VLAN-x receiver? No, because of manual configuration. VLANs can lurk. ### Right. So really my point was that, since you can't tell if there is a VLAN-x listener, if you are sending MVRPs, you have to formulate them based not on some other Rbridge in the campus having a VLAN-x receiver but just on some other Rbridge in the campus being a VLAN-x appointed forwarder, which is what is reported in the link state database. I suspect that SHOULD for MVRP carries a bit too much force here. It's an optional part of the IEEE world, and, as best I can tell, it's not really used anywhere (yet?). SHOULD means that vendors need to have a very good reason to avoid implementing, and not just that their target markets use .1d bridging only. ### I wish, when people slam MVRP, they would make it clear if they are slamming dynamic VLAN registration or just MVRP. ### As per my other messages, I think we have been targeting 802.1Q bridges. Lots of things could be vastly simplified in Rbridges if they, like 802.1D bridges, didn't need to support VLANs at all. And, as far as I can tell, MVRP is a mandatory to implement part of 802.1Q. And I don't think we should look only at today's deployment. Presumably Rbridges should be aimed at a future state of deployment. I think optional parts ought to be listed as MAY in the base specification or -- much better yet -- listed in a separate document (or documents) where you can be free with the MUSTs as needed. ### It seems like you should still say something about what you do when you receive a VLAN registration frame. Things we list in the base document need to be the things that are required to build an implementation. Is MVRP really one of those things? ### Well, the group gets to decide that. But I suspect that dynamic VLAN registration, either GVRP or MVRP, takes at least an order of magnitude fewer lines of code that implementing SNMP and static VLAN configuration. And in 802.1Q, MVRP is mandatory while configuration by a management protocol is optional. ### Thanks, ### Donald -- 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 Sun Mar 30 21:30:56 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sun, 30 Mar 2008 21:30:56 -0700 Subject: [rbridge] VLAN registration In-Reply-To: <3870C46029D1F945B1472F170D2D979003A9521D@de01exm64.ds.mot.com> References: <47E12312.7090304@sun.com> <3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com> <47E1AB61.5050101@cisco.com> <3870C46029D1F945B1472F170D2D979003A9521D@de01exm64.ds.mot.com> Message-ID: <47F06900.4050906@cisco.com> Donald, First off, if I used the word .1D bridges, I really meant .1Q bridges. IEEE does NOT mandate MVRP or MMRP to be implemented in 802.1Q bridges. Dynamic VLAN registration is not mandated in the 802.1Q 2005 standard. So, TRILL spec should not either. Further, I know of no customer using these protocols in their networks and I work closely with a lot of customers in the field, from small networks to F500 customers. Next, are we going to specify what an Rbridge does for every single IEEE protocol ? I don't think so. If we get into that game, we're in deep trouble. I'm fine if someone wants to write an informational draft that talks about how an RBridge should correctly implement various IEEE protocols. I, for one, don't think it is valuable in the base protocol spec, has the danger of being out of date and duplicating information. I'd like to draw a clean demarcation of Rbridge functionality from IEEE bridge functionality. We don't specify how VLANs work in this draft. They're specified in IEEE and folks follow those documents for understanding and implementing VLAN functionality. Rbridges are forward looking. They fix what is broken and is in urgent demand, by keeping it simple and not complicating the base protocol with unnecessary functionality. They don't get to be forward looking by mandating what is not required in the field, that standards bodies that define those standards don't mandate either. If we had broken statements about handling dynamic VLAN registration in the draft, let's take it out completely, not fix it. I must've missed seeing that section or you'd have heard me holler a lot sooner. Dinesh Eastlake III Donald-LDE008 wrote: > Hi Dinesh, > > There have been posts to this list stating that there are customers that > want and use standards based dynamic VLAN registration. > > It seems to me that the completely broken state of dynamic VLAN > registration that was in the TRILL base protocol draft version -06 > needed to be fixed. If you have two 802.1Q bridges, say X and Z, and put > an Rbridge conformant to the -06 spec between them or if you have three > such bridges connected in sequence, say X - Y - Z, and replace Y with > such an Rbridge, the Rbridge will generally break any dynamic VLAN > registration going on between these bridges, whether you are using GVRP > or the new MVRP. How can such network damage be consistent with our > goals of incremental deployment and VLAN support? > > It seemed to me that Rbridges should be forward looking, so I thought > they should support the newer MVRP, and Rbridges should be simple, so I > didn't even bother to think much about how you could support both GVRP > and MVRP (although you could do that as the frames seem to be easily > distinguishable). That's why I just said MVRP in my earlier posting to > the Rbridge list and in my presentation to the TRILL working group in > Philadelphia. MVRP also appears to me to be technically superior to GVRP > because you can sometimes replace thousands of GVRP frames with one MVRP > frame. > > I assume by "advertise" VLANs below you mean propagate through the link > state database. I've got no problem with there being additional methods > to configure VLANs but I think we will need to say how to configure them > with SNMP (even if that is mostly just a pointer to an existing bridge > MIB) and say how they work with 802.1 dynamic VLAN registration. > > In a later message you clarified your statement that MVRP was not > mandatory to implement by narrowing that claim to 802.1D bridges. Since > 802.1D bridges are VLAN ignorant and do not support VLANs, it is hardly > surprising that they do not mandate implementing dynamic VLAN > registration. But the TRILL WG has decided that Rbridges will support > VLANs and, in most cases, be incrementally deployable into 802.1Q > bridged LANs. As I document in a separate message, as far as I can see, > 802.1Q requires the implementation of dynamic VLAN registration. > > Donald > > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Wednesday, March 19, 2008 8:10 PM > To: Eastlake III Donald-LDE008 > Cc: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] VLAN registration > > I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have > found no customers wanting it so far. I don't see why RBridge spec needs > > to say anything more than how VLANs are advertised. How they discover > what VLANs to advertise is a specific RBridge implementation detail. > Some may use MVRP, some may use some proprietary protocol (this is not > the reason for my opposition) and some may use local configuration. MVRP > > support is not a MUST or a SHOULD and I don't want RBridge support to be > > so either. > > Dinesh > > -- 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 Sun Mar 30 22:21:51 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sun, 30 Mar 2008 22:21:51 -0700 Subject: [rbridge] "Inter-RBridge-only" port In-Reply-To: <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> References: <47EDA209.6040902@sun.com> <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> Message-ID: <47F074EF.8010901@cisco.com> Hi Donald, Eastlake III Donald-LDE008 wrote: > If port p is configured to be inter-RBridge-only on RB1, then RB1: > a) ignores all traffic that is not TRILL-encapsulated > > @@@ Actually, it still has to pay attention to control frames like PAUSE > or, if implemented, local link discovery, etc. It just ignores native > frames. > This is where I see a need for a clear demarcation between TRILL and IEEE functionality. It's useful to talk about the frames the TRILL functionality is concerned with. "Native frames" is not a clear enough term IMO. Dinesh -- 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 Sun Mar 30 22:23:07 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sun, 30 Mar 2008 22:23:07 -0700 Subject: [rbridge] "Inter-RBridge-only" port In-Reply-To: <47EFD5CB.5080508@sun.com> References: <47EDA209.6040902@sun.com> <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> <47EFD5CB.5080508@sun.com> Message-ID: <47F0753B.5070709@cisco.com> Agreed, Dinesh Radia Perlman wrote: > Eastlake III Donald-LDE008 wrote: > >> @@@ It occurs to me that if a port is configured to provide no end >> station support (ignore native frames and not decapsulate), then it >> should not contribute to the VLANs advertised by that RBridge in the >> link state database. The only reason to advertise the enablement of a >> VLAN on one or more ports at an Rbridge is to attract certain >> multi-destination encapsulated traffic to that Rbridge but such traffic >> will not be decapsulated out such a port. This needs to be mentioned in >> the base protocol document. >> >> >> > Yes. Good point. > _______________________________________________ > 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 Mar 31 06:15:10 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 31 Mar 2008 09:15:10 -0400 Subject: [rbridge] "Inter-RBridge-only" port In-Reply-To: <47F074EF.8010901@cisco.com> References: <47EDA209.6040902@sun.com> <3870C46029D1F945B1472F170D2D979003A95218@de01exm64.ds.mot.com> <47F074EF.8010901@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003A952B1@de01exm64.ds.mot.com> Hi, This is one reason that there is a (hopefully clear) definition of "native frames", "control frames", and "TRILL frames" in Section 1.2 of base protocol draft version -07. But further clarification would probably be a good idea. Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Monday, March 31, 2008 1:22 AM To: Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] "Inter-RBridge-only" port Hi Donald, Eastlake III Donald-LDE008 wrote: > If port p is configured to be inter-RBridge-only on RB1, then RB1: > a) ignores all traffic that is not TRILL-encapsulated > > @@@ Actually, it still has to pay attention to control frames like PAUSE > or, if implemented, local link discovery, etc. It just ignores native > frames. > This is where I see a need for a clear demarcation between TRILL and IEEE functionality. It's useful to talk about the frames the TRILL functionality is concerned with. "Native frames" is not a clear enough term IMO. Dinesh -- 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 Mar 31 09:15:14 2008 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Mon, 31 Mar 2008 12:15:14 -0400 Subject: [rbridge] VLAN registration In-Reply-To: <47F06900.4050906@cisco.com> References: <47E12312.7090304@sun.com><3870C46029D1F945B1472F170D2D979003A0FF30@de01exm64.ds.mot.com><47E1AB61.5050101@cisco.com><3870C46029D1F945B1472F170D2D979003A9521D@de01exm64.ds.mot.com> <47F06900.4050906@cisco.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77034D336B@nekter> Dinesh Dutt wrote: > > Donald, > > Next, are we going to specify what an Rbridge does for every single > IEEE > protocol ? I don't think so. If we get into that game, we're in deep > trouble. I'm fine if someone wants to write an informational draft that > talks about how an RBridge should correctly implement various IEEE > protocols. I, for one, don't think it is valuable in the base protocol > spec, has the danger of being out of date and duplicating information. > I'd like to draw a clean demarcation of Rbridge functionality from IEEE > bridge functionality. We don't specify how VLANs work in this draft. > They're specified in IEEE and folks follow those documents for > understanding and implementing VLAN functionality. I agree with this approach. I suspect this boils down to where we think an RBridge fits in 802's hierarchy. If you view it as an alternate to 802.1 which cobbles together 802.3 links then you end up having to specify how it supports or does not support virtually every 802.1 protocol. 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. Each RBridge connects to one or more physical LANs using 802.1 services, and participates in VLANs on each physical LAN according to whatever 802.1 rules are appropriate for that LAN. That means 802.l and the market place determines how much standards lag is tolerable, not an IETF group. BRridges then share their VLAN membership with each other. This ends up relaying information about VLAN membership, but it is not the same thing as relaying/proxying BPDUs and LLDP packets around. There may be some 802.1 protocols that are desirable to carry through RBridges. AVB and Congestion Notification are both possibilities. But the rules for extending special 802.1 clouds through RBridges should be dealt with later in separate documents. Having base specifications for both RBridges and the 802.1 cloud discovery rules will certainly help. There is a very simple and easily understood model where RBridges use 802.1 services to relay messages between RBridges, performs encapsulation on ingress data frames and decapsulation on egress data frames. Trying to figure out which 802.1 control frames should be forwarded by RBridges will greatly complicate that entire process. We should at least wait until 802.1 has finished working that out for all the various types of 802.1 bridges. From ddutt at cisco.com Mon Mar 31 09:39:58 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 31 Mar 2008 09:39:58 -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: <47F113DE.5050609@cisco.com> Caitlin, Caitlin Bestler wrote: > 802.1 has trouble keeping track of 802.1 projects. We don't want to go > there. > Exactly. > A more stable approach is to view RBridge as a *consumer* of 802.1 > services. > This was the same thing I wanted to convey with a picture, Dinesh -- 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 Mar 31 12:03:07 2008 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 31 Mar 2008 12:03:07 -0700 Subject: [rbridge] VLAN registration In-Reply-To: <47F113DE.5050609@cisco.com> 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> <47F113DE.5050609@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA203B25F65@nuova-ex1.hq.nuovaimpresa.com> I agree with Dinesh and Caitlin -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Monday, March 31, 2008 9:40 AM > To: Caitlin Bestler > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] VLAN registration > > Caitlin, > > Caitlin Bestler wrote: > > 802.1 has trouble keeping track of 802.1 projects. We don't want to go > > there. > > > Exactly. > > A more stable approach is to view RBridge as a *consumer* of 802.1 > > services. > > > This was the same thing I wanted to convey with a picture, > > Dinesh > > -- > 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