From d3e3e3 at gmail.com Wed Aug 4 09:52:58 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 4 Aug 2010 12:52:58 -0400 Subject: [rbridge] Mail regarding draft-ietf-trill-rbridge-protocol In-Reply-To: References: Message-ID: Hi Maria, On Wed, Aug 4, 2010 at 8:26 AM, wrote: > > Good morning, > > Im reading the RFC for TRILL and its benefits for multipathing and loop > avoidance. I have some doubts, among them i would like you can explain me > 1. if there is just one DRB per campus or can be more, > The DRB (Designated RBridge) in TRILL is the same as the "Designated Router" or "Designated Intermediate System" in IS-IS. There is one per link, not one per campus, using the word "link" as defined in the protocol draft. You may find it helpful to look at the IS-IS routing protocol. > 2. Also for a network similar to the scheme attached in this mail: > <> > This is a network example im trying to understand in order to ease my > comprehension of the protocol. Consider this four Rbridges interconnected > RB1, RB2, RB3 and App Fw Vlan x. Imagine they are connected through normal > Bridges (therefore frames must be with an outer header ehternet) > OK. Keep in mind that Appointed Forwarder status is a characteristic of an RBridge port, not of the entire RBridge. > In case Host B wants to send a packet to Host A, if these two belong to > vlan x, the native packet will go to the spanning tree formed by Bridge 4, 6 > and 5 up to RB1 wich could be the root tree (A.3.3 > draft-ietf-trill-rbridge-protocol-16) ; then RB1 will encapsulate in TRILL > Format and send the packet to the Appointed Forwarder for VLANx who will > know to which path send this packet towards Host A. ? > (A.3.3 is about an optional feature and is not too relevant to normal RBridge operation.) Well, first I'll talk about this after MAC addresses have been learned: The port on RB1 that is connected to Bridge 4 is the only RBridge port connected to that bridge LAN so it must be acting as the appointed forwarder for VLAN X, otherwise the frame would be blocked at that port. Since I am assuming that MAC addresses have already been learned, RB1 will know that the MAC address and VLAN for Host A is attached to the RB you have labeled "App Fwd" which I will call RBAF. So RB1 encapsulates the frame putting the nickname for RBAF in the Egress Nickname field. In this case the shortest path is just one hop, but in the general case their could be intermediate transit RBridges that keep forwarding the frame, hop-by-hop, to RBAF. When the frame arrives at RBAF, it recognizes itself as the Egress, decapsulates the inner frame, looks up the MAC address and VLAN to find out which port to output it on. Since, in this case, there is only one RBridge port connected to the bridged LAN consisting of Bridge 2, Bridge 3, and "Root Bridge", that port has to be the Appointed Forwarder for any VLANs that are going to get service from the RBridge campus for things attached to those bridges. The bridges then direct the frame down to Host A. If MAC addresses had not yet been learned, when the frame arrived at RB1, it would have been encapsulated as a multi-destination frame, sent on a distribution tree, and output on all ports in the campus which are Appointed Forwarders for the frame's VLAN. Note that there are two separate spanning trees in your diagram. One composed of Bridges 4, 5, and 6 and one composed of Bridges 2, 3, and the one you label "Root Bridge". RBridges terminate the spanning tree, just like Layer 3 routers do. > Please I would appreciate your help with my doubts and thank you for your > attention. > I hope the above is helpful, Thanks, Donald [image: Picture (Metafile)] > *Bel?n Eg?ez* > FT/RD/RD/BIZZ/CMC/LSD > Stagiaire de R&D - Services LAN et Stockage de Donn?es en r?seau > t?l. 01 45 29 62 42 > *maria.beleneguez at orange-ftgroup.com* > [image: Picture (Metafile)] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100804/55cf415c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/bmp Size: 1162 bytes Desc: not available Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100804/55cf415c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/bmp Size: 2474 bytes Desc: not available Url : http://mailman.postel.org/pipermail/rbridge/attachments/20100804/55cf415c/attachment-0001.bin From d3e3e3 at gmail.com Thu Aug 5 11:51:31 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 5 Aug 2010 14:51:31 -0400 Subject: [rbridge] Fwd: [Isis-wg] I-D ACTION:draft-ietf-isis-trill-00.txt In-Reply-To: <20100805184501.D350D3A68FD@core3.amsl.com> References: <20100805184501.D350D3A68FD@core3.amsl.com> Message-ID: This draft has been posted in the IS-IS working group. Thanks, Donald ---------- Forwarded message ---------- From: Date: Thu, Aug 5, 2010 at 2:45 PM Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-trill-00.txt To: i-d-announce at ietf.org Cc: isis-wg at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : TRILL Use of IS-IS Author(s) : D. Eastlake 3rd, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani Filename : draft-ietf-isis-trill-00.txt Pages : 27 Date : 2010-8-5 The IETF has standardized the TRILL protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-trill-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Isis-wg mailing list Isis-wg at ietf.org https://www.ietf.org/mailman/listinfo/isis-wg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100805/4e135ec3/attachment.html From d3e3e3 at gmail.com Thu Aug 12 14:08:49 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 12 Aug 2010 17:08:49 -0400 Subject: [rbridge] Draft Minutes from Maastricht posted Message-ID: Hi, Draft minutes from the TRILL WG meeting in Maastricht have been posted at http://www.ietf.org/proceedings/78/minutes/trill.txt Please try to get any comments in by August 27th. Thanks, Donald -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100812/904ef222/attachment.html From d3e3e3 at gmail.com Thu Aug 19 20:48:06 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 19 Aug 2010 23:48:06 -0400 Subject: [rbridge] draft-eastlake-trill-rbridge-dcb-00.txt Message-ID: From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Reply-to: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-eastlake-trill-rbridge-dcb-00.txt X-RSN: 1/0/935/31900/35258 X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=35258 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RBridges: Support of IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau Author(s) : D. Eastlake 3rd, M. Wadekar, A. Ghanwani Filename : draft-eastlake-trill-rbridge-dcb-00.txt Pages : 22 Date : 2010-8-18 IEEE 802.1 is developing standards as part of its Data Center Bridging (DCB) activity that amend the IEEE 802.1Q standard. These include 802.1Qau, 802.1Qaz, and 802.1Qbb. The intent of these three standards is (1) to efficiently minimize data loss due to queue overflow for selected classes of traffic within Local Area Networks (LANs) meeting certain conditions and (2) to provide means to allocate the available bandwidth to different classes of traffic. IEEE 802.1 is specifying theses standards and the behavior needed to support them in bridges and end stations. This document briefly explains the standards and specifies the implementation of these standards for RBridges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-dcb-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100819/1584e447/attachment.html From d3e3e3 at gmail.com Fri Aug 27 06:20:51 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 27 Aug 2010 09:20:51 -0400 Subject: [rbridge] Draft Minutes from Maastricht posted In-Reply-To: References: Message-ID: Since no corrections or comments were received, the posted minutes are the minutes from the Maastricht TRILL WG meeting. It is still possible to make corrections until 15 September. Thanks, Donald On Thu, Aug 12, 2010 at 5:08 PM, Donald Eastlake wrote: > Hi, > Draft minutes from the TRILL WG meeting in Maastricht have been posted at > http://www.ietf.org/proceedings/78/minutes/trill.txt > Please try to get any comments in by August 27th. > Thanks, > Donald From xuxh at huawei.com Fri Aug 27 18:39:42 2010 From: xuxh at huawei.com (Xu Xiaohu) Date: Sat, 28 Aug 2010 09:39:42 +0800 Subject: [rbridge] A question about the Rbridge ID Message-ID: <002101cb4651$e37d3500$26626e0a@china.huawei.com> Hi Radia, As stated in RBRIDGE specification: "To save room in the TRILL header and simplify forwarding lookups, a dynamic nickname acquisition protocol is run among the RBridges to select 2-octet nicknames for RBridges, unique within the campus, which are an abbreviation for the 6-octet IS-IS system ID of the RBridge. The 2-octet nicknames are used to specify the ingress and egress RBridges in the TRILL header." My question is why not consider to use IP addresses directly as Rbridge identifiers. To realize free configuration, these IP addresses could also be automatically generated in the similar way as the TRILL nickname does. Some conceivable benefits of using IP address as Rbridge ID include: 1) The core Rbridge could directly use the proven IP forwarding chips. 2) Matured OAM tools for IP, e.g., PING and Traceroute, can be used directly. Or do you have any plan to develop TRILL nickname based PING or Traceroute tools? 3) Features in the IP header, e.g., QoS, Fragmentation can be inherited naturally. For example, there is no need to use complex technology to deal with large packet as stated in Rbridge specification, "... If traffic engineering tools know which links support larger than minimally acceptable data packet sizes, paths can be computed that can support large data packets." Do you believe saving room in the packet header is a strong reason for developing a totally new TRILL header, rather than reusing the proven IP header for the TRILL Rbridge? Or would you please give some other reasons for this option? Best wishes, Xiaohu From d3e3e3 at gmail.com Sat Aug 28 15:00:16 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 28 Aug 2010 18:00:16 -0400 Subject: [rbridge] A question about the Rbridge ID In-Reply-To: <002101cb4651$e37d3500$26626e0a@china.huawei.com> References: <002101cb4651$e37d3500$26626e0a@china.huawei.com> Message-ID: Hi Xiaohu, I'll try to give an answer to your questions below: On Fri, Aug 27, 2010 at 9:39 PM, Xu Xiaohu wrote: > Hi Radia, > > As stated in RBRIDGE specification: > ? "To save room in the TRILL header and simplify forwarding lookups, a > ? dynamic nickname acquisition protocol is run among the RBridges to > ? select 2-octet nicknames for RBridges, unique within the campus, > ? which are an abbreviation for the 6-octet IS-IS system ID of the > ? RBridge. ?The 2-octet nicknames are used to specify the ingress and > ? egress RBridges in the TRILL header." > > My question is why not consider to use IP addresses directly as Rbridge > identifiers. To realize free configuration, these IP addresses could also be > automatically generated in the similar way as the TRILL nickname does. An obvious disadvantage is that IP addresses are twice as big as TRILL nicknames for IPv4 (worse for IPv6 but I can't see why you would use IPv6). But the main thing is that TRILL has already made its decision. > Some conceivable benefits of using IP address as Rbridge ID include: > > 1) The core Rbridge could directly use the proven IP forwarding chips. There was consideration of using various existing headers (IP, 802.1ah, MPLS) early on in the development of the TRILL standard but these were all rejected for one reason or another. It is my understanding that leading switching chip companies now all have TRILL chips so chip availability is not a problem. > 2) Matured OAM tools for IP, e.g., PING and Traceroute, can be used > directly. Or do you have any plan to develop TRILL nickname based PING or > Traceroute tools? RBridges are designed so that an RBridge level Traceroute could be added fairly easily. There are two drafts that I know of which are being developed for TRILL OAM tools of one sort or another. OAM is listed on the proposed new Charter for the TRILL WG. > 3) Features in the IP header, e.g., QoS, Fragmentation can be inherited > naturally. For example, there is no need to use complex technology to deal > with large packet as stated in Rbridge specification, "... If traffic > engineering tools know which links support larger than minimally acceptable > data packet sizes, paths can be computed that can support large data > packets." Constrained routing does not seem like a complex technology. But, in any case, people will be expecting Layer 2 QoS, that is frame priority, Data Center Bridging ( see http://tools.ietf.org/html/draft-eastlake-trill-rbridge-dcb-00 ), and things like that. It was also a goal to be able to incrementally replace 802.1Q customer bridges with RBridges and it seems like a complex design problem to try to do that with IP facilities. Finally, people engineering Layer 2 networks, particularly in things like Data Centers, generally have large MTUs, sometimes 9K jumbo frames, so exceeding the MTU is rarely a problem and if it is many people think the fragmentation is an inefficient solution. > Do you believe saving room in the packet header is a strong reason for > developing a totally new TRILL header, rather than reusing the proven IP > header for the TRILL Rbridge? Or would you please give some other reasons > for this option? I would say it doesn't matter any more. The TRILL header has already been developed, the TRILL base protocol specification is approved as an IETF standard, hardware has already been developed or adapted for TRILL, TRILL implementations are far enough along that a publicly announced TRILL interoperability event has been held at UNH IOL and it looks like a second one will be scheduled early next year. I don't see any reason for TRILL to change the basic design at this point. > Best wishes, > Xiaohu Thanks, Donald From xuxh at huawei.com Sun Aug 29 18:11:36 2010 From: xuxh at huawei.com (Xu Xiaohu) Date: Mon, 30 Aug 2010 09:11:36 +0800 Subject: [rbridge] A question about the Rbridge ID In-Reply-To: Message-ID: <001701cb47e0$4b38ef60$26626e0a@china.huawei.com> Hi Donald, > -----????----- > ???: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] ?? > Donald Eastlake > ????: 2010?8?29? 6:00 > ???: Xu Xiaohu > ??: rbridge at postel.org; Radia at alum.mit.edu > ??: Re: [rbridge] A question about the Rbridge ID > > Hi Xiaohu, > > I'll try to give an answer to your questions below: > > On Fri, Aug 27, 2010 at 9:39 PM, Xu Xiaohu wrote: > > Hi Radia, > > > > As stated in RBRIDGE specification: > > "To save room in the TRILL header and simplify forwarding lookups, a > > dynamic nickname acquisition protocol is run among the RBridges to > > select 2-octet nicknames for RBridges, unique within the campus, > > which are an abbreviation for the 6-octet IS-IS system ID of the > > RBridge. The 2-octet nicknames are used to specify the ingress and > > egress RBridges in the TRILL header." > > > > My question is why not consider to use IP addresses directly as Rbridge > > identifiers. To realize free configuration, these IP addresses could also > be > > automatically generated in the similar way as the TRILL nickname does. > > An obvious disadvantage is that IP addresses are twice as big as TRILL > nicknames for IPv4 (worse for IPv6 but I can't see why you would use > IPv6). But the main thing is that TRILL has already made its decision. > > > Some conceivable benefits of using IP address as Rbridge ID include: > > > > 1) The core Rbridge could directly use the proven IP forwarding chips. > > There was consideration of using various existing headers (IP, > 802.1ah, MPLS) early on in the development of the TRILL standard but > these were all rejected for one reason or another. It is my > understanding that leading switching chip companies now all have TRILL > chips so chip availability is not a problem. Yes, TRILL chips are available. However, the economy of scale for IP chips is not available for TRILL chips. Thanks for your reply anymore. Best wishes, Xiaohu > > 2) Matured OAM tools for IP, e.g., PING and Traceroute, can be used > > directly. Or do you have any plan to develop TRILL nickname based PING or > > Traceroute tools? > > RBridges are designed so that an RBridge level Traceroute could be > added fairly easily. There are two drafts that I know of which are > being developed for TRILL OAM tools of one sort or another. OAM is > listed on the proposed new Charter for the TRILL WG. > > > 3) Features in the IP header, e.g., QoS, Fragmentation can be inherited > > naturally. For example, there is no need to use complex technology to deal > > with large packet as stated in Rbridge specification, "... If traffic > > engineering tools know which links support larger than minimally acceptable > > data packet sizes, paths can be computed that can support large data > > packets." > > Constrained routing does not seem like a complex technology. But, in > any case, people will be expecting Layer 2 QoS, that is frame > priority, Data Center Bridging ( see > http://tools.ietf.org/html/draft-eastlake-trill-rbridge-dcb-00 ), and > things like that. It was also a goal to be able to incrementally > replace 802.1Q customer bridges with RBridges and it seems like a > complex design problem to try to do that with IP facilities. Finally, > people engineering Layer 2 networks, particularly in things like Data > Centers, generally have large MTUs, sometimes 9K jumbo frames, so > exceeding the MTU is rarely a problem and if it is many people think > the fragmentation is an inefficient solution. > > > Do you believe saving room in the packet header is a strong reason for > > developing a totally new TRILL header, rather than reusing the proven IP > > header for the TRILL Rbridge? Or would you please give some other reasons > > for this option? > > I would say it doesn't matter any more. The TRILL header has already > been developed, the TRILL base protocol specification is approved as > an IETF standard, hardware has already been developed or adapted for > TRILL, TRILL implementations are far enough along that a publicly > announced TRILL interoperability event has been held at UNH IOL and it > looks like a second one will be scheduled early next year. I don't see > any reason for TRILL to change the basic design at this point. > > > Best wishes, > > Xiaohu > > Thanks, > Donald > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge