From Radia.Perlman at sun.com Sun Jun 1 17:39:39 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 01 Jun 2008 17:39:39 -0700 Subject: [rbridge] Testing the mailing list Message-ID: <4843414B.3080608@sun.com> There were 3 replies (including one of mine) to Suresh's post on 5/29 about Appointed Forwarder changes. I did not see any of the replies on the list (though they are in the archives -- a message from me, from Donald, and from Jim Carlson.) I'm testing to see if I receive this message on the list, and can other people reply to me (privately) if they received any of the replies to Suresh's post on the list? Thanks, Radia From Donald.Eastlake at motorola.com Mon Jun 2 11:11:51 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 2 Jun 2008 14:11:51 -0400 Subject: [rbridge] AF change handling Message-ID: <3870C46029D1F945B1472F170D2D979003D91D25@de01exm64.ds.mot.com> Hi, There were three messages in the "[rbridge] AF change handling" thread which at least some people did not seem to receive from the mailing list although they are in the archives. The original message, which I believe did go out on the list, and the three follow-ups which at least some people didn't get, are the last four messages on this archive web page: http://www.postel.org/pipermail/rbridge/2008-May/date.html Sorry for the additional traffic if you did get all these messages originally. 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 touch at ISI.EDU Mon Jun 2 12:55:23 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 02 Jun 2008 12:55:23 -0700 Subject: [rbridge] AF change handling In-Reply-To: <3870C46029D1F945B1472F170D2D979003D91D25@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979003D91D25@de01exm64.ds.mot.com> Message-ID: <4844502B.7030909@isi.edu> FYI, to anyone who didn't receive these mails, please send a note off-list to me. I'm tracking the list to see if there was an error. Also, it might be useful to check your subscription settings. In particular, the default for this list was "nodupes" was set to TRUE, which means that if you post to the list AND cc others, the others will NOT receive a copy from the list. I've reset the default for new subscribers to clear this bit, but any of you who have had list problems (esp. in not receiving items from the list that you did receive cc'd) should check that setting. Joe (as list admin) Eastlake III Donald-LDE008 wrote: > Hi, > > There were three messages in the "[rbridge] AF change handling" thread > which at least some people did not seem to receive from the mailing list > although they are in the archives. The original message, which I believe > did go out on the list, and the three follow-ups which at least some > people didn't get, are the last four messages on this archive web page: > http://www.postel.org/pipermail/rbridge/2008-May/date.html > > Sorry for the additional traffic if you did get all these messages > originally. > > 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 > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080602/8993c1a4/signature.bin From rshekhar at juniper.net Mon Jun 2 20:11:13 2008 From: rshekhar at juniper.net (Ravi Shekhar) Date: Mon, 2 Jun 2008 20:11:13 -0700 Subject: [rbridge] AF change handling Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> >To avoid extra messages and do this via the link state data base, you >would need some additional encoding. I don't see how just some one bit >flag per Rbridge per VLAN would do it as you can never tell that any >particular Rbridge will see each successive update from any other >Rbridge, as far as I know. It might see update N and N+k but never see >N+1 through N+k-1 and the bit might have flipped twice over that >sequence. So I think you would have to do something which was logically >equivalent to the following: include in the link state data base for >each Rbridge a hash function of the ports for which it is appointed >forwarder for VLAN-x. For example, SHA-1 of the sorted MAC addresses of >all the ports which are appointed forwarders for VLAN-x. Then, when >Rbridge-1 notices this hash change for Rbridge-2 for VLAN-x, it would >know it could forget or shorten the cache timer for all VLAN-x addresses >that it learned for data from Rbridge-2. Donald, can it simplified to have an "optional" TLV per VLAN-x that contains the "AF-gen-id" of that RBridge? Each time AFness of an RBridge changes for VLAN-x on any of its port, it can increase its AF-gen-id by 1 for that VLAN-x in its LSP. Recipients can "optionally" process the AF-gen-id TLV to shorten the cache timer as you have stated. - Ravi Shekhar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080602/62a33e30/attachment.html From Donald.Eastlake at motorola.com Mon Jun 2 20:50:16 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 2 Jun 2008 23:50:16 -0400 Subject: [rbridge] AF change handling In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> References: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> Message-ID: <3870C46029D1F945B1472F170D2D979003D91F4E@de01exm64.ds.mot.com> That would work but not be quite as good because if the AF status of a port flapped (changed and then changed back to its original state quickly), it would not generate the same value. But maybe that advantage is too small to bother with. Donald ________________________________ From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Ravi Shekhar Sent: Monday, June 02, 2008 11:11 PM To: rbridge at postel.org Subject: [rbridge] AF change handling >To avoid extra messages and do this via the link state data base, you >would need some additional encoding. I don't see how just some one bit >flag per Rbridge per VLAN would do it as you can never tell that any >particular Rbridge will see each successive update from any other >Rbridge, as far as I know. It might see update N and N+k but never see >N+1 through N+k-1 and the bit might have flipped twice over that >sequence. So I think you would have to do something which was logically >equivalent to the following: include in the link state data base for >each Rbridge a hash function of the ports for which it is appointed >forwarder for VLAN-x. For example, SHA-1 of the sorted MAC addresses of >all the ports which are appointed forwarders for VLAN-x. Then, when >Rbridge-1 notices this hash change for Rbridge-2 for VLAN-x, it would >know it could forget or shorten the cache timer for all VLAN-x addresses >that it learned for data from Rbridge-2. Donald, can it simplified to have an "optional" TLV per VLAN-x that contains the "AF-gen-id" of that RBridge? Each time AFness of an RBridge changes for VLAN-x on any of its port, it can increase its AF-gen-id by 1 for that VLAN-x in its LSP. Recipients can "optionally" process the AF-gen-id TLV to shorten the cache timer as you have stated. - Ravi Shekhar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080602/8fd6d804/attachment.html From james.d.carlson at sun.com Tue Jun 3 04:13:07 2008 From: james.d.carlson at sun.com (James Carlson) Date: Tue, 3 Jun 2008 07:13:07 -0400 Subject: [rbridge] AF change handling In-Reply-To: <3870C46029D1F945B1472F170D2D979003D91F4E@de01exm64.ds.mot.com> References: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> <3870C46029D1F945B1472F170D2D979003D91F4E@de01exm64.ds.mot.com> Message-ID: <18501.10051.104227.948065@gargle.gargle.HOWL> Eastlake III Donald-LDE008 writes: > That would work but not be quite as good because if the AF status of a > port flapped (changed and then changed back to its original state > quickly), it would not generate the same value. But maybe that advantage > is too small to bother with. In some cases, "flaps" are actually changes in attachment -- i.e., someone moving patch cables around -- and I'm not so sure I'd want to try to optimize that one away. Catching the event does sound good enough to me. -- 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 Donald.Eastlake at motorola.com Tue Jun 3 08:40:42 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 3 Jun 2008 11:40:42 -0400 Subject: [rbridge] AF change handling In-Reply-To: <18501.10051.104227.948065@gargle.gargle.HOWL> References: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net><3870C46029D1F945B1472F170D2D979003D91F4E@de01exm64.ds.mot.com> <18501.10051.104227.948065@gargle.gargle.HOWL> Message-ID: <3870C46029D1F945B1472F170D2D979003D920E5@de01exm64.ds.mot.com> That's a good point. Donald -----Original Message----- From: James Carlson [mailto:james.d.carlson at sun.com] Sent: Tuesday, June 03, 2008 7:13 AM To: Eastlake III Donald-LDE008 Cc: Ravi Shekhar; rbridge at postel.org Subject: Re: [rbridge] AF change handling Eastlake III Donald-LDE008 writes: > That would work but not be quite as good because if the AF status of a > port flapped (changed and then changed back to its original state > quickly), it would not generate the same value. But maybe that advantage > is too small to bother with. In some cases, "flaps" are actually changes in attachment -- i.e., someone moving patch cables around -- and I'm not so sure I'd want to try to optimize that one away. Catching the event does sound good enough to me. -- 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 sboddapa at yahoo.com Tue Jun 3 09:49:41 2008 From: sboddapa at yahoo.com (Suresh Boddapati) Date: Tue, 3 Jun 2008 09:49:41 -0700 (PDT) Subject: [rbridge] AF change handling In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> Message-ID: <291739.66867.qm@web81302.mail.mud.yahoo.com> > > Donald, can it simplified to have an "optional" TLV > per VLAN-x that > contains > the "AF-gen-id" of that RBridge? Each time AFness of > an RBridge changes > for VLAN-x > on any of its port, it can increase its AF-gen-id by > 1 for that VLAN-x > in its LSP. > Recipients can "optionally" process the AF-gen-id > TLV to shorten the > cache timer > as you have stated. > I like this idea. This can be optimized a bit to change the gen-ID only when the RBridge moves from AF to non-AF on any of its ports. When an RBridge changes from non-AF to AF on any of its ports, nothing needs to be done, since there are no MAC addresses to unlearn. So maybe you could call this "AF-lost-GenID" or "AF-lost-counter". Suresh From ddutt at cisco.com Tue Jun 3 10:29:43 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 03 Jun 2008 10:29:43 -0700 Subject: [rbridge] AF change handling In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> References: <7FA0C743C38E5340BFC2873488FA1E8E02051745@emailcorp3.jnpr.net> Message-ID: <48457F87.5080306@cisco.com> I like this idea, Dinesh Ravi Shekhar wrote: > >To avoid extra messages and do this via the link state data base, you > >would need some additional encoding. I don't see how just some one bit > >flag per Rbridge per VLAN would do it as you can never tell that any > >particular Rbridge will see each successive update from any other > >Rbridge, as far as I know. It might see update N and N+k but never see > >N+1 through N+k-1 and the bit might have flipped twice over that > >sequence. So I think you would have to do something which was logically > >equivalent to the following: include in the link state data base for > >each Rbridge a hash function of the ports for which it is appointed > >forwarder for VLAN-x. For example, SHA-1 of the sorted MAC addresses of > >all the ports which are appointed forwarders for VLAN-x. Then, when > >Rbridge-1 notices this hash change for Rbridge-2 for VLAN-x, it would > >know it could forget or shorten the cache timer for all VLAN-x addresses > >that it learned for data from Rbridge-2. > > > Donald, can it simplified to have an ?optional? TLV per VLAN-x that contains > the ?AF-gen-id? of that RBridge? Each time AFness of an RBridge changes for VLAN-x > on any of its port, it can increase its AF-gen-id by 1 for that VLAN-x in its LSP. > Recipients can ?optionally? process the AF-gen-id TLV to shorten the cache timer > as you have stated. > > - Ravi Shekhar. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Jun 4 09:29:55 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 4 Jun 2008 12:29:55 -0400 Subject: [rbridge] Rbridge assumptions about bridged LANs Message-ID: <3870C46029D1F945B1472F170D2D979003DCCC14@de01exm64.ds.mot.com> At the meeting in Philadelphia, it was requested that draft text which might be included in the next version of the base protocol document concerning assumptions about bridged LANs attached to Rbridges be posted to the mailing list for comment. Some possible text is pasted at the end of this message. 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 Rbridges make certain assumptions concerning the configuration of the links connected to them, which may be bridged LANs. Campuses will still be safe if these assumptions do not hold, in that there will not be loops, unless the RBridges are configured so as to disable their loop prevention features; but some end stations may not be provided with connectivity to the campus and some Rbridge ports may not be utilized. If lack of connectivity occurs due to violation of these assumptions, it can be restored by altering bridge configurations so as to conform to the assumptions. Rbridges assume that for every link with two or more Rbridges on it, there will be at least one VLAN those RBridges are configured to use that will provide bi-directional connectivity between them. If this is not the case, one or more of the Rbridges can become orphaned from the link and not be usable for native traffic or transit TRILL data on that link. Rbridges attempt to provide connectivity between all end stations in a particular VLAN but they assume this is already the case within any bridged LAN to which they are connected. If a bridge LAN is connected to a single Rbridge, connectivity can only be provided to stations in VLAN areas of that bridged LAN connect to the Rbridge and where the Rbridge is appointed forwarder for that VLAN. Should there be an island of some VLAN within the bridge LAN with no access to the Rbridge, it will be isolated. The same is true if the bridge LAN is connected to multiple Rbridges. At most one such Rbridge will be appointed forwarder for that VLAN and will provide connectivity to end stations with a path to that Rbridge. Should there be another island of stations in that VLAN within the link, it will be isolated even if it has connectivity to another Rbridge which is not the appointed forwarder for the link and VLAN. From touch at ISI.EDU Mon Jun 16 11:11:48 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 16 Jun 2008 11:11:48 -0700 Subject: [rbridge] [Fwd: New Version Notification for draft-ietf-trill-prob-03] Message-ID: <4856ACE4.2050804@isi.edu> Hi, all, Attached is info on an update to the problem statement. From Phila, there were no outstanding issues, and only Donald had pending text, which has been incorporated in this version. As far as I can tell, this seems ready for last call... Joe -------------- next part -------------- An embedded message was scrubbed... From: IETF I-D Submission Tool Subject: New Version Notification for draft-ietf-trill-prob-03 Date: Mon, 16 Jun 2008 11:07:19 -0700 (PDT) Size: 2754 Url: http://mailman.postel.org/pipermail/rbridge/attachments/20080616/751b6a99/NewVersionNotificationfordraft-ietf-trill-prob-03.eml -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080616/751b6a99/signature.bin From Internet-Drafts at ietf.org Mon Jun 16 11:15:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 16 Jun 2008 11:15:01 -0700 (PDT) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-03.txt Message-ID: <20080616181501.986333A681A@core3.amsl.com> From Internet-Drafts at ietf.org Mon Jun 16 11:15:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 16 Jun 2008 11:15:01 -0700 (PDT) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-03.txt Message-ID: <20080616181501.986333A681A@core3.amsl.com> -------------- next part -------------- _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From erik.nordmark at sun.com Wed Jun 18 10:27:37 2008 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 18 Jun 2008 10:27:37 -0700 Subject: [rbridge] Agenda items for Dublin? In-Reply-To: <4836FCC1.5070002@sun.com> References: <4836FCC1.5070002@sun.com> Message-ID: <48594589.7050102@sun.com> We don't have much if anything to put on the agenda, and some key WG contributors will not be in Dubling, thus we are considering canceling the WG meeting in Dublin. Comments? Erik and Donald Erik Nordmark wrote: > What are the items that we to discuss face-to-face in Dublin? We don't > seem to have many open issues left in the protocol spec. > > Erik and Donald > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Thu Jun 19 11:56:06 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 19 Jun 2008 11:56:06 -0700 Subject: [rbridge] Agenda items for Dublin? In-Reply-To: <48594589.7050102@sun.com> References: <4836FCC1.5070002@sun.com> <48594589.7050102@sun.com> Message-ID: <485AABC6.5090504@isi.edu> The only item I had was related to the last call for the PAS, which was just submitted based on final edits. That can be started on the list now, though ;-), and doesn't warrant much at the meeting... Joe Erik Nordmark wrote: > We don't have much if anything to put on the agenda, and some key WG > contributors will not be in Dubling, thus we are considering canceling > the WG meeting in Dublin. > > Comments? > Erik and Donald > > Erik Nordmark wrote: >> What are the items that we to discuss face-to-face in Dublin? We don't >> seem to have many open issues left in the protocol spec. >> >> Erik and Donald >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080619/855e56f7/signature.bin From Internet-Drafts at ietf.org Mon Jun 16 11:15:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 16 Jun 2008 11:15:01 -0700 (PDT) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-03.txt Message-ID: <20080616181501.986333A681A@core3.amsl.com> -------------- next part -------------- _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From fenner at fenron.com Sun Jun 22 14:34:31 2008 From: fenner at fenron.com (Bill Fenner) Date: Sun, 22 Jun 2008 17:34:31 -0400 Subject: [rbridge] Review of draft-ietf-trill-rbridge-arch-05 Message-ID: <940D5D05-2EB4-4EE8-85DF-4276FDA67F5B@fenron.com> In Philadelphia, I volunteered to review draft-ietf-trill-rbridge- arch-05. I apologize that this review is so delayed. Similar to James, I found that the extensive equivocation about what an rbridge might or might not do made it difficult to figure out what it actually would do. Given the lackluster WG response to his review, though, I am not encouraged that there is energy to fix this. In fact, Eric's response implied that the WG more or less has consensus that the document needs to be vague and wishy-washy. I have some specific comments for some minor improvements. - In the middle of page 5, in addition to 4) Establish L2 delivery using shortest path, is there a desire to enable ECMP forwarding at L2? - In 2.2, taken together, the definitions are confusing. For example, an Egress RBridge removes the TRILL encapsulation and forwards the unencapsulated frame to the destination, causing it to leave the TRILL campus. However, the TRILL campus is defined as the set of RBridges and TRILL links, and the link connecting an RBridge and an end station is a TRILL link, so the packet actually isn't leaving the TRILL campus? An extreme example is a hub connecting two RBridges and an end station -- since the spec is careful not to say that any link is point-to-point unless explicitly configured -- is that inside the campus or outside? Seems like the TRILL-encapsulated frames are inside and the other packets are outside. - As used in 3.2.1, the term "Adjacent RBridge peers" is confusing, since in my first reading I took it to mean "Adjacent to the system maintaining the forwarding database", making its statements ridiculous. Of course, it means "The set of all 'Adjacent RBridges' in the TRILL Campus", but that meaning is not very clear at first read. - In 3.2.2, the definition of Local RBridge is confusing to me. Isn't it possible to also have a transit RBridge, which is neither the root nor an egress, yet still needs to maintain a multi-destination FDB entry? - The next to last paragraph of section 5.2 left me wondering "or what?" - either there needs to be another clause or the word "either" needs to be removed: ... it will forward the frame on all interfaces for which it is either the designated RBridge. - The pessimization of broadcast, multicast and flooded frames should probably be called out more explicitly. Specifically, without configuration, 5.3.2-1 requires that when forwarding a broadcast [so presumably also a multicast or flooded frame] using the trill encapsulation, it be also forwarded on the same interface without encapsulation, in the case that there's an end station on that link that we don't know about. Specific configuration is required to avoid this behavior. This seems like a fairly significant aspect of the protocol that's left implicit - e.g., traffic to unknown destinations is double-forwarded on all links. For example, this [only] doubles the effect of a denial-of-service attack sending frames to unknown destinations. - Another behavior that is somewhat implicit is the addition of an extra hop in some situations when delivering to a destination on a shared medium - of course, true shared mediums are pretty rare these days, and this doesn't apply in the all-RBridge case, but when a frame arrives at a shared medium on the non-egress RBridge it gets forwarded across that medium to the egress RBridge and then decapsulated. - I found the intro to the problem in 5.5.1 more confusing than helpful. It assumes the operation of a DR protocol that hasn't been described (in stating that either RB-a or RB-b will be the DR so only one link between the closet and the core will be used). Here's my summary of RBridge operation, after reading through the architecture document. Whether or not it's accurate might have some relevance to the question of whether the architecture document describes RBridge operation well. - There's a routing instance running, carrying egress RBridge addresses. - Packets are encapsulated inside a TRILL encapsulation inside the TRILL campus, which is all the TRILL routers and the encapsulated frames between them. The encapsulation probably contains an egress RBridge for the encapsulated frame's source (which, in many cases, is the ingress RBridge). It also probably contains a TTL, or maybe a full source route. - Packets are [by default] flooded inside the TRILL campus in order to learn the mapping of destination to egress RBridge, although a variation could flood this mapping in the routing protocol. - Flooding/multicast/broadcast are, by default, pessimized by forwarding the frame both encapsulated and unencapsulated. Explicit configuration of links as point-to-point links between RBridges can avoid this traffic duplication. - Unknown destination flooding can be optimized if an intermediate RBridge knows the destination. - Multicast flooding can be optimized if the location of multicast group members is advertised in the routing protocol. - The protocol might or might not do some kind of ARP/ND optimization by advertising these mappings in the routing protocol and then intercepting and/or snooping these protocols. Bill From eric.gray at ericsson.com Mon Jun 23 08:44:01 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Mon, 23 Jun 2008 10:44:01 -0500 Subject: [rbridge] Review of draft-ietf-trill-rbridge-arch-05 In-Reply-To: <940D5D05-2EB4-4EE8-85DF-4276FDA67F5B@fenron.com> References: <940D5D05-2EB4-4EE8-85DF-4276FDA67F5B@fenron.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF03497058@eusrcmw721.eamcs.ericsson.se> Bill, Thanks for your review, some responses below. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Bill Fenner > Sent: Sunday, June 22, 2008 5:35 PM > To: rbridge at postel.org > Subject: [rbridge] Review of draft-ietf-trill-rbridge-arch-05 > > In Philadelphia, I volunteered to review draft-ietf-trill-rbridge- > arch-05. I apologize that this review is so delayed. > > Similar to James, I found that the extensive equivocation about what > an rbridge might or might not do made it difficult to figure out what > it actually would do. Given the lackluster WG response to his review, > though, I am not encouraged that there is energy to fix this. In > fact, Eric's response implied that the WG more or less has consensus > that the document needs to be vague and wishy-washy. I am willing to work with you and James to figure out what can be removed to make this document less wishy-washy. If we have specific proposals that are acceptable to the WG, I am sure there is enough energy to get the changes done. > > I have some specific comments for some minor improvements. > > - In the middle of page 5, in addition to 4) Establish L2 delivery > using shortest path, is there a desire to enable ECMP forwarding at L2? Yes. Is there a reason to bring this up at this point in the draft? If so, it can be added. There are some reason to be cautious about an ECMP-like forwarding at L2. For example, while symmetric forwarding is not strictly a requirement when tunneling end-station frames across TRILL links (as long as they start and end at the same places), L2 applications assume "shared-fate" with respect to their use of physical links - and L2 link state determinations are based on this assumption - so having frames traversing non-symmetric paths in opposite directions increases the probability of a link failure being detected between end stations. There are other issues, as well, almost certainly including ones we do not know of at this time. The thing is, we have precedence that leads me to believe that it is not impossible to add ECMP at a later point. > > - In 2.2, taken together, the definitions are confusing. For > example, > an Egress RBridge removes the TRILL encapsulation and forwards the > unencapsulated frame to the destination, causing it to leave > the TRILL > campus. However, the TRILL campus is defined as the set of RBridges > and TRILL links, and the link connecting an RBridge and an > end station > is a TRILL link, so the packet actually isn't leaving the TRILL > campus? An extreme example is a hub connecting two RBridges and an > end station -- since the spec is careful not to say that any link is > point-to-point unless explicitly configured -- is that inside the > campus or outside? Seems like the TRILL-encapsulated frames are > inside and the other packets are outside. Terminology was a very sore issue, requiring a lot of effort to get agreement on. The issue that you point out seems to arise out of the definitions of Ingress and Egress RBridge - which assume the TRILL Campus consists ONLY of the TRILL links between RBridges (where those links might be defined as exclusively having TRILL encapsulation). I will try to get consensus to change these definitions to read as follows: o Egress RBridge: for any specific frame, the RBridge at which the TRILL header is removed from the frame prior to delivery to an end station (possibly via a LAN). o Ingress RBridge: for any specific frame, the RBridge at which a TRILL header is added to the frame prior to being forwarded to one or more other RBridges. One could argue that - in the degenerate case where there is, for example, only one RBridge - it is possible that an implementation will encapsulate a frame at an ingress port, send it across the backplane and decapsulate it at an egress port. In this case, the second definition breaks down (for that implementation) because the encapsulated frame is never forwarded to another RBridge. But - at some point - a definition starts to have a little too much baggage to be useful, and I would counter that such an RBridge is not visibly an ingress RBridge from an external perspective... > > - As used in 3.2.1, the term "Adjacent RBridge peers" is confusing, > since in my first reading I took it to mean "Adjacent to the system > maintaining the forwarding database", making its statements > ridiculous. Of course, it means "The set of all 'Adjacent RBridges' > in the TRILL Campus", but that meaning is not very clear at > first read. Agreed. I propose removing the word "Adjacent" in this case. > > - In 3.2.2, the definition of Local RBridge is confusing to > me. Isn't > it possible to also have a transit RBridge, which is neither > the root > nor an egress, yet still needs to maintain a multi-destination FDB > entry? Agreed. I propose changing the definition to include transit RBridges. > > - The next to last paragraph of section 5.2 left me wondering "or > what?" - either there needs to be another clause or the word > "either" > needs to be removed: > ... it will forward the frame on all > interfaces for which it is either the designated RBridge. Agreed. I propose removing the entire paragraph, which now reads: "In the DRB example, if the destination MAC address of a received frame does not correspond to a learned MAC destination address at an egress interface, it will forward the frame on all interfaces for which it is either the designated RBridge. If a received frame does correspond to a learned MAC destination address at an egress interface, the RBridge will forward the frame via that interface only." Owing to other changes, this paragraph is now out of place. > > - The pessimization of broadcast, multicast and flooded > frames should > probably be called out more explicitly. Specifically, without > configuration, 5.3.2-1 requires that when forwarding a broadcast [so > presumably also a multicast or flooded frame] using the trill > encapsulation, it be also forwarded on the same interface without > encapsulation, in the case that there's an end station on that link > that we don't know about. Specific configuration is required > to avoid > this behavior. This seems like a fairly significant aspect of the > protocol that's left implicit - e.g., traffic to unknown > destinations > is double-forwarded on all links. For example, this [only] doubles > the effect of a denial-of-service attack sending frames to unknown > destinations. Agreed. This was a complication made very difficult to explicitly state as a result of not being allowed to assume that a DRB election process would be required. I already have a number of "Note" statements and this should be explicitly added, along with a potential structure modification to make these notes both clearer and more obvious. As a general observation, this kind of forwarding requirement has had these same effects on L2 deployments for some time - particularly since the advent of VLANs. > > - Another behavior that is somewhat implicit is the addition of an > extra hop in some situations when delivering to a destination on a > shared medium - of course, true shared mediums are pretty rare these > days, and this doesn't apply in the all-RBridge case, but > when a frame > arrives at a shared medium on the non-egress RBridge it gets > forwarded > across that medium to the egress RBridge and then decapsulated. Just to be clear, implementations would presumably include the "extra" hop in their shortest path calculations and the case you describe only occurs when the path (that traverses first the TRILL link between a penultimate RBridge and the egress RBridge, and then the hop back to the end-station is still the shortest path. Interestingly enough, this is (yet another) one of the areas in which we would have to be careful about using an L2 ECMP-like forwarding. If the path that includes the "hop back" has an equal cost with the one that does not, it is tempting to use the one that does not. However, this can very easily break normal bridging in the shared media LAN between these two RBridges. Otherwise, I agree with your comment. I propose adding another note as with the above comment. > > > - I found the intro to the problem in 5.5.1 more confusing than > helpful. It assumes the operation of a DR protocol that hasn't been > described (in stating that either RB-a or RB-b will be the DR > so only > one link between the closet and the core will be used). Agreed. I propose rewriting the second sentence in the paragraph that immediately follows the diagram as follows. "Moreover, the process defined in protocol specification to avoid breaking bridge learning, may result in only using one of the links (B-1<=>RB-a, B-2<=>RB-b). This is contrary to the usage intended in a similar network using IEEE 802.1Q bridges." There are two separate issues: one is that - unless RBridges participate in (M)STP - (M)STP will not block the link between B-1 and B-2; the other is that - without blocking this link - RBridges RB-a and RB-b will detect a connection and this will require use of some mechanism or approach to resolve which is the one providing ingress/egress for this common link. The first issue is the more relevant one - hence that is the one the is addressed mostly in the remaining text. However, the second issue needed to be mentioned as well. It is the second issue that will impact on the time it would take for the example network to recover from a loss of the link between B-1 and B-2, since the two RBridges will now need to detect the loss, start operating independently (including re-learning end-station attachments and re-computing shortest paths) - and then the bridges can start learning again. > > > Here's my summary of RBridge operation, after reading through the > architecture document. Whether or not it's accurate might have some > relevance to the question of whether the architecture document > describes RBridge operation well. > > - There's a routing instance running, carrying egress RBridge > addresses. > > - Packets are encapsulated inside a TRILL encapsulation inside the > TRILL campus, which is all the TRILL routers and the encapsulated > frames between them. The encapsulation probably contains an egress > RBridge for the encapsulated frame's source (which, in many > cases, is > the ingress RBridge). It also probably contains a TTL, or maybe a > full source route. > > - Packets are [by default] flooded inside the TRILL campus in > order to > learn the mapping of destination to egress RBridge, although a > variation could flood this mapping in the routing protocol. > > - Flooding/multicast/broadcast are, by default, pessimized by > forwarding the frame both encapsulated and unencapsulated. Explicit > configuration of links as point-to-point links between RBridges can > avoid this traffic duplication. > > - Unknown destination flooding can be optimized if an intermediate > RBridge knows the destination. > > - Multicast flooding can be optimized if the location of multicast > group members is advertised in the routing protocol. > > - The protocol might or might not do some kind of ARP/ND > optimization > by advertising these mappings in the routing protocol and then > intercepting and/or snooping these protocols. > > Bill > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Mon Jun 23 09:33:03 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Mon, 23 Jun 2008 11:33:03 -0500 Subject: [rbridge] Terminology Change? Message-ID: <941D5DCD8C42014FAF70FB7424686DCF03497125@eusrcmw721.eamcs.ericsson.se> Silvano/Radia/Donald/Erik/Dinesh, Based on an inconsistency pointed out during a review, I need to make some of the terminology definitions more consistent. I propose changing the following two definitions - o Egress RBridge: for any specific frame, the RBridge through which that frame leaves the TRILL Campus. For frames transiting a TRILL Campus, the egress RBridge is an edge RBridge where RBridge encapsulation is removed from the transit frames prior to exiting the TRILL Campus. o Ingress RBridge: for any specific frame, the RBridge through which that frame enters the TRILL Campus. For frames transiting a TRILL Campus, the ingress RBridge is the edge RBridge where RBridge encapsulation is added to the transit traffic entering the TRILL Campus. - to read as follows: o Egress RBridge: for any specific frame, the RBridge at which the TRILL header is removed from the frame prior to delivery to an end station (possibly via a LAN). o Ingress RBridge: for any specific frame, the RBridge at which a TRILL header is added to the frame prior to being forwarded to one or more other RBridges. Is this change okay with you? -- Eric Gray Principal Engineer Ericsson From touch at ISI.EDU Mon Jun 23 20:23:50 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 23 Jun 2008 20:23:50 -0700 Subject: [rbridge] Terminology Change? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF03497125@eusrcmw721.eamcs.ericsson.se> References: <941D5DCD8C42014FAF70FB7424686DCF03497125@eusrcmw721.eamcs.ericsson.se> Message-ID: <486068C6.9040404@isi.edu> Eric Gray wrote: > Silvano/Radia/Donald/Erik/Dinesh, > > Based on an inconsistency pointed out during a review, I need to make > some of the terminology definitions more consistent. > > I propose changing the following two definitions - > > o Egress RBridge: for any specific frame, the RBridge through > which that frame leaves the TRILL Campus. For frames > transiting a TRILL Campus, the egress RBridge is an edge > RBridge where RBridge encapsulation is removed from the > transit frames prior to exiting the TRILL Campus. > o Ingress RBridge: for any specific frame, the RBridge through > which that frame enters the TRILL Campus. For frames > transiting a TRILL Campus, the ingress RBridge is the edge > RBridge where RBridge encapsulation is added to the transit > traffic entering the TRILL Campus. > > - to read as follows: > > o Egress RBridge: for any specific frame, the RBridge at which > the TRILL header is removed from the frame prior to delivery > to an end station (possibly via a LAN). This seems confusing, in that the LAN includes the campus and all stub segments. Did you mean "possibly via a stub segment"? Alternately, I'd keep the notion that once you leave a campus you leave forever, i.e., you can't leave a campus and enter it again. > o Ingress RBridge: for any specific frame, the RBridge at which > a TRILL header is added to the frame prior to being forwarded > to one or more other RBridges. Overall, I prefer the form that describes entering/leaving the campus in addition to adding/removing TRILL headers. The former is architectural, the second procedural, and defining them together couples the two in useful ways. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20080623/0bad6af7/signature.bin From sboddapa at yahoo.com Mon Jun 23 22:09:43 2008 From: sboddapa at yahoo.com (Suresh Boddapati) Date: Mon, 23 Jun 2008 22:09:43 -0700 (PDT) Subject: [rbridge] Distribution Tree and ECMP Message-ID: <67219.9993.qm@web81307.mail.mud.yahoo.com> 4.3.1 of the base protocol spec says: "When a node RBn has two or more minimal equal cost paths toward the Root RBi a deterministic tie-breaker is needed to guarantee that all Rbridges calculate the same distribution tree. This is obtained by selecting the path that goes to the parent that has the lower IS-IS System ID." This however does not cover the case when the ECMP paths are through the same RBridge. For example, A ----- B ---------- C ---------- If B is the designated IS for both the links connected to C for the tree rooted at A, it is possible that C might compute the top link to be on the distribution tree whereas B might compute the bottom one. It seems to me that the algorithm will be more deterministic if the LAN ID were to be used for tie-breaking, when System IDs are the same. In this case if the top link's LAN ID were to be B.01 and the bottom link's were to be B.02, both could deterministically decide that B.01 should be the link on the distribution tree. Comments? Suresh From ddutt at cisco.com Mon Jun 23 23:36:00 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 23 Jun 2008 23:36:00 -0700 Subject: [rbridge] Terminology Change? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF03497125@eusrcmw721.eamcs.ericsson.se> References: <941D5DCD8C42014FAF70FB7424686DCF03497125@eusrcmw721.eamcs.ericsson.se> Message-ID: <486095D0.7030706@cisco.com> Yes, Dinesh Eric Gray wrote: > Silvano/Radia/Donald/Erik/Dinesh, > > Based on an inconsistency pointed out during a review, I need to make > some of the terminology definitions more consistent. > > I propose changing the following two definitions - > > o Egress RBridge: for any specific frame, the RBridge through > which that frame leaves the TRILL Campus. For frames > transiting a TRILL Campus, the egress RBridge is an edge > RBridge where RBridge encapsulation is removed from the > transit frames prior to exiting the TRILL Campus. > > o Ingress RBridge: for any specific frame, the RBridge through > which that frame enters the TRILL Campus. For frames > transiting a TRILL Campus, the ingress RBridge is the edge > RBridge where RBridge encapsulation is added to the transit > traffic entering the TRILL Campus. > > - to read as follows: > > o Egress RBridge: for any specific frame, the RBridge at which > the TRILL header is removed from the frame prior to delivery > to an end station (possibly via a LAN). > > o Ingress RBridge: for any specific frame, the RBridge at which > a TRILL header is added to the frame prior to being forwarded > to one or more other RBridges. > > Is this change okay with you? > > -- > Eric Gray > Principal Engineer > Ericsson > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From eric.gray at ericsson.com Tue Jun 24 05:05:41 2008 From: eric.gray at ericsson.com (Eric Gray) Date: Tue, 24 Jun 2008 07:05:41 -0500 Subject: [rbridge] Agenda items for Dublin? In-Reply-To: <48594589.7050102@sun.com> References: <4836FCC1.5070002@sun.com> <48594589.7050102@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF03497A26@eusrcmw721.eamcs.ericsson.se> Erik, We have had relative quiet on the mailing list, but I'm unsure that means there are not some issues with the protocol specification that need focus. However, if key contributors will not be there, it is questionable what value there is to be derived from trying to do this at the IETF meeting in Dublin. Just for clarity, what are the presumed resolutions for these issues: AF Change Handling (the list went quiet after several slightly different proposals were made)? Have there been any off-list comments on Donald's post with the subject "Rbridge assumptions about bridged LANs"? Rbridge setting of BPDU Topology Change Flag (this looks to have been resolved based on a comment from Donald and a response from Radia)? David Melman's questions (requiring changes to the protocol draft - based on Donald's reponses): Modifications to text to make the text Normative (while also presumably aligning the pseudo-code and text)? What does a transit RBridge does with a known unicast TRILL data frame if the egress RBridge nickname is unknown? Proposed details for announcing endnodes (this dicussion petered out in a tangential discussion about WG goals and objectives - as a result, it's not obvious what, if any, resolution was achieved)? Radia's question - How many "priorities" are there (there was a small consensus - two reponders - that all of the priorities she mentioned should be separately configurable, but what changes did this require)? Donald's question - What to do about VLAN mapping (asked but not answered by anyone)? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark > Sent: Wednesday, June 18, 2008 1:28 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Agenda items for Dublin? > > > We don't have much if anything to put on the agenda, and some key WG > contributors will not be in Dubling, thus we are considering > canceling > the WG meeting in Dublin. > > Comments? > Erik and Donald > > Erik Nordmark wrote: > > What are the items that we to discuss face-to-face in > Dublin? We don't > > seem to have many open issues left in the protocol spec. > > > > Erik and Donald > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From ayabaner at cisco.com Tue Jun 24 09:44:04 2008 From: ayabaner at cisco.com (Ayan Banerjee (ayabaner)) Date: Tue, 24 Jun 2008 09:44:04 -0700 Subject: [rbridge] Distribution Tree and ECMP In-Reply-To: <67219.9993.qm@web81307.mail.mud.yahoo.com> References: <67219.9993.qm@web81307.mail.mud.yahoo.com> Message-ID: <4C76BEA6DA349A4EBE240D97BBE4546403F6ACC4@xmb-sjc-22b.amer.cisco.com> Suresh, I agree with your observation and in the event these links are P2P we should use the extended circuit-id to break the tie. Thanks, Ayan -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Suresh Boddapati Sent: Monday, June 23, 2008 10:10 PM To: rbridge at postel.org Subject: [rbridge] Distribution Tree and ECMP 4.3.1 of the base protocol spec says: "When a node RBn has two or more minimal equal cost paths toward the Root RBi a deterministic tie-breaker is needed to guarantee that all Rbridges calculate the same distribution tree. This is obtained by selecting the path that goes to the parent that has the lower IS-IS System ID." This however does not cover the case when the ECMP paths are through the same RBridge. For example, A ----- B ---------- C ---------- If B is the designated IS for both the links connected to C for the tree rooted at A, it is possible that C might compute the top link to be on the distribution tree whereas B might compute the bottom one. It seems to me that the algorithm will be more deterministic if the LAN ID were to be used for tie-breaking, when System IDs are the same. In this case if the top link's LAN ID were to be B.01 and the bottom link's were to be B.02, both could deterministically decide that B.01 should be the link on the distribution tree. Comments? Suresh _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Wed Jun 25 10:57:01 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 25 Jun 2008 13:57:01 -0400 Subject: [rbridge] Agenda items for Dublin? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF03497A26@eusrcmw721.eamcs.ericsson.se> References: <4836FCC1.5070002@sun.com> <48594589.7050102@sun.com> <941D5DCD8C42014FAF70FB7424686DCF03497A26@eusrcmw721.eamcs.ericsson.se> Message-ID: <3870C46029D1F945B1472F170D2D979003EBFD72@de01exm64.ds.mot.com> Hi Eric, See below at @@@ -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray Sent: Tuesday, June 24, 2008 8:06 AM To: Erik Nordmark; Developing a hybrid router/bridge. Subject: Re: [rbridge] Agenda items for Dublin? Erik, We have had relative quiet on the mailing list, but I'm unsure that means there are not some issues with the protocol specification that need focus. However, if key contributors will not be there, it is questionable what value there is to be derived from trying to do this at the IETF meeting in Dublin. @@@ Yes, at this point Erik and I are planning to cancel the Dublin TRILL WG meeting. Just for clarity, what are the presumed resolutions for these issues: AF Change Handling (the list went quiet after several slightly different proposals were made)? @@@ It seems to me that the proposal to have a per Rbridge per VLAN "appointed forwarder status lost" counter met with the most approval so that will be in the next protocol draft for people to comment on. When Rbridge RB1 observes this counter change in the link state for RB2 for VLAN-x then RB1 would shorten the time-out for any VLAN-x MAC addresses it had learned from decapsulating frames from RB2. Have there been any off-list comments on Donald's post with the subject "Rbridge assumptions about bridged LANs"? @@@ If there were, they didn't get to me :-) So currently the plan is for something very similar to that text to be in the next protocol draft. Rbridge setting of BPDU Topology Change Flag (this looks to have been resolved based on a comment from Donald and a response from Radia)? @@@ It seems to have been resolved to put this in but I think my comment may have been slightly confused or at least not specific enough. I think it is more like the topology change flag in a spanning tree BPDU is for the root to flood the fact that there has been topology change through the bridged LAN. What an Rbridge should do when it looses appointer forwarder status for a VLAN on a port is send topology change BPDUs out that port until it gets an acknowledging spanning tree BPDU with the topology change flag set... David Melman's questions (requiring changes to the protocol draft - based on Donald's responses): Modifications to text to make the text Normative (while also presumably aligning the pseudo-code and text)? @@@ Yes, a working group consensus has been declared that the text is normative and in case of conflict the text dominates the pseudo code. What does a transit RBridge does with a known unicast TRILL data frame if the egress RBridge nickname is unknown? @@@ I guess there hasn't been any discussion on this but the suggestion I posted was that it discard the frame. This seems like the simplest thing. Converting to unknown unicast frame seems too likely to cause broadcast storms. I suppose that, in principle, a "MAY" behavior for the transit Rbridge could be to see if it knows the Inner.MacDA unicast address and if so change the TRILL header. But: (1) Transit Rbridges and unlikely to know that many end station MAC addresses. Shielding transit Rbridges from having to learn or use lots of end station MAC addresses is part of the point of TRILL. (2) Lots of places where the draft prohibits any monkeying with TRILL header fields after encapsulation would have to change. Proposed details for announcing endnodes (this discussion petered out in a tangential discussion about WG goals and objectives - as a result, it's not obvious what, if any, resolution was achieved)? @@@ A major complaint had been that there would be too many Hellos but it appears to be simple to eliminate Hellos on the end station address distribution instances of TRILL IS-IS by the inclusion of enough information in the core instance link state to determine the DRB for any end station address distribution instance virtual link. The only thing that would be special about such a virtual link DRB would be that it would issue CSNPs. Radia's question - How many "priorities" are there (there was a small consensus - two responders - that all of the priorities she mentioned should be separately configurable, but what changes did this require)? @@@ Radia listed four possible priorities and indeed, both comments said they should all be separate. Two of them are already provided for: the priority for becoming DRB for the core instance of IS-IS is already provided by IS-IS and the priority for getting a nickname is already spelled out in detail in the current protocol draft. A third was the priority for becoming a distribution tree root. The whole mechanism for having this priority (with System ID for tie breaker) to select the highest priority Rbridge which can then specify how many trees are to be calculated, etc., is being added. So adding this priority can be easily done at the same time. The last additional priority was for being DRB on an end station address distribution instance virtual link. And, if there is a separate priority for this, should it be per Rbridge or per Rbridge per VLAN. To me, this seems like the least important of all the priorities. I don't see any harm in having a separate priority for this per Rbridge but it doesn't seem worth it to have one per Rbridge per VLAN. I don't think people will be setting up vast numbers of such instances... Donald's question - What to do about VLAN mapping (asked but not answered by anyone)? @@@ Yes, it was hard to tell which way the WG was leaning on this. The simplest and most drastic thing to do is, if Rbridge RBi gets a Hello showing mapping from VLAN-x to VLAN-y, then Rbi disables the port on which the Hellos was received for both VLANs. This would at least lead to hard failures and hopefully get the network administrator's attention. Other possibilities would be disabling only one of these and/or reporting the matter to the DRB... -- Eric Gray Principal Engineer Ericsson @@@ Thanks for gathering these questions together and posting them. @@@ Comments welcome but it might be a good idea, for detailed comments, to cut and paste so as to separate the various issues into different emails. @@@ Donald > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark > Sent: Wednesday, June 18, 2008 1:28 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Agenda items for Dublin? > > We don't have much if anything to put on the agenda, and some key WG > contributors will not be in Dublin, thus we are considering > canceling > the WG meeting in Dublin. > > Comments? > Erik and Donald > > Erik Nordmark wrote: > > What are the items that we to discuss face-to-face in > Dublin? We don't > > seem to have many open issues left in the protocol spec. > > > > Erik and Donald _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Wed Jun 25 14:11:41 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 25 Jun 2008 17:11:41 -0400 Subject: [rbridge] Distribution Tree and ECMP In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546403F6ACC4@xmb-sjc-22b.amer.cisco.com> References: <67219.9993.qm@web81307.mail.mud.yahoo.com> <4C76BEA6DA349A4EBE240D97BBE4546403F6ACC4@xmb-sjc-22b.amer.cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D979003EBFEA4@de01exm64.ds.mot.com> Some of these cases may not occur due to link aggregation but when these cases do occur, it certainly seems like you need a further tie breaker and your suggestion sounds good to me. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Ayan Banerjee (ayabaner) Sent: Tuesday, June 24, 2008 12:44 PM To: Suresh Boddapati; rbridge at postel.org Subject: Re: [rbridge] Distribution Tree and ECMP Suresh, I agree with your observation and in the event these links are P2P we should use the extended circuit-id to break the tie. Thanks, Ayan -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Suresh Boddapati Sent: Monday, June 23, 2008 10:10 PM To: rbridge at postel.org Subject: [rbridge] Distribution Tree and ECMP 4.3.1 of the base protocol spec says: "When a node RBn has two or more minimal equal cost paths toward the Root RBi a deterministic tie-breaker is needed to guarantee that all Rbridges calculate the same distribution tree. This is obtained by selecting the path that goes to the parent that has the lower IS-IS System ID." This however does not cover the case when the ECMP paths are through the same RBridge. For example, A ----- B ---------- C ---------- If B is the designated IS for both the links connected to C for the tree rooted at A, it is possible that C might compute the top link to be on the distribution tree whereas B might compute the bottom one. It seems to me that the algorithm will be more deterministic if the LAN ID were to be used for tie-breaking, when System IDs are the same. In this case if the top link's LAN ID were to be B.01 and the bottom link's were to be B.02, both could deterministically decide that B.01 should be the link on the distribution tree. Comments? Suresh _______________________________________________ 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 leea at grnoc.iu.edu Thu Jun 26 08:11:41 2008 From: leea at grnoc.iu.edu (Andrew Lee) Date: Thu, 26 Jun 2008 11:11:41 -0400 Subject: [rbridge] draft-ietf-trill-rbridge-arch-05.txt review Message-ID: <4863B1AD.3090705@grnoc.iu.edu> If I am not mistaken, I am the mysterious 5th and last person from Philadelphia to promise to review the architecture document (it looks like my last name got misspelled in the minutes), so here is my review. I am relatively new to the group and do not have all the background and history this document may have already been through. To a degree I have purposefully ignored discussions on the list as far as this review is concerned to give a "fresh" perspective, so I apologize if I am rehashing old, settled arguments. One of the things I noticed is an implied requirement at certain points in the document that an RBridge not be anything but an RBridge. I could be reading too much into the document, but I think there would be benefit to add a statement that points out that it is not a requirement of the architecture that an RBridge device cannot also participate in other Layer 2 architectures such as an STP domain (sorry for the double negative), similar to the disclaimer given for ISIS in the middle of page 6. In Section 2.2, Using terms (especially TRILL Campus) before defining them can be confusing. While there is elegance in alphabetizing this section, consideration should be given to the order in which the terms appear. There are too many terms that refer to an RBridge Distribution Tree: distribution tree, RDT, or R-Tree. Please pick one. Sections 4.1 and 4.4 seem redundant to me. There is little added in section 4.4, maybe that could be merged into 4.1 and 4.4 deleted or strike the second paragraph in 4.1? In 4.6, 2nd paragraph, "desitnation" should be "destination" (which I am sure has been pointed out already). 5.2 has the following sentence: In the DRB example, if the destination MAC address of a received frame does not correspond to a learned MAC destination address at an egress interface, it will forward the frame on all interfaces for which it is either the designated RBridge. It seems like there is an "or ..." missing. It may be easiest to just delete the word "either" so that it reads In the DRB example, if the destination MAC address of a received frame does not correspond to a learned MAC destination address at an egress interface, it will forward the frame on all interfaces for which it is the designated RBridge. This seems like it would be consistent with the egress behavior described several paragraphs earlier, though maybe a further modification would be "for which it is the designated egress RBridge" so that the previous exception of distinct ingress/egress DRBs is covered. In section 5.3.2-1, I am a little concerned about language regarding treatment of broadcast frames and point to point links. The document seems to imply that if you have a point to point link between two RBridges, and no learning has occurred on that link, it is not necessary to forward a broadcast packet across that link to the other RBridge. Perhaps I am misreading it, but if the RBridge on the other side of that link has egress interfaces, it should receive all broadcast packets regardless of the state of learning on the point to point link. It is also possible that I am misunderstanding the use of 'point to point' in this context. Section 5.5 has the statement This architecture assumes RBridges block STP. This may seem like a dumb question, but why is this? Why wouldn't STP packets be encapsulated and flooded through the RBridge Campus to each egress interface like it would be "if RBridges were replaced by other types of L2 forwarding devices" as stated at the top of 5.5? This seems like it would solve the wiring closet problem quite neatly (which makes me think I am overlooking something painfully obvious to everyone else). As mentioned in 5.1.1, either RB-a or RB-b would be the DRB for the MAC address originating the STP frame, but wouldn't the other be considered an egress interface, and thus a valid destination for the (multicast) frame? I will leave it at this for now. I plan on re-reading the draft, and sending out any further comments that I may come up with, if any. Thanks for reading this. ~Andrew Andrew Lee Network Engineer Indiana University Global Research NOC leea at grnoc.iu.edu | http://www.globalnoc.iu.edu From Radia.Perlman at sun.com Thu Jun 26 16:14:42 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 26 Jun 2008 16:14:42 -0700 Subject: [rbridge] Distribution Tree and ECMP In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546403F6ACC4@xmb-sjc-22b.amer.cisco.com> References: <67219.9993.qm@web81307.mail.mud.yahoo.com> <4C76BEA6DA349A4EBE240D97BBE4546403F6ACC4@xmb-sjc-22b.amer.cisco.com> Message-ID: <486422E2.1020904@sun.com> Yup. I might have been the culprit who did that wording. At any rate, yeah -- it should be the "ID of the parent node", so as you said, it should be the IS-IS 7-byte ID of the node, whether the "parent" is a pseudonode or a regular node. "System ID" implies the 6 byte ID of a router, and that is incorrect in this case, as you point out. Thanks for catching that. Radia Ayan Banerjee (ayabaner) wrote: > Suresh, > > I agree with your observation and in the event these links are P2P we > should use the extended circuit-id to break the tie. > > Thanks, > Ayan > > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Suresh Boddapati > Sent: Monday, June 23, 2008 10:10 PM > To: rbridge at postel.org > Subject: [rbridge] Distribution Tree and ECMP > > 4.3.1 of the base protocol spec says: > > "When a node RBn has two or more minimal equal cost paths toward the > Root RBi a deterministic tie-breaker is needed to guarantee that all > Rbridges calculate the same distribution tree. This is obtained by > selecting the path that goes to the parent that has the lower IS-IS > System ID." > > This however does not cover the case when the ECMP paths are through the > same RBridge. For example, > > > A ----- B ---------- C > ---------- > > If B is the designated IS for both the links connected to C for the tree > rooted at A, it is possible that C might compute the top link to be on > the distribution tree whereas B might compute the bottom one. > > It seems to me that the algorithm will be more deterministic if the LAN > ID were to be used for tie-breaking, when System IDs are the same. In > this case if the top link's LAN ID were to be B.01 and the bottom link's > were to be B.02, both could deterministically decide that B.01 should be > the link on the distribution tree. > > Comments? > > Suresh > > > > > > _______________________________________________ > 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 Fri Jun 27 09:00:16 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 27 Jun 2008 12:00:16 -0400 Subject: [rbridge] Change of Address Message-ID: <3870C46029D1F945B1472F170D2D979003EC057A@de01exm64.ds.mot.com> Please note my change of email address to d3e3e3 at gmail.com Thanks, Donald =================================================== Donald E. Eastlake, 3rd 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Internet-Drafts at ietf.org Fri Jun 27 13:15:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri, 27 Jun 2008 13:15:01 -0700 (PDT) Subject: [rbridge] I-D Action:draft-ietf-trill-prob-04.txt Message-ID: <20080627201501.B25CE3A6B1C@core3.amsl.com>