[rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft
robey at huawei.com (robey) Wed, 01 March 2006 03:55 UTC
From: "robey at huawei.com"
Date: Wed, 01 Mar 2006 11:55:22 +0800
Subject: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft
References: <0IV4006ZFDCCSM@szxml02-in.huawei.com> <43FD44E7.6060700@sun.com> <43FD82F2.7050407@it.uc3m.es> <005001c639be$f0d04bb0$594d460a@china.huawei.com> <44043527.8060702@it.uc3m.es>
Message-ID: <00a801c63ce3$f728b240$594d460a@china.huawei.com>
Hi,Guillermo, I agree that the present solution of symmetic tree protocol developed by IEEE will limit the the core to 64 bridges maximum, so the symmetic tree protocol has to be improved further. I think Abridges draft providers simpler approach to implement shortest bridges, and misorder of frames can be avoided by the mechanisms as you presented in your mail, so it is deserved to study and promote the related work of Abridges. Best regards Robey ----- Original Message ----- From: "Guillermo Ib??ez" <gibanez at it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge at postel.org> Sent: Tuesday, February 28, 2006 7:33 PM Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft > Hi Robey, > > Many thanks for your feedback on the Abridges draft. > While preparing the response I have seen the mail from Eric Gray. I > agree with him and I think it applies as well to Abridges. The > disordering is equally very unlikely by the same reasons and some > additional for Abridges. > Forcing the trees to be symmetric may solve the problem, but > the only solution that I know with spanning trees protocols to ensure > symmetric trees (N. Finn, cut vectors) increases the convergence time of > the trees and limits the core to 64 bridges maximum. IS-IS is better to > ensure symmetric trees but to obtain same convergence speed as RSTP > based protocols is a pending task, as far as I know. > Broadcasts in the Abridges scenario are rather unfrequent. > Abridges do not use MAC learning. Abridges are targetted to big size > campus networks, where broadcasts should be very limited. So the > mechanism proposed in the draft is to avoid addresses learning of all > hosts in the network (it does not scale) and use ARP/Abridge Servers, > to perform the ARP resolution and to obtain the destination Abridge for > destination host. Hosts (pairs host-Abridge) are previously registered > upon detection by its designated Abridge. Even the forwarding between > Abridges is not based in MAC learning, but in forwarding via root port > of the tree of every Abridge. By using the servers, broadcasts are > reduced only to a backup mechanism role in the case of ARP or other > services using broadcast. > As the origin of the (potential but unlikely) problem is to use > different tree in broadcast of unknown hosts versus unicast, a remedy, > although not very efficient, is to replace broadcast by repeated unicast > to all ARB egress bridges via all root ports of the ingress Abridge. > In fact, The "all Abridges" multicast address might be used instead of > the broadcast address for this functionality. This would be a different > way of performing broadcasts among Abridges in the campus/enterprise core. > Regards > Guillermo > > robey wrote: > >>Hi,Guillermo Ibanez, >> >>I have read through your Abridge draft, and think it provider a simpler method to achieve shortest path bridges . >>In terms of approaches presented in Abridge draft, when packets of one specific traffic destined to same destination arrived at edge bridge, if these packets are kind of unknown packets, they will be broadcasted on ingress tree, then after learing unicast path FDB entry for the flow, packets of the traffic will be forwarded on the engress tree, in this case it is possible to bring about misorder of frames related to the traffic.How can you solve this problem? >> >>Maybe we can create symmetric tree, and still consider using ingress tree to forward broadcast/multicast/unknown packets and using egress tree to forward unicast packets, in this way not only can it overcome the above problem ,but also have a simpler method to create FDB entries and can avoid address learning (except foraddresses of end nodes) which can reduce traffic flooding when topology changes. >> >>Best regards >> >>robey >> >> >> >> >>From: "Guillermo Ib??ez" <gibanez at it.uc3m.es> >>To: "Developing a hybrid router/bridge." <rbridge at postel.org> >>Sent: Thursday, February 23, 2006 5:40 PM >>Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft >> > >> >> >> >>>Let me give my opinions interleaved. >>>By the way, as the Abridges draft we submitted last december is >>>somewhere between the current RBridges proposal and the IEEE Shortest >>>Path Bridging, we think it would help clarify to obtain comments to our >>>draft from the RBridges WG members. >>>Regards >>>Guillermo Ibanez >>> >>> >>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >>> >>>Guillermo Ibanez >>> >>> >>>Radia Perlman wrote: >>> >>> >>> >>>>Suping Zhai, >>>> >>>>You are not the first person to ask these questions. >>>>There is a lot of confusion over what is different between RSTP and STP, >>>>and what is different between RSTP and link state routing. >>>>I'll try to explain. >>>> >>>>1) What's the difference between RSTP and STP? >>>> >>>>RSTP and STP are almost identical, are compatible, >>>>and it would be less confusing to think of RSTP as a different >>>>version of the bridge spec than a different protocol. >>>> >>>>RSTP calculates the >>>>same spanning tree, and uses the same algorithm and even >>>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>>> >>>> >>>>from the Root bridge, which is the bridge with lowest ID/priority. >>> >>> >>>>The major difference between RSTP and STP >>>>is how they avoid temporary loops. >>>>STP did it with a timer. RSTP coordinates between neighbors >>>>to turn on links more quickly after topology changes. >>>> >>>>However, in either case, it is impossible to always avoid temporary >>>>loops...the simplest case is when a repeater comes up, or if too many >>>>spanning tree messages get lost due to congestion. >>>> >>>>So to summarize, both STP and RSTP use the same basic >>>>algorithm...the heart of algorithm is to calculate a tree >>>>of shortest paths from a single point. >>>>And the resulting tree and data packet >>>>forwarding path is the same in both (because it is the >>>>same algorithm). A single shared loop-free subset >>>>of the physical topology is calculated, upon which data packets are >>>>forwarded. >>>> >>>> >>>> >>>>2) What is the difference between RSTP and IS-IS? >>>> >>>>This is harder to answer than the difference between RSTP and STP, >>>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>>each other. IS-IS passes around topology >>>>information so that every RBridge calculates the shortest path between >>>>itself >>>>and each >>>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>>subset of its >>>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>>the spanning tree, >>>>then it cannot be used, even if it is the shortest path between point A >>>>and B, and >>>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>>on the links in the spanning tree, because no traffic can be on links >>>>not in the >>>>spanning tree. >>>> >>>>Also spanning tree bridges learn, based on >>>>seeing data traffic, which >>>>direction the source is. (which of its own local ports lead to the >>>>source of >>>>the data packet). So packets must always arrive from a particular source >>>>from >>>>the same direction or else bridges will get confused. In contrast, with >>>>IS-IS, >>>>switches can do path splitting; using multiple paths to reach a destination. >>>> >>>> >>>> >>>> >>>> >>>It is important to remember that the standard convergence times of RSTP >>>are lower than those of routing protocols, unless specific measures for >>>milliseconds convergence are applied. >>> >>> >>> >>>>3) What is difference between RSTP and RBridge approach? >>>> >>>>RBridge incorporates >>>>a TTL into the header of forwarded data packets so a temporary loop is >>>>not really bad, so it need not >>>>be very conservative about avoiding loops. Also, >>>>a link state protocol (IS-IS) calculates shortest >>>>pair-wise paths. Also, it can calculate multiple paths to the >>>>destination, and do path splitting. >>>> >>>> >>>> >>>> >>>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>>obtain shortest paths. They do not allow path splitting, but are less >>>complex than IS-IS >>>and do not mix STP and IS-IS protocols in same area. >>> >>> >>> >>>>4) What is the difference between recent work in IEEE to calculate >>>>per-ingress trees, and RBridge approach? >>>> >>>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>>before TRILL I tried to get IEEE interested in doing this approach, >>>>but they were not interested, perhaps because I didn't explain it >>>>well enough. Now that work has started in IETF, I think it is possible >>>>that IEEE will converge on the same solution, which would actually >>>>be good for the industry. >>>>Radia >>>> >>>> >>>> >>>> >>>I do not see an easy convergence between IEEE and RBridge proposals >>>unless the two groups cooperate strongly. >>>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>>distance vector to (multiple) root bridges) with multiple spanning trees >>>(this is my guess, I do not follow their recent activities), while >>>RBridge uses IS-IS (link state mechanisms) as basic protocol. >>> >>> >>>Guillermo Ibanez >>> >>> >>> >>>>Suping Zhai wrote: >>>> >>>> >>>> >>>> >>>> >>>>>hi, >>>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>>> >>>>>TIA. >>>>> >>>>>Best Regards, >>>>>zhaisuping at huawei.com >>>>>Huawei Technologies Co., Ltd. >>>>>Tel: +86-10-82836882 >>>>>Fax: +86-10-82836020 >>>>>2006-02-23 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>------------------------------------------------------------------------ >>>>> >>>>>_______________________________________________ >>>>>rbridge mailing list >>>>>rbridge at postel.org >>>>>http://www.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge at postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>-- >>>Guillermo Ib??ez >>>Departamento de Ingenier?a Telem?tica >>>Universidad Carlos III de Madrid >>>1.1.B.11 Colmenarejo 91-6241393 >>>4.1.F.13 Legan?s 91-6248794 >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge at postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>_______________________________________________ >>rbridge mailing list >>rbridge at postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > -------------------------------------------------------------------------------- > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge > Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k214Atu11820 for <rbridge@postel.org>; Tue, 28 Feb 2006 20:10:55 -0800 (PST) Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVF004Y7K321W@usaga01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 19:52:15 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVF006BCKTKHD@szxga02-in.huawei.com> for rbridge@postel.org; Wed, 01 Mar 2006 12:08:08 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVF00K6ZKTJFE@szxga02-in.huawei.com> for rbridge@postel.org; Wed, 01 Mar 2006 12:08:08 +0800 (CST) Received: from y41566 ([10.70.77.89]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVF001OKKZB2H@szxml01-in.huawei.com> for rbridge@postel.org; Wed, 01 Mar 2006 12:11:36 +0800 (CST) Date: Wed, 01 Mar 2006 11:55:22 +0800 From: robey <robey@huawei.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <00a801c63ce3$f728b240$594d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=UTF-8 X-Priority: 3 X-MSMail-priority: Normal References: <0IV4006ZFDCCSM@szxml02-in.huawei.com> <43FD44E7.6060700@sun.com> <43FD82F2.7050407@it.uc3m.es> <005001c639be$f0d04bb0$594d460a@china.huawei.com> <44043527.8060702@it.uc3m.es> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: robey@huawei.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id k214Atu11820 Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Mar 2006 04:12:01 -0000 Status: RO Content-Length: 11788 Hi,Guillermo, I agree that the present solution of symmetic tree protocol developed by IEEE will limit the the core to 64 bridges maximum, so the symmetic tree protocol has to be improved further. I think Abridges draft providers simpler approach to implement shortest bridges, and misorder of frames can be avoided by the mechanisms as you presented in your mail, so it is deserved to study and promote the related work of Abridges. Best regards Robey ----- Original Message ----- From: "Guillermo Ibáñez" <gibanez@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Sent: Tuesday, February 28, 2006 7:33 PM Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft > Hi Robey, > > Many thanks for your feedback on the Abridges draft. > While preparing the response I have seen the mail from Eric Gray. I > agree with him and I think it applies as well to Abridges. The > disordering is equally very unlikely by the same reasons and some > additional for Abridges. > Forcing the trees to be symmetric may solve the problem, but > the only solution that I know with spanning trees protocols to ensure > symmetric trees (N. Finn, cut vectors) increases the convergence time of > the trees and limits the core to 64 bridges maximum. IS-IS is better to > ensure symmetric trees but to obtain same convergence speed as RSTP > based protocols is a pending task, as far as I know. > Broadcasts in the Abridges scenario are rather unfrequent. > Abridges do not use MAC learning. Abridges are targetted to big size > campus networks, where broadcasts should be very limited. So the > mechanism proposed in the draft is to avoid addresses learning of all > hosts in the network (it does not scale) and use ARP/Abridge Servers, > to perform the ARP resolution and to obtain the destination Abridge for > destination host. Hosts (pairs host-Abridge) are previously registered > upon detection by its designated Abridge. Even the forwarding between > Abridges is not based in MAC learning, but in forwarding via root port > of the tree of every Abridge. By using the servers, broadcasts are > reduced only to a backup mechanism role in the case of ARP or other > services using broadcast. > As the origin of the (potential but unlikely) problem is to use > different tree in broadcast of unknown hosts versus unicast, a remedy, > although not very efficient, is to replace broadcast by repeated unicast > to all ARB egress bridges via all root ports of the ingress Abridge. > In fact, The "all Abridges" multicast address might be used instead of > the broadcast address for this functionality. This would be a different > way of performing broadcasts among Abridges in the campus/enterprise core. > Regards > Guillermo > > robey wrote: > >>Hi,Guillermo Ibanez, >> >>I have read through your Abridge draft, and think it provider a simpler method to achieve shortest path bridges . >>In terms of approaches presented in Abridge draft, when packets of one specific traffic destined to same destination arrived at edge bridge, if these packets are kind of unknown packets, they will be broadcasted on ingress tree, then after learing unicast path FDB entry for the flow, packets of the traffic will be forwarded on the engress tree, in this case it is possible to bring about misorder of frames related to the traffic.How can you solve this problem? >> >>Maybe we can create symmetric tree, and still consider using ingress tree to forward broadcast/multicast/unknown packets and using egress tree to forward unicast packets, in this way not only can it overcome the above problem ,but also have a simpler method to create FDB entries and can avoid address learning (except foraddresses of end nodes) which can reduce traffic flooding when topology changes. >> >>Best regards >> >>robey >> >> >> >> >>From: "Guillermo Ibáñez" <gibanez@it.uc3m.es> >>To: "Developing a hybrid router/bridge." <rbridge@postel.org> >>Sent: Thursday, February 23, 2006 5:40 PM >>Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft >> > >> >> >> >>>Let me give my opinions interleaved. >>>By the way, as the Abridges draft we submitted last december is >>>somewhere between the current RBridges proposal and the IEEE Shortest >>>Path Bridging, we think it would help clarify to obtain comments to our >>>draft from the RBridges WG members. >>>Regards >>>Guillermo Ibanez >>> >>> >>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >>> >>>Guillermo Ibanez >>> >>> >>>Radia Perlman wrote: >>> >>> >>> >>>>Suping Zhai, >>>> >>>>You are not the first person to ask these questions. >>>>There is a lot of confusion over what is different between RSTP and STP, >>>>and what is different between RSTP and link state routing. >>>>I'll try to explain. >>>> >>>>1) What's the difference between RSTP and STP? >>>> >>>>RSTP and STP are almost identical, are compatible, >>>>and it would be less confusing to think of RSTP as a different >>>>version of the bridge spec than a different protocol. >>>> >>>>RSTP calculates the >>>>same spanning tree, and uses the same algorithm and even >>>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>>> >>>> >>>>from the Root bridge, which is the bridge with lowest ID/priority. >>> >>> >>>>The major difference between RSTP and STP >>>>is how they avoid temporary loops. >>>>STP did it with a timer. RSTP coordinates between neighbors >>>>to turn on links more quickly after topology changes. >>>> >>>>However, in either case, it is impossible to always avoid temporary >>>>loops...the simplest case is when a repeater comes up, or if too many >>>>spanning tree messages get lost due to congestion. >>>> >>>>So to summarize, both STP and RSTP use the same basic >>>>algorithm...the heart of algorithm is to calculate a tree >>>>of shortest paths from a single point. >>>>And the resulting tree and data packet >>>>forwarding path is the same in both (because it is the >>>>same algorithm). A single shared loop-free subset >>>>of the physical topology is calculated, upon which data packets are >>>>forwarded. >>>> >>>> >>>> >>>>2) What is the difference between RSTP and IS-IS? >>>> >>>>This is harder to answer than the difference between RSTP and STP, >>>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>>each other. IS-IS passes around topology >>>>information so that every RBridge calculates the shortest path between >>>>itself >>>>and each >>>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>>subset of its >>>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>>the spanning tree, >>>>then it cannot be used, even if it is the shortest path between point A >>>>and B, and >>>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>>on the links in the spanning tree, because no traffic can be on links >>>>not in the >>>>spanning tree. >>>> >>>>Also spanning tree bridges learn, based on >>>>seeing data traffic, which >>>>direction the source is. (which of its own local ports lead to the >>>>source of >>>>the data packet). So packets must always arrive from a particular source >>>>from >>>>the same direction or else bridges will get confused. In contrast, with >>>>IS-IS, >>>>switches can do path splitting; using multiple paths to reach a destination. >>>> >>>> >>>> >>>> >>>> >>>It is important to remember that the standard convergence times of RSTP >>>are lower than those of routing protocols, unless specific measures for >>>milliseconds convergence are applied. >>> >>> >>> >>>>3) What is difference between RSTP and RBridge approach? >>>> >>>>RBridge incorporates >>>>a TTL into the header of forwarded data packets so a temporary loop is >>>>not really bad, so it need not >>>>be very conservative about avoiding loops. Also, >>>>a link state protocol (IS-IS) calculates shortest >>>>pair-wise paths. Also, it can calculate multiple paths to the >>>>destination, and do path splitting. >>>> >>>> >>>> >>>> >>>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>>obtain shortest paths. They do not allow path splitting, but are less >>>complex than IS-IS >>>and do not mix STP and IS-IS protocols in same area. >>> >>> >>> >>>>4) What is the difference between recent work in IEEE to calculate >>>>per-ingress trees, and RBridge approach? >>>> >>>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>>before TRILL I tried to get IEEE interested in doing this approach, >>>>but they were not interested, perhaps because I didn't explain it >>>>well enough. Now that work has started in IETF, I think it is possible >>>>that IEEE will converge on the same solution, which would actually >>>>be good for the industry. >>>>Radia >>>> >>>> >>>> >>>> >>>I do not see an easy convergence between IEEE and RBridge proposals >>>unless the two groups cooperate strongly. >>>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>>distance vector to (multiple) root bridges) with multiple spanning trees >>>(this is my guess, I do not follow their recent activities), while >>>RBridge uses IS-IS (link state mechanisms) as basic protocol. >>> >>> >>>Guillermo Ibanez >>> >>> >>> >>>>Suping Zhai wrote: >>>> >>>> >>>> >>>> >>>> >>>>>hi, >>>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>>> >>>>>TIA. >>>>> >>>>>Best Regards, >>>>>zhaisuping@huawei.com >>>>>Huawei Technologies Co., Ltd. >>>>>Tel: +86-10-82836882 >>>>>Fax: +86-10-82836020 >>>>>2006-02-23 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>------------------------------------------------------------------------ >>>>> >>>>>_______________________________________________ >>>>>rbridge mailing list >>>>>rbridge@postel.org >>>>>http://www.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>-- >>>Guillermo Ibáñez >>>Departamento de Ingeniería Telemática >>>Universidad Carlos III de Madrid >>>1.1.B.11 Colmenarejo 91-6241393 >>>4.1.F.13 Leganés 91-6248794 >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > -------------------------------------------------------------------------------- > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k211bBu28578 for <rbridge@postel.org>; Tue, 28 Feb 2006 17:37:11 -0800 (PST) Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVF00GY1D20N0@lhrga01-in.huawei.com> for rbridge@postel.org; Wed, 01 Mar 2006 01:20:25 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVF00H39E8RVT@szxga01-in.huawei.com> for rbridge@postel.org; Wed, 01 Mar 2006 09:46:03 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVF006HLE8QXP@szxga01-in.huawei.com> for rbridge@postel.org; Wed, 01 Mar 2006 09:46:03 +0800 (CST) Received: from z11024 ([10.111.12.75]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVF0027GECAYS@szxml02-in.huawei.com>; Wed, 01 Mar 2006 09:48:11 +0800 (CST) Date: Wed, 01 Mar 2006 09:35:34 +0800 From: Suping Zhai <zhaisuping@huawei.com> To: =?GB2312?Q?Guillermo Ib=A8=A2?ez?= <gibanez@it.uc3m.es>, "rbridge@postel.org" <rbridge@postel.org> Message-id: <0IVF0027HECAYS@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhaisuping@huawei.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k211bBu28578 Subject: Re: [rbridge] Additioanla clarification Abridges port types Re: A questionabout (R)STP and routing protocol / requestfor comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: zhaisuping@huawei.com, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Mar 2006 01:37:48 -0000 Status: RO Content-Length: 8793 Hi Guillermo, Thank you for your help and clarification. As far as now, I think this approach is the relative simple solution for the shortest bridge, but need further speculation and verification. I will present my ideas if any question wrt this solution. Regards, Suping >Hi Suping, > Just a clarification. Abridges have core ports (those connected to >other Abridges) and distribution ports (those connected to standard >bridges). Core ports run AMSTP protocol and distribution ports run RSTP >or STP protocol. The ports selfconfigure as core or distribution ports >according to the standard protocol migration procedure 802.1D (i.e. >depending on the protocol type of STP BPDUs they hear from neighbour). >Distribution ports are standard ports regarding learning. Specific >operation corresponds to core ports. >Regards >Guillermo > >Suping Zhai wrote: > >>Hi Guillermo, >>Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects, >>1) what's the orientation wrt the basic RSTP instance in the core Abrige network? What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance. >> >>2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points? >> >>Regards >>Suping >> >> >>>Let me give my opinions interleaved. >>>By the way, as the Abridges draft we submitted last december is >>>somewhere between the current RBridges proposal and the IEEE Shortest >>>Path Bridging, we think it would help clarify to obtain comments to our >>>draft from the RBridges WG members. >>>Regards >>>Guillermo Ibanez >>> >>> >>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >>> >>>Guillermo Ibanez >>> >>> >>>Radia Perlman wrote: >>> >>> >>> >>>>Suping Zhai, >>>> >>>>You are not the first person to ask these questions. >>>>There is a lot of confusion over what is different between RSTP and STP, >>>>and what is different between RSTP and link state routing. >>>>I'll try to explain. >>>> >>>>1) What's the difference between RSTP and STP? >>>> >>>>RSTP and STP are almost identical, are compatible, >>>>and it would be less confusing to think of RSTP as a different >>>>version of the bridge spec than a different protocol. >>>> >>>>RSTP calculates the >>>>same spanning tree, and uses the same algorithm and even >>>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>>> >>>> >>>>from the Root bridge, which is the bridge with lowest ID/priority. >>> >>> >>>>The major difference between RSTP and STP >>>>is how they avoid temporary loops. >>>>STP did it with a timer. RSTP coordinates between neighbors >>>>to turn on links more quickly after topology changes. >>>> >>>>However, in either case, it is impossible to always avoid temporary >>>>loops...the simplest case is when a repeater comes up, or if too many >>>>spanning tree messages get lost due to congestion. >>>> >>>>So to summarize, both STP and RSTP use the same basic >>>>algorithm...the heart of algorithm is to calculate a tree >>>>of shortest paths from a single point. >>>>And the resulting tree and data packet >>>>forwarding path is the same in both (because it is the >>>>same algorithm). A single shared loop-free subset >>>>of the physical topology is calculated, upon which data packets are >>>>forwarded. >>>> >>>> >>>> >>>>2) What is the difference between RSTP and IS-IS? >>>> >>>>This is harder to answer than the difference between RSTP and STP, >>>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>>each other. IS-IS passes around topology >>>>information so that every RBridge calculates the shortest path between >>>>itself >>>>and each >>>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>>subset of its >>>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>>the spanning tree, >>>>then it cannot be used, even if it is the shortest path between point A >>>>and B, and >>>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>>on the links in the spanning tree, because no traffic can be on links >>>>not in the >>>>spanning tree. >>>> >>>>Also spanning tree bridges learn, based on >>>>seeing data traffic, which >>>>direction the source is. (which of its own local ports lead to the >>>>source of >>>>the data packet). So packets must always arrive from a particular source >>>>from >>>>the same direction or else bridges will get confused. In contrast, with >>>>IS-IS, >>>>switches can do path splitting; using multiple paths to reach a destination. >>>> >>>> >>>> >>>> >>>> >>>It is important to remember that the standard convergence times of RSTP >>>are lower than those of routing protocols, unless specific measures for >>>milliseconds convergence are applied. >>> >>> >>> >>>>3) What is difference between RSTP and RBridge approach? >>>> >>>>RBridge incorporates >>>>a TTL into the header of forwarded data packets so a temporary loop is >>>>not really bad, so it need not >>>>be very conservative about avoiding loops. Also, >>>>a link state protocol (IS-IS) calculates shortest >>>>pair-wise paths. Also, it can calculate multiple paths to the >>>>destination, and do path splitting. >>>> >>>> >>>> >>>> >>>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>>obtain shortest paths. They do not allow path splitting, but are less >>>complex than IS-IS >>>and do not mix STP and IS-IS protocols in same area. >>> >>> >>> >>>>4) What is the difference between recent work in IEEE to calculate >>>>per-ingress trees, and RBridge approach? >>>> >>>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>>before TRILL I tried to get IEEE interested in doing this approach, >>>>but they were not interested, perhaps because I didn't explain it >>>>well enough. Now that work has started in IETF, I think it is possible >>>>that IEEE will converge on the same solution, which would actually >>>>be good for the industry. >>>>Radia >>>> >>>> >>>> >>>> >>>I do not see an easy convergence between IEEE and RBridge proposals >>>unless the two groups cooperate strongly. >>>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>>distance vector to (multiple) root bridges) with multiple spanning trees >>>(this is my guess, I do not follow their recent activities), while >>>RBridge uses IS-IS (link state mechanisms) as basic protocol. >>> >>> >>>Guillermo Ibanez >>> >>> >>> >>>>Suping Zhai wrote: >>>> >>>> >>>> >>>> >>>> >>>>>hi, >>>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>>> >>>>>TIA. >>>>> >>>>>Best Regards, >>>>>zhaisuping@huawei.com >>>>>Huawei Technologies Co., Ltd. >>>>>Tel: +86-10-82836882 >>>>>Fax: +86-10-82836020 >>>>>2006-02-23 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>------------------------------------------------------------------------ >>>>> >>>>>_______________________________________________ >>>>>rbridge mailing list >>>>>rbridge@postel.org >>>>>http://www.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>-- >>>Guillermo Ib???ez >>>Departamento de Ingenier??a Telem??tica >>>Universidad Carlos III de Madrid >>>1.1.B.11 Colmenarejo 91-6241393 >>>4.1.F.13 Legan??s 91-6248794 >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >> >> >> >> >> Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1SFWOu05252 for <rbridge@postel.org>; Tue, 28 Feb 2006 07:32:25 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C59E4A36DC; Tue, 28 Feb 2006 16:32:18 +0100 (CET) Received: from [163.117.139.233] (gibanez.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 123A6A36E0; Tue, 28 Feb 2006 16:32:18 +0100 (CET) Message-ID: <44046D03.3050505@it.uc3m.es> Date: Tue, 28 Feb 2006 16:32:19 +0100 From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhaisuping@huawei.com References: <0IVD001BPPFROR@szxml01-in.huawei.com> In-Reply-To: <0IVD001BPPFROR@szxml01-in.huawei.com> Content-Type: multipart/mixed; boundary="------------050904090305040305080102" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Cc: "rbridge@postel.org" <rbridge@postel.org> Subject: [rbridge] Additioanla clarification Abridges port types Re: A question about (R)STP and routing protocol / requestfor comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 15:32:36 -0000 Status: RO Content-Length: 9263 This is a multi-part message in MIME format. --------------050904090305040305080102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Suping, Just a clarification. Abridges have core ports (those connected to other Abridges) and distribution ports (those connected to standard bridges). Core ports run AMSTP protocol and distribution ports run RSTP or STP protocol. The ports selfconfigure as core or distribution ports according to the standard protocol migration procedure 802.1D (i.e. depending on the protocol type of STP BPDUs they hear from neighbour). Distribution ports are standard ports regarding learning. Specific operation corresponds to core ports. Regards Guillermo Suping Zhai wrote: >Hi Guillermo, >Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects, >1) what's the orientation wrt the basic RSTP instance in the core Abrige network? What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance. > >2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points? > >Regards >Suping > > >>Let me give my opinions interleaved. >>By the way, as the Abridges draft we submitted last december is >>somewhere between the current RBridges proposal and the IEEE Shortest >>Path Bridging, we think it would help clarify to obtain comments to our >>draft from the RBridges WG members. >>Regards >>Guillermo Ibanez >> >> >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >> >>Guillermo Ibanez >> >> >>Radia Perlman wrote: >> >> >> >>>Suping Zhai, >>> >>>You are not the first person to ask these questions. >>>There is a lot of confusion over what is different between RSTP and STP, >>>and what is different between RSTP and link state routing. >>>I'll try to explain. >>> >>>1) What's the difference between RSTP and STP? >>> >>>RSTP and STP are almost identical, are compatible, >>>and it would be less confusing to think of RSTP as a different >>>version of the bridge spec than a different protocol. >>> >>>RSTP calculates the >>>same spanning tree, and uses the same algorithm and even >>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>> >>> >>>from the Root bridge, which is the bridge with lowest ID/priority. >> >> >>>The major difference between RSTP and STP >>>is how they avoid temporary loops. >>>STP did it with a timer. RSTP coordinates between neighbors >>>to turn on links more quickly after topology changes. >>> >>>However, in either case, it is impossible to always avoid temporary >>>loops...the simplest case is when a repeater comes up, or if too many >>>spanning tree messages get lost due to congestion. >>> >>>So to summarize, both STP and RSTP use the same basic >>>algorithm...the heart of algorithm is to calculate a tree >>>of shortest paths from a single point. >>>And the resulting tree and data packet >>>forwarding path is the same in both (because it is the >>>same algorithm). A single shared loop-free subset >>>of the physical topology is calculated, upon which data packets are >>>forwarded. >>> >>> >>> >>>2) What is the difference between RSTP and IS-IS? >>> >>>This is harder to answer than the difference between RSTP and STP, >>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>each other. IS-IS passes around topology >>>information so that every RBridge calculates the shortest path between >>>itself >>>and each >>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>subset of its >>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>the spanning tree, >>>then it cannot be used, even if it is the shortest path between point A >>>and B, and >>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>on the links in the spanning tree, because no traffic can be on links >>>not in the >>>spanning tree. >>> >>>Also spanning tree bridges learn, based on >>>seeing data traffic, which >>>direction the source is. (which of its own local ports lead to the >>>source of >>>the data packet). So packets must always arrive from a particular source >>>from >>>the same direction or else bridges will get confused. In contrast, with >>>IS-IS, >>>switches can do path splitting; using multiple paths to reach a destination. >>> >>> >>> >>> >>> >>It is important to remember that the standard convergence times of RSTP >>are lower than those of routing protocols, unless specific measures for >>milliseconds convergence are applied. >> >> >> >>>3) What is difference between RSTP and RBridge approach? >>> >>>RBridge incorporates >>>a TTL into the header of forwarded data packets so a temporary loop is >>>not really bad, so it need not >>>be very conservative about avoiding loops. Also, >>>a link state protocol (IS-IS) calculates shortest >>>pair-wise paths. Also, it can calculate multiple paths to the >>>destination, and do path splitting. >>> >>> >>> >>> >>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>obtain shortest paths. They do not allow path splitting, but are less >>complex than IS-IS >>and do not mix STP and IS-IS protocols in same area. >> >> >> >>>4) What is the difference between recent work in IEEE to calculate >>>per-ingress trees, and RBridge approach? >>> >>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>before TRILL I tried to get IEEE interested in doing this approach, >>>but they were not interested, perhaps because I didn't explain it >>>well enough. Now that work has started in IETF, I think it is possible >>>that IEEE will converge on the same solution, which would actually >>>be good for the industry. >>>Radia >>> >>> >>> >>> >>I do not see an easy convergence between IEEE and RBridge proposals >>unless the two groups cooperate strongly. >>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>distance vector to (multiple) root bridges) with multiple spanning trees >>(this is my guess, I do not follow their recent activities), while >>RBridge uses IS-IS (link state mechanisms) as basic protocol. >> >> >>Guillermo Ibanez >> >> >> >>>Suping Zhai wrote: >>> >>> >>> >>> >>> >>>>hi, >>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>> >>>>TIA. >>>> >>>>Best Regards, >>>>zhaisuping@huawei.com >>>>Huawei Technologies Co., Ltd. >>>>Tel: +86-10-82836882 >>>>Fax: +86-10-82836020 >>>>2006-02-23 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >>-- >>Guillermo Ibá?ez >>Departamento de Ingeniería Telemática >>Universidad Carlos III de Madrid >>1.1.B.11 Colmenarejo 91-6241393 >>4.1.F.13 Leganés 91-6248794 >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > > > > > --------------050904090305040305080102 Content-Type: text/x-vcard; charset=utf-8; name="gibanez.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gibanez.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+ Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------050904090305040305080102-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1SDN1u07987 for <rbridge@postel.org>; Tue, 28 Feb 2006 05:23:01 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k1SDMtgL026967 for <rbridge@postel.org>; Tue, 28 Feb 2006 08:22:55 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01157 for <rbridge@postel.org>; Tue, 28 Feb 2006 08:22:54 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7R6N3N>; Tue, 28 Feb 2006 08:22:54 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0DAC1742@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Tue, 28 Feb 2006 08:22:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Subject: Re: [rbridge] A question about (R)STP and routing protocol / requ est for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 13:23:36 -0000 Status: RO Content-Length: 13404 Robey, Great, thanks for the clarification! -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of robey --> Sent: Monday, February 27, 2006 8:48 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] A question about (R)STP and routing --> protocol / requ est for comments to Abridges draft --> --> Hi,Eric, --> --> Thank for your comments first. --> I agree with your opinion that the likelihood of frame --> misorder is not big. --> Otherwise, about your question of "How does use of --> symmetric trees impact on out of order delivery?", I can --> say if symmetric trees is used ,the path destined to one --> destination before obtaining unicast FDB entries for that --> destination and the path destined to same destination after --> obtaining FDB entries through source address learning will --> be same,so no misorder of frames occur. --> --> Best regards --> --> Robey --> --> ----- Original Message ----- --> From: "Gray, Eric" <Eric.Gray@marconi.com> --> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> --> Sent: Tuesday, February 28, 2006 3:43 AM --> Subject: Re: [rbridge] A question about (R)STP and routing --> protocol / requ est for comments to Abridges draft --> --> --> Robey, --> --> I can't answer for Guilllermo's draft, but I can answer --> for (or comment on) the general case addressed by documents --> already chartered for the WG. Please see below... --> --> --> -----Original Message----- --> --> From: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of robey --> --> Sent: Friday, February 24, 2006 10:53 PM --> --> To: Developing a hybrid router/bridge. --> --> Subject: Re: [rbridge] A question about (R)STP and routing --> --> protocol / request for comments to Abridges draft --> --> --> --> Hi,Guillermo Ibanez, --> --> --> --> I have read through your Abridge draft, and think it --> --> provider a simpler method to achieve shortest path bridges . --> --> In terms of approaches presented in Abridge draft, when --> --> packets of one specific traffic destined to same --> --> destination arrived at edge bridge, if these packets are --> --> kind of unknown packets, they will be broadcasted on --> --> ingress tree, then after learing unicast path FDB entry --> --> for the flow, packets of the traffic will be forwarded on --> --> the engress tree, in this case it is possible to bring --> --> about misorder of frames related to the traffic. --> --> --> --> How can you solve this problem? --> --> Realistically speaking, several potential behaviors are not --> very likely. --> --> One example is the scenario where a lot of frames are sent --> to a host that has not yet been discovered on the network. --> --> Even in the case where this may occur, the degree to which --> small scale out of order delivery is pathological behavior --> with today's higher-level protocols is very small. --> --> Finally, because the ultimate unicast delivery path will be --> along the shortest path, the window of opportunity that may --> result in actual out of order delivery, in transition from --> flooding to simple delivery, is very small (especially if --> the traffic stream is a small fraction of link capacity). --> --> --> --> --> Maybe we can create symmetric tree, and still consider --> --> using ingress tree to forward broadcast/multicast/unknown --> --> packets and using egress tree to forward unicast packets, --> --> in this way not only can it overcome the above problem ,but --> --> also have a simpler method to create FDB entries and can --> --> avoid address learning (except foraddresses of end nodes) --> --> which can reduce traffic flooding when topology changes. --> --> How does use of symmetric trees impact on out of order delivery? --> --> --> --> --> Best regards --> --> --> --> robey --> --> --> --> --> --> --> --> --> --> From: "Guillermo Ib??ez" <gibanez@it.uc3m.es> --> --> To: "Developing a hybrid router/bridge." <rbridge@postel.org> --> --> Sent: Thursday, February 23, 2006 5:40 PM --> --> Subject: Re: [rbridge] A question about (R)STP and routing --> --> protocol / request for comments to Abridges draft --> --> --> --> --> --> > Let me give my opinions interleaved. --> --> > By the way, as the Abridges draft we submitted last --> december is --> --> > somewhere between the current RBridges proposal and the --> --> IEEE Shortest --> --> > Path Bridging, we think it would help clarify to obtain --> --> comments to our --> --> > draft from the RBridges WG members. --> --> > Regards --> --> > Guillermo Ibanez --> --> > --> --> > --> --> > --> --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri --> --> dge-00.txt --> --> > --> --> > Guillermo Ibanez --> --> > --> --> > --> --> > Radia Perlman wrote: --> --> > --> --> >>Suping Zhai, --> --> >> --> --> >>You are not the first person to ask these questions. --> --> >>There is a lot of confusion over what is different --> --> between RSTP and STP, --> --> >>and what is different between RSTP and link state routing. --> --> >>I'll try to explain. --> --> >> --> --> >>1) What's the difference between RSTP and STP? --> --> >> --> --> >>RSTP and STP are almost identical, are compatible, --> --> >>and it would be less confusing to think of RSTP as a different --> --> >>version of the bridge spec than a different protocol. --> --> >> --> --> >>RSTP calculates the --> --> >>same spanning tree, and uses the same algorithm and even --> --> >>packet formats as STP. Both RSTP and STP calculate a tree --> --> of shortest paths --> --> >>from the Root bridge, which is the bridge with lowest --> ID/priority. --> --> >> --> --> >>The major difference between RSTP and STP --> --> >>is how they avoid temporary loops. --> --> >>STP did it with a timer. RSTP coordinates between neighbors --> --> >>to turn on links more quickly after topology changes. --> --> >> --> --> >>However, in either case, it is impossible to always avoid --> --> temporary --> --> >>loops...the simplest case is when a repeater comes up, or --> --> if too many --> --> >>spanning tree messages get lost due to congestion. --> --> >> --> --> >>So to summarize, both STP and RSTP use the same basic --> --> >>algorithm...the heart of algorithm is to calculate a tree --> --> >>of shortest paths from a single point. --> --> >>And the resulting tree and data packet --> --> >>forwarding path is the same in both (because it is the --> --> >>same algorithm). A single shared loop-free subset --> --> >>of the physical topology is calculated, upon which data --> --> packets are --> --> >>forwarded. --> --> >> --> --> >> --> --> >> --> --> >>2) What is the difference between RSTP and IS-IS? --> --> >> --> --> >>This is harder to answer than the difference between --> RSTP and STP, --> --> >>because IS-IS and spanning tree (RSTP/STP) are so very --> --> different from --> --> >>each other. IS-IS passes around topology --> --> >>information so that every RBridge calculates the shortest --> --> path between --> --> >>itself --> --> >>and each --> --> >>destination. With spanning tree (RSTP/STP) each bridge --> --> just knows which --> --> >>subset of its --> --> >>own ports are "in" or "out" of the spanning tree. If a --> --> link is not in --> --> >>the spanning tree, --> --> >>then it cannot be used, even if it is the shortest path --> --> between point A --> --> >>and B, and --> --> >>pairwise paths can be quite suboptimal. Furthermore, --> --> traffic is concentrated --> --> >>on the links in the spanning tree, because no traffic can --> --> be on links --> --> >>not in the --> --> >>spanning tree. --> --> >> --> --> >>Also spanning tree bridges learn, based on --> --> >>seeing data traffic, which --> --> >>direction the source is. (which of its own local --> ports lead to the --> --> >>source of --> --> >>the data packet). So packets must always arrive from a --> --> particular source --> --> >>from --> --> >>the same direction or else bridges will get confused. In --> --> contrast, with --> --> >>IS-IS, --> --> >>switches can do path splitting; using multiple paths to --> --> reach a destination. --> --> >> --> --> >> --> --> >> --> --> > It is important to remember that the standard convergence --> --> times of RSTP --> --> > are lower than those of routing protocols, unless --> --> specific measures for --> --> > milliseconds convergence are applied. --> --> > --> --> >>3) What is difference between RSTP and RBridge approach? --> --> >> --> --> >>RBridge incorporates --> --> >>a TTL into the header of forwarded data packets so a --> --> temporary loop is --> --> >>not really bad, so it need not --> --> >>be very conservative about avoiding loops. Also, --> --> >>a link state protocol (IS-IS) calculates shortest --> --> >>pair-wise paths. Also, it can calculate multiple paths to the --> --> >>destination, and do path splitting. --> --> >> --> --> >> --> --> > Both IEEE Shortest Path Bridging and the Abridges draft --> --> proposal ( see --> --> > --> --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri --> --> dge-00.txt) --> --> > obtain shortest paths. They do not allow path splitting, --> --> but are less --> --> > complex than IS-IS --> --> > and do not mix STP and IS-IS protocols in same area. --> --> > --> --> >>4) What is the difference between recent work in IEEE --> to calculate --> --> >>per-ingress trees, and RBridge approach? --> --> >> --> --> >>IEEE may indeed wind up doing the same thing as RBridge. --> --> Several years --> --> >>before TRILL I tried to get IEEE interested in doing this --> --> approach, --> --> >>but they were not interested, perhaps because I --> didn't explain it --> --> >>well enough. Now that work has started in IETF, I think --> --> it is possible --> --> >>that IEEE will converge on the same solution, which --> would actually --> --> >>be good for the industry. --> --> >>Radia --> --> >> --> --> >> --> --> > I do not see an easy convergence between IEEE and RBridge --> --> proposals --> --> > unless the two groups cooperate strongly. --> --> > IEEE will likely preserve basic RSTP mechanisms (fast --> --> convergence and --> --> > distance vector to (multiple) root bridges) with multiple --> --> spanning trees --> --> > (this is my guess, I do not follow their recent --> --> activities), while --> --> > RBridge uses IS-IS (link state mechanisms) as basic protocol. --> --> > --> --> > --> --> > Guillermo Ibanez --> --> > --> --> >>Suping Zhai wrote: --> --> >> --> --> >> --> --> >> --> --> >>>hi, --> --> >>>I am confronted with some questions when reading the --> --> Rbridge protocol related draft and hope someone can help me --> --> with details. --> --> >>>What's the essential difference between (R)STP and --> --> routing protocol(e.g. IS-IS)? --> --> >>>How dose the routing protocol(e.g. IS-IS) can optimize --> --> the routing path while (R)STP can't? --> --> >>>Can we optimize the (R)STP protocol itself to reach that --> --> goal? If that's the case, then I think that all RBridge WG --> --> works can be substituted. And I have seen some work been --> --> done in IEEE802.1aq which is on the way to the per bridge --> --> MSTP road. But what I imagine is that should we get a --> --> comparable simple and untangled solution for the bridge --> --> network routing path? --> --> >>> --> --> >>>TIA. --> --> >>> --> --> >>>Best Regards, --> --> >>>zhaisuping@huawei.com --> --> >>>Huawei Technologies Co., Ltd. --> --> >>>Tel: +86-10-82836882 --> --> >>>Fax: +86-10-82836020 --> --> >>>2006-02-23 --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>>--------------------------------------------------------- --> --> --------------- --> --> >>> --> --> >>>_______________________________________________ --> --> >>>rbridge mailing list --> --> >>>rbridge@postel.org --> --> >>>http://www.postel.org/mailman/listinfo/rbridge --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >> --> --> >> --> --> >> --> --> >>---------------------------------------------------------- --> --> -------------- --> --> >> --> --> >>_______________________________________________ --> --> >>rbridge mailing list --> --> >>rbridge@postel.org --> --> >>http://www.postel.org/mailman/listinfo/rbridge --> --> >> --> --> >> --> --> > --> --> > -- --> --> > Guillermo Ib??ez --> --> > Departamento de Ingenier?a Telem?tica --> --> > Universidad Carlos III de Madrid --> --> > 1.1.B.11 Colmenarejo 91-6241393 --> --> > 4.1.F.13 Legan?s 91-6248794 --> --> > --> --> > _______________________________________________ --> --> > rbridge mailing list --> --> > rbridge@postel.org --> --> > http://www.postel.org/mailman/listinfo/rbridge --> --> > --> --> _______________________________________________ --> --> rbridge mailing list --> --> rbridge@postel.org --> --> http://www.postel.org/mailman/listinfo/rbridge --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1SCN7u25726 for <rbridge@postel.org>; Tue, 28 Feb 2006 04:23:10 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A3A7C8984C; Tue, 28 Feb 2006 13:23:01 +0100 (CET) Received: from [163.117.139.233] (gibanez.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id CAEDF897D5; Tue, 28 Feb 2006 13:23:00 +0100 (CET) Message-ID: <440440A6.8070606@it.uc3m.es> Date: Tue, 28 Feb 2006 13:23:02 +0100 From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhaisuping@huawei.com References: <0IVD001ZGPRJCZ@szxml01-in.huawei.com> In-Reply-To: <0IVD001ZGPRJCZ@szxml01-in.huawei.com> Content-Type: multipart/mixed; boundary="------------060501020909010303030807" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Cc: "rbridge@postel.org" <rbridge@postel.org> Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 12:23:55 -0000 Status: RO Content-Length: 9371 This is a multi-part message in MIME format. --------------060501020909010303030807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Abridges, as Rbridges are targetted to campus/enterprise networks, so different service providers are not contemplated. VLAN discrimination is optional, but we have to choose between selfconfiguration (one of the main objectives of Rbridges and Abridges) and features. The main issue with VLANs is that they require careful planning and configuration of their tree instances. In the campus network core, the single shortest path forwarding among Abridges ensures confidentiality by preventing traffic broadcasts. VLANs are suited at lower (access) level, provided that the configuration is automatic enough. The VLAN tag can be transported end to end inside the encapsulated frame. The only logical use I see for VLANs in the campus core is to link VLAN ID to the per-destination tree, as it is done in different ways in Global Open Ethernet and Shortest Path Bridging. I do not know how VLANs are assigned (manually, automatically) in these cases. It should be fully automatic, selfconfiguring. Suping Zhai wrote: >Hi Guillermo, >Still another observation wrt the following draft. >If in the core Abridge there is no VLAN discrimination, so are there any security issues or application complex implications? What I concern is that the Abridges in the core belong to different service provider or something like that, if the VLAN domain a good way to control the access? > >Regards, >Suping > > >>Let me give my opinions interleaved. >>By the way, as the Abridges draft we submitted last december is >>somewhere between the current RBridges proposal and the IEEE Shortest >>Path Bridging, we think it would help clarify to obtain comments to our >>draft from the RBridges WG members. >>Regards >>Guillermo Ibanez >> >> >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >> >>Guillermo Ibanez >> >> >>Radia Perlman wrote: >> >> >> >>>Suping Zhai, >>> >>>You are not the first person to ask these questions. >>>There is a lot of confusion over what is different between RSTP and STP, >>>and what is different between RSTP and link state routing. >>>I'll try to explain. >>> >>>1) What's the difference between RSTP and STP? >>> >>>RSTP and STP are almost identical, are compatible, >>>and it would be less confusing to think of RSTP as a different >>>version of the bridge spec than a different protocol. >>> >>>RSTP calculates the >>>same spanning tree, and uses the same algorithm and even >>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>> >>> >>>from the Root bridge, which is the bridge with lowest ID/priority. >> >> >>>The major difference between RSTP and STP >>>is how they avoid temporary loops. >>>STP did it with a timer. RSTP coordinates between neighbors >>>to turn on links more quickly after topology changes. >>> >>>However, in either case, it is impossible to always avoid temporary >>>loops...the simplest case is when a repeater comes up, or if too many >>>spanning tree messages get lost due to congestion. >>> >>>So to summarize, both STP and RSTP use the same basic >>>algorithm...the heart of algorithm is to calculate a tree >>>of shortest paths from a single point. >>>And the resulting tree and data packet >>>forwarding path is the same in both (because it is the >>>same algorithm). A single shared loop-free subset >>>of the physical topology is calculated, upon which data packets are >>>forwarded. >>> >>> >>> >>>2) What is the difference between RSTP and IS-IS? >>> >>>This is harder to answer than the difference between RSTP and STP, >>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>each other. IS-IS passes around topology >>>information so that every RBridge calculates the shortest path between >>>itself >>>and each >>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>subset of its >>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>the spanning tree, >>>then it cannot be used, even if it is the shortest path between point A >>>and B, and >>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>on the links in the spanning tree, because no traffic can be on links >>>not in the >>>spanning tree. >>> >>>Also spanning tree bridges learn, based on >>>seeing data traffic, which >>>direction the source is. (which of its own local ports lead to the >>>source of >>>the data packet). So packets must always arrive from a particular source >>>from >>>the same direction or else bridges will get confused. In contrast, with >>>IS-IS, >>>switches can do path splitting; using multiple paths to reach a destination. >>> >>> >>> >>> >>> >>It is important to remember that the standard convergence times of RSTP >>are lower than those of routing protocols, unless specific measures for >>milliseconds convergence are applied. >> >> >> >>>3) What is difference between RSTP and RBridge approach? >>> >>>RBridge incorporates >>>a TTL into the header of forwarded data packets so a temporary loop is >>>not really bad, so it need not >>>be very conservative about avoiding loops. Also, >>>a link state protocol (IS-IS) calculates shortest >>>pair-wise paths. Also, it can calculate multiple paths to the >>>destination, and do path splitting. >>> >>> >>> >>> >>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>obtain shortest paths. They do not allow path splitting, but are less >>complex than IS-IS >>and do not mix STP and IS-IS protocols in same area. >> >> >> >>>4) What is the difference between recent work in IEEE to calculate >>>per-ingress trees, and RBridge approach? >>> >>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>before TRILL I tried to get IEEE interested in doing this approach, >>>but they were not interested, perhaps because I didn't explain it >>>well enough. Now that work has started in IETF, I think it is possible >>>that IEEE will converge on the same solution, which would actually >>>be good for the industry. >>>Radia >>> >>> >>> >>> >>I do not see an easy convergence between IEEE and RBridge proposals >>unless the two groups cooperate strongly. >>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>distance vector to (multiple) root bridges) with multiple spanning trees >>(this is my guess, I do not follow their recent activities), while >>RBridge uses IS-IS (link state mechanisms) as basic protocol. >> >> >>Guillermo Ibanez >> >> >> >>>Suping Zhai wrote: >>> >>> >>> >>> >>> >>>>hi, >>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>> >>>>TIA. >>>> >>>>Best Regards, >>>>zhaisuping@huawei.com >>>>Huawei Technologies Co., Ltd. >>>>Tel: +86-10-82836882 >>>>Fax: +86-10-82836020 >>>>2006-02-23 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >>-- >>Guillermo Ibá?ez >>Departamento de Ingeniería Telemática >>Universidad Carlos III de Madrid >>1.1.B.11 Colmenarejo 91-6241393 >>4.1.F.13 Leganés 91-6248794 >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > > > > > --------------060501020909010303030807 Content-Type: text/x-vcard; charset=utf-8; name="gibanez.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gibanez.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+ Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------060501020909010303030807-- Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1SBhgu18186 for <rbridge@postel.org>; Tue, 28 Feb 2006 03:43:42 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 178D689A43; Tue, 28 Feb 2006 12:43:36 +0100 (CET) Received: from [163.117.139.233] (gibanez.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 74DD689A4D; Tue, 28 Feb 2006 12:43:35 +0100 (CET) Message-ID: <44043768.2070801@it.uc3m.es> Date: Tue, 28 Feb 2006 12:43:36 +0100 From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhaisuping@huawei.com References: <0IVD001BPPFROR@szxml01-in.huawei.com> In-Reply-To: <0IVD001BPPFROR@szxml01-in.huawei.com> Content-Type: multipart/mixed; boundary="------------010706030603050708040502" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Cc: "rbridge@postel.org" <rbridge@postel.org> Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 11:44:43 -0000 Status: RO Content-Length: 9410 This is a multi-part message in MIME format. --------------010706030603050708040502 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Suping, Please find my answers interleaved. Regards Guillermo Ibañez Suping Zhai wrote: >Hi Guillermo, >Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects, >1) what's the orientation wrt the basic RSTP instance in the core Abrige network? What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance. > > > There are two alternatives. The most traditional is to use a basic RSTP instance and a combined BPDU where the m-records of all tree instances are included. The most radical is to use fully independent RSTP instances. >2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points? > > > The double MAC learning refers to learning the association of host to its Abridge from inspecting in the double layer 2 encapsulated the pairs host origin-Abridge origin host destination-Abridge destination, to later resolve the destination Abridge from the destination host. Double MAC learning is only advisable in networks with a moderate number of hosts like metropolitan backbones. >Regards >Suping > > >>Let me give my opinions interleaved. >>By the way, as the Abridges draft we submitted last december is >>somewhere between the current RBridges proposal and the IEEE Shortest >>Path Bridging, we think it would help clarify to obtain comments to our >>draft from the RBridges WG members. >>Regards >>Guillermo Ibanez >> >> >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >> >>Guillermo Ibanez >> >> >>Radia Perlman wrote: >> >> >> >>>Suping Zhai, >>> >>>You are not the first person to ask these questions. >>>There is a lot of confusion over what is different between RSTP and STP, >>>and what is different between RSTP and link state routing. >>>I'll try to explain. >>> >>>1) What's the difference between RSTP and STP? >>> >>>RSTP and STP are almost identical, are compatible, >>>and it would be less confusing to think of RSTP as a different >>>version of the bridge spec than a different protocol. >>> >>>RSTP calculates the >>>same spanning tree, and uses the same algorithm and even >>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>> >>> >>>from the Root bridge, which is the bridge with lowest ID/priority. >> >> >>>The major difference between RSTP and STP >>>is how they avoid temporary loops. >>>STP did it with a timer. RSTP coordinates between neighbors >>>to turn on links more quickly after topology changes. >>> >>>However, in either case, it is impossible to always avoid temporary >>>loops...the simplest case is when a repeater comes up, or if too many >>>spanning tree messages get lost due to congestion. >>> >>>So to summarize, both STP and RSTP use the same basic >>>algorithm...the heart of algorithm is to calculate a tree >>>of shortest paths from a single point. >>>And the resulting tree and data packet >>>forwarding path is the same in both (because it is the >>>same algorithm). A single shared loop-free subset >>>of the physical topology is calculated, upon which data packets are >>>forwarded. >>> >>> >>> >>>2) What is the difference between RSTP and IS-IS? >>> >>>This is harder to answer than the difference between RSTP and STP, >>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>each other. IS-IS passes around topology >>>information so that every RBridge calculates the shortest path between >>>itself >>>and each >>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>subset of its >>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>the spanning tree, >>>then it cannot be used, even if it is the shortest path between point A >>>and B, and >>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>on the links in the spanning tree, because no traffic can be on links >>>not in the >>>spanning tree. >>> >>>Also spanning tree bridges learn, based on >>>seeing data traffic, which >>>direction the source is. (which of its own local ports lead to the >>>source of >>>the data packet). So packets must always arrive from a particular source >>>from >>>the same direction or else bridges will get confused. In contrast, with >>>IS-IS, >>>switches can do path splitting; using multiple paths to reach a destination. >>> >>> >>> >>> >>> >>It is important to remember that the standard convergence times of RSTP >>are lower than those of routing protocols, unless specific measures for >>milliseconds convergence are applied. >> >> >> >>>3) What is difference between RSTP and RBridge approach? >>> >>>RBridge incorporates >>>a TTL into the header of forwarded data packets so a temporary loop is >>>not really bad, so it need not >>>be very conservative about avoiding loops. Also, >>>a link state protocol (IS-IS) calculates shortest >>>pair-wise paths. Also, it can calculate multiple paths to the >>>destination, and do path splitting. >>> >>> >>> >>> >>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>obtain shortest paths. They do not allow path splitting, but are less >>complex than IS-IS >>and do not mix STP and IS-IS protocols in same area. >> >> >> >>>4) What is the difference between recent work in IEEE to calculate >>>per-ingress trees, and RBridge approach? >>> >>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>before TRILL I tried to get IEEE interested in doing this approach, >>>but they were not interested, perhaps because I didn't explain it >>>well enough. Now that work has started in IETF, I think it is possible >>>that IEEE will converge on the same solution, which would actually >>>be good for the industry. >>>Radia >>> >>> >>> >>> >>I do not see an easy convergence between IEEE and RBridge proposals >>unless the two groups cooperate strongly. >>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>distance vector to (multiple) root bridges) with multiple spanning trees >>(this is my guess, I do not follow their recent activities), while >>RBridge uses IS-IS (link state mechanisms) as basic protocol. >> >> >>Guillermo Ibanez >> >> >> >>>Suping Zhai wrote: >>> >>> >>> >>> >>> >>>>hi, >>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>> >>>>TIA. >>>> >>>>Best Regards, >>>>zhaisuping@huawei.com >>>>Huawei Technologies Co., Ltd. >>>>Tel: +86-10-82836882 >>>>Fax: +86-10-82836020 >>>>2006-02-23 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >>-- >>Guillermo Ibá?ez >>Departamento de Ingeniería Telemática >>Universidad Carlos III de Madrid >>1.1.B.11 Colmenarejo 91-6241393 >>4.1.F.13 Leganés 91-6248794 >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > > > > > --------------010706030603050708040502 Content-Type: text/x-vcard; charset=utf-8; name="gibanez.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gibanez.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+ Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------010706030603050708040502-- Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1SBYYu16142 for <rbridge@postel.org>; Tue, 28 Feb 2006 03:34:35 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B3CB889A2C for <rbridge@postel.org>; Tue, 28 Feb 2006 12:33:58 +0100 (CET) Received: from [163.117.139.233] (gibanez.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id AFE9D89A01 for <rbridge@postel.org>; Tue, 28 Feb 2006 12:33:57 +0100 (CET) Message-ID: <44043527.8060702@it.uc3m.es> Date: Tue, 28 Feb 2006 12:33:59 +0100 From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <0IV4006ZFDCCSM@szxml02-in.huawei.com> <43FD44E7.6060700@sun.com> <43FD82F2.7050407@it.uc3m.es> <005001c639be$f0d04bb0$594d460a@china.huawei.com> In-Reply-To: <005001c639be$f0d04bb0$594d460a@china.huawei.com> Content-Type: multipart/mixed; boundary="------------060802050809020202040009" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 11:36:00 -0000 Status: RO Content-Length: 11478 This is a multi-part message in MIME format. --------------060802050809020202040009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Robey, Many thanks for your feedback on the Abridges draft. While preparing the response I have seen the mail from Eric Gray. I agree with him and I think it applies as well to Abridges. The disordering is equally very unlikely by the same reasons and some additional for Abridges. Forcing the trees to be symmetric may solve the problem, but the only solution that I know with spanning trees protocols to ensure symmetric trees (N. Finn, cut vectors) increases the convergence time of the trees and limits the core to 64 bridges maximum. IS-IS is better to ensure symmetric trees but to obtain same convergence speed as RSTP based protocols is a pending task, as far as I know. Broadcasts in the Abridges scenario are rather unfrequent. Abridges do not use MAC learning. Abridges are targetted to big size campus networks, where broadcasts should be very limited. So the mechanism proposed in the draft is to avoid addresses learning of all hosts in the network (it does not scale) and use ARP/Abridge Servers, to perform the ARP resolution and to obtain the destination Abridge for destination host. Hosts (pairs host-Abridge) are previously registered upon detection by its designated Abridge. Even the forwarding between Abridges is not based in MAC learning, but in forwarding via root port of the tree of every Abridge. By using the servers, broadcasts are reduced only to a backup mechanism role in the case of ARP or other services using broadcast. As the origin of the (potential but unlikely) problem is to use different tree in broadcast of unknown hosts versus unicast, a remedy, although not very efficient, is to replace broadcast by repeated unicast to all ARB egress bridges via all root ports of the ingress Abridge. In fact, The "all Abridges" multicast address might be used instead of the broadcast address for this functionality. This would be a different way of performing broadcasts among Abridges in the campus/enterprise core. Regards Guillermo robey wrote: >Hi,Guillermo Ibanez, > >I have read through your Abridge draft, and think it provider a simpler method to achieve shortest path bridges . >In terms of approaches presented in Abridge draft, when packets of one specific traffic destined to same destination arrived at edge bridge, if these packets are kind of unknown packets, they will be broadcasted on ingress tree, then after learing unicast path FDB entry for the flow, packets of the traffic will be forwarded on the engress tree, in this case it is possible to bring about misorder of frames related to the traffic.How can you solve this problem? > >Maybe we can create symmetric tree, and still consider using ingress tree to forward broadcast/multicast/unknown packets and using egress tree to forward unicast packets, in this way not only can it overcome the above problem ,but also have a simpler method to create FDB entries and can avoid address learning (except foraddresses of end nodes) which can reduce traffic flooding when topology changes. > >Best regards > >robey > > > > >From: "Guillermo Ibáñez" <gibanez@it.uc3m.es> >To: "Developing a hybrid router/bridge." <rbridge@postel.org> >Sent: Thursday, February 23, 2006 5:40 PM >Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft > > > > >>Let me give my opinions interleaved. >>By the way, as the Abridges draft we submitted last december is >>somewhere between the current RBridges proposal and the IEEE Shortest >>Path Bridging, we think it would help clarify to obtain comments to our >>draft from the RBridges WG members. >>Regards >>Guillermo Ibanez >> >> >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt >> >>Guillermo Ibanez >> >> >>Radia Perlman wrote: >> >> >> >>>Suping Zhai, >>> >>>You are not the first person to ask these questions. >>>There is a lot of confusion over what is different between RSTP and STP, >>>and what is different between RSTP and link state routing. >>>I'll try to explain. >>> >>>1) What's the difference between RSTP and STP? >>> >>>RSTP and STP are almost identical, are compatible, >>>and it would be less confusing to think of RSTP as a different >>>version of the bridge spec than a different protocol. >>> >>>RSTP calculates the >>>same spanning tree, and uses the same algorithm and even >>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>> >>> >>>from the Root bridge, which is the bridge with lowest ID/priority. >> >> >>>The major difference between RSTP and STP >>>is how they avoid temporary loops. >>>STP did it with a timer. RSTP coordinates between neighbors >>>to turn on links more quickly after topology changes. >>> >>>However, in either case, it is impossible to always avoid temporary >>>loops...the simplest case is when a repeater comes up, or if too many >>>spanning tree messages get lost due to congestion. >>> >>>So to summarize, both STP and RSTP use the same basic >>>algorithm...the heart of algorithm is to calculate a tree >>>of shortest paths from a single point. >>>And the resulting tree and data packet >>>forwarding path is the same in both (because it is the >>>same algorithm). A single shared loop-free subset >>>of the physical topology is calculated, upon which data packets are >>>forwarded. >>> >>> >>> >>>2) What is the difference between RSTP and IS-IS? >>> >>>This is harder to answer than the difference between RSTP and STP, >>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>each other. IS-IS passes around topology >>>information so that every RBridge calculates the shortest path between >>>itself >>>and each >>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>subset of its >>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>the spanning tree, >>>then it cannot be used, even if it is the shortest path between point A >>>and B, and >>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>on the links in the spanning tree, because no traffic can be on links >>>not in the >>>spanning tree. >>> >>>Also spanning tree bridges learn, based on >>>seeing data traffic, which >>>direction the source is. (which of its own local ports lead to the >>>source of >>>the data packet). So packets must always arrive from a particular source >>>from >>>the same direction or else bridges will get confused. In contrast, with >>>IS-IS, >>>switches can do path splitting; using multiple paths to reach a destination. >>> >>> >>> >>> >>> >>It is important to remember that the standard convergence times of RSTP >>are lower than those of routing protocols, unless specific measures for >>milliseconds convergence are applied. >> >> >> >>>3) What is difference between RSTP and RBridge approach? >>> >>>RBridge incorporates >>>a TTL into the header of forwarded data packets so a temporary loop is >>>not really bad, so it need not >>>be very conservative about avoiding loops. Also, >>>a link state protocol (IS-IS) calculates shortest >>>pair-wise paths. Also, it can calculate multiple paths to the >>>destination, and do path splitting. >>> >>> >>> >>> >>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >>obtain shortest paths. They do not allow path splitting, but are less >>complex than IS-IS >>and do not mix STP and IS-IS protocols in same area. >> >> >> >>>4) What is the difference between recent work in IEEE to calculate >>>per-ingress trees, and RBridge approach? >>> >>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>before TRILL I tried to get IEEE interested in doing this approach, >>>but they were not interested, perhaps because I didn't explain it >>>well enough. Now that work has started in IETF, I think it is possible >>>that IEEE will converge on the same solution, which would actually >>>be good for the industry. >>>Radia >>> >>> >>> >>> >>I do not see an easy convergence between IEEE and RBridge proposals >>unless the two groups cooperate strongly. >>IEEE will likely preserve basic RSTP mechanisms (fast convergence and >>distance vector to (multiple) root bridges) with multiple spanning trees >>(this is my guess, I do not follow their recent activities), while >>RBridge uses IS-IS (link state mechanisms) as basic protocol. >> >> >>Guillermo Ibanez >> >> >> >>>Suping Zhai wrote: >>> >>> >>> >>> >>> >>>>hi, >>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>> >>>>TIA. >>>> >>>>Best Regards, >>>>zhaisuping@huawei.com >>>>Huawei Technologies Co., Ltd. >>>>Tel: +86-10-82836882 >>>>Fax: +86-10-82836020 >>>>2006-02-23 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >>-- >>Guillermo Ibáñez >>Departamento de Ingeniería Telemática >>Universidad Carlos III de Madrid >>1.1.B.11 Colmenarejo 91-6241393 >>4.1.F.13 Leganés 91-6248794 >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> >> >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > --------------060802050809020202040009 Content-Type: text/x-vcard; charset=utf-8; name="gibanez.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gibanez.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6R3VpbGxlcm1vIEEuIEliPUMzPUEx PUMzPUIxZXoNCm47cXVvdGVkLXByaW50YWJsZTpJYj1DMz1BMT1DMz1CMWV6O0d1aWxsZXJt byBBLg0Kb3JnOlVuaXZlcnNpZGFkIENhcmxvcyBJSUkgTWFkcmlkO0luZ2VuaWVyaWEgVGVs ZW1hdGljYQ0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7TGVnYW49QzM9QTlzO01hZHJpZDsy ODkxMTtTcGFpbg0KZW1haWw7aW50ZXJuZXQ6Z2liYW5lekBpdC51YzNtLmVzDQp0aXRsZTpQ cm9mLiBEci4NCnRlbDt3b3JrOjM0IDkxIDYyNDEzNDMNCnRlbDtmYXg6MzQgNjI0ODc0OQ0K eC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vZW5qYW1icmUuaXQudWMzbS5lcy9+ Z2liYW5lei9pbmRpY2UuaHRtbA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------060802050809020202040009-- Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1S3oDu13528 for <rbridge@postel.org>; Mon, 27 Feb 2006 19:50:13 -0800 (PST) Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD0068KNZE6N@lhrga01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 03:21:15 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD0099BP0N6T@szxga03-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 11:43:36 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD00IC4P0NT4@szxga03-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 11:43:35 +0800 (CST) Received: from z11024 ([10.111.12.75]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVD001BOPFQOR@szxml01-in.huawei.com>; Tue, 28 Feb 2006 11:52:39 +0800 (CST) Date: Tue, 28 Feb 2006 11:36:27 +0800 From: Suping Zhai <zhaisuping@huawei.com> To: =?GB2312?Q?Guillermo Ib=A8=A2?ez?= <gibanez@it.uc3m.es>, "rbridge@postel.org" <rbridge@postel.org> Message-id: <0IVD001BPPFROR@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhaisuping@huawei.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k1S3oDu13528 Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: zhaisuping@huawei.com, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 03:50:33 -0000 Status: RO Content-Length: 7347 Hi Guillermo, Thank you for your response. After I have gone through the following draft, there are some doubts wrt the following aspects, 1) what's the orientation wrt the basic RSTP instance in the core Abrige network? What I understand is per-Abridge RSTP is enough for the forwarding and there is no need for the aforementioned basic RSTP instance. 2) In 4.3.2 it says that Abridge may learn from the received frames both outer MAC and inter MAC address, called the double MAC adress learning. On the other hand, when talk about the symmetric spanning tree problem in section 4.8 and 6.2, it says that Abridges don't learn addresses. So which is the right one or I missed some points? Regards Suping >Let me give my opinions interleaved. >By the way, as the Abridges draft we submitted last december is >somewhere between the current RBridges proposal and the IEEE Shortest >Path Bridging, we think it would help clarify to obtain comments to our >draft from the RBridges WG members. >Regards >Guillermo Ibanez > > >http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt > >Guillermo Ibanez > > >Radia Perlman wrote: > >>Suping Zhai, >> >>You are not the first person to ask these questions. >>There is a lot of confusion over what is different between RSTP and STP, >>and what is different between RSTP and link state routing. >>I'll try to explain. >> >>1) What's the difference between RSTP and STP? >> >>RSTP and STP are almost identical, are compatible, >>and it would be less confusing to think of RSTP as a different >>version of the bridge spec than a different protocol. >> >>RSTP calculates the >>same spanning tree, and uses the same algorithm and even >>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>from the Root bridge, which is the bridge with lowest ID/priority. >> >>The major difference between RSTP and STP >>is how they avoid temporary loops. >>STP did it with a timer. RSTP coordinates between neighbors >>to turn on links more quickly after topology changes. >> >>However, in either case, it is impossible to always avoid temporary >>loops...the simplest case is when a repeater comes up, or if too many >>spanning tree messages get lost due to congestion. >> >>So to summarize, both STP and RSTP use the same basic >>algorithm...the heart of algorithm is to calculate a tree >>of shortest paths from a single point. >>And the resulting tree and data packet >>forwarding path is the same in both (because it is the >>same algorithm). A single shared loop-free subset >>of the physical topology is calculated, upon which data packets are >>forwarded. >> >> >> >>2) What is the difference between RSTP and IS-IS? >> >>This is harder to answer than the difference between RSTP and STP, >>because IS-IS and spanning tree (RSTP/STP) are so very different from >>each other. IS-IS passes around topology >>information so that every RBridge calculates the shortest path between >>itself >>and each >>destination. With spanning tree (RSTP/STP) each bridge just knows which >>subset of its >>own ports are "in" or "out" of the spanning tree. If a link is not in >>the spanning tree, >>then it cannot be used, even if it is the shortest path between point A >>and B, and >>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>on the links in the spanning tree, because no traffic can be on links >>not in the >>spanning tree. >> >>Also spanning tree bridges learn, based on >>seeing data traffic, which >>direction the source is. (which of its own local ports lead to the >>source of >>the data packet). So packets must always arrive from a particular source >>from >>the same direction or else bridges will get confused. In contrast, with >>IS-IS, >>switches can do path splitting; using multiple paths to reach a destination. >> >> >> >It is important to remember that the standard convergence times of RSTP >are lower than those of routing protocols, unless specific measures for >milliseconds convergence are applied. > >>3) What is difference between RSTP and RBridge approach? >> >>RBridge incorporates >>a TTL into the header of forwarded data packets so a temporary loop is >>not really bad, so it need not >>be very conservative about avoiding loops. Also, >>a link state protocol (IS-IS) calculates shortest >>pair-wise paths. Also, it can calculate multiple paths to the >>destination, and do path splitting. >> >> >Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >obtain shortest paths. They do not allow path splitting, but are less >complex than IS-IS >and do not mix STP and IS-IS protocols in same area. > >>4) What is the difference between recent work in IEEE to calculate >>per-ingress trees, and RBridge approach? >> >>IEEE may indeed wind up doing the same thing as RBridge. Several years >>before TRILL I tried to get IEEE interested in doing this approach, >>but they were not interested, perhaps because I didn't explain it >>well enough. Now that work has started in IETF, I think it is possible >>that IEEE will converge on the same solution, which would actually >>be good for the industry. >>Radia >> >> >I do not see an easy convergence between IEEE and RBridge proposals >unless the two groups cooperate strongly. >IEEE will likely preserve basic RSTP mechanisms (fast convergence and >distance vector to (multiple) root bridges) with multiple spanning trees >(this is my guess, I do not follow their recent activities), while >RBridge uses IS-IS (link state mechanisms) as basic protocol. > > >Guillermo Ibanez > >>Suping Zhai wrote: >> >> >> >>>hi, >>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>> >>>TIA. >>> >>>Best Regards, >>>zhaisuping@huawei.com >>>Huawei Technologies Co., Ltd. >>>Tel: +86-10-82836882 >>>Fax: +86-10-82836020 >>>2006-02-23 >>> >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > >-- >Guillermo Ib???ez >Departamento de Ingenier??a Telem??tica >Universidad Carlos III de Madrid >1.1.B.11 Colmenarejo 91-6241393 >4.1.F.13 Legan??s 91-6248794 > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1S3oEu13529 for <rbridge@postel.org>; Mon, 27 Feb 2006 19:50:14 -0800 (PST) Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD006K9OB66N@lhrga01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 03:28:19 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD00M7CPCGJC@szxga03-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 11:50:40 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD007E2PCF16@szxga03-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 11:50:39 +0800 (CST) Received: from z11024 ([10.111.12.75]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVD001ZDPRJCZ@szxml01-in.huawei.com>; Tue, 28 Feb 2006 11:59:43 +0800 (CST) Date: Tue, 28 Feb 2006 11:43:31 +0800 From: Suping Zhai <zhaisuping@huawei.com> To: =?GB2312?Q?Guillermo Ib=A8=A2?ez?= <gibanez@it.uc3m.es>, "rbridge@postel.org" <rbridge@postel.org> Message-id: <0IVD001ZGPRJCZ@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhaisuping@huawei.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k1S3oEu13529 Subject: Re: [rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: zhaisuping@huawei.com, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 03:50:33 -0000 Status: RO Content-Length: 7008 Hi Guillermo, Still another observation wrt the following draft. If in the core Abridge there is no VLAN discrimination, so are there any security issues or application complex implications? What I concern is that the Abridges in the core belong to different service provider or something like that, if the VLAN domain a good way to control the access? Regards, Suping >Let me give my opinions interleaved. >By the way, as the Abridges draft we submitted last december is >somewhere between the current RBridges proposal and the IEEE Shortest >Path Bridging, we think it would help clarify to obtain comments to our >draft from the RBridges WG members. >Regards >Guillermo Ibanez > > >http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt > >Guillermo Ibanez > > >Radia Perlman wrote: > >>Suping Zhai, >> >>You are not the first person to ask these questions. >>There is a lot of confusion over what is different between RSTP and STP, >>and what is different between RSTP and link state routing. >>I'll try to explain. >> >>1) What's the difference between RSTP and STP? >> >>RSTP and STP are almost identical, are compatible, >>and it would be less confusing to think of RSTP as a different >>version of the bridge spec than a different protocol. >> >>RSTP calculates the >>same spanning tree, and uses the same algorithm and even >>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>from the Root bridge, which is the bridge with lowest ID/priority. >> >>The major difference between RSTP and STP >>is how they avoid temporary loops. >>STP did it with a timer. RSTP coordinates between neighbors >>to turn on links more quickly after topology changes. >> >>However, in either case, it is impossible to always avoid temporary >>loops...the simplest case is when a repeater comes up, or if too many >>spanning tree messages get lost due to congestion. >> >>So to summarize, both STP and RSTP use the same basic >>algorithm...the heart of algorithm is to calculate a tree >>of shortest paths from a single point. >>And the resulting tree and data packet >>forwarding path is the same in both (because it is the >>same algorithm). A single shared loop-free subset >>of the physical topology is calculated, upon which data packets are >>forwarded. >> >> >> >>2) What is the difference between RSTP and IS-IS? >> >>This is harder to answer than the difference between RSTP and STP, >>because IS-IS and spanning tree (RSTP/STP) are so very different from >>each other. IS-IS passes around topology >>information so that every RBridge calculates the shortest path between >>itself >>and each >>destination. With spanning tree (RSTP/STP) each bridge just knows which >>subset of its >>own ports are "in" or "out" of the spanning tree. If a link is not in >>the spanning tree, >>then it cannot be used, even if it is the shortest path between point A >>and B, and >>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>on the links in the spanning tree, because no traffic can be on links >>not in the >>spanning tree. >> >>Also spanning tree bridges learn, based on >>seeing data traffic, which >>direction the source is. (which of its own local ports lead to the >>source of >>the data packet). So packets must always arrive from a particular source >>from >>the same direction or else bridges will get confused. In contrast, with >>IS-IS, >>switches can do path splitting; using multiple paths to reach a destination. >> >> >> >It is important to remember that the standard convergence times of RSTP >are lower than those of routing protocols, unless specific measures for >milliseconds convergence are applied. > >>3) What is difference between RSTP and RBridge approach? >> >>RBridge incorporates >>a TTL into the header of forwarded data packets so a temporary loop is >>not really bad, so it need not >>be very conservative about avoiding loops. Also, >>a link state protocol (IS-IS) calculates shortest >>pair-wise paths. Also, it can calculate multiple paths to the >>destination, and do path splitting. >> >> >Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see >http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) >obtain shortest paths. They do not allow path splitting, but are less >complex than IS-IS >and do not mix STP and IS-IS protocols in same area. > >>4) What is the difference between recent work in IEEE to calculate >>per-ingress trees, and RBridge approach? >> >>IEEE may indeed wind up doing the same thing as RBridge. Several years >>before TRILL I tried to get IEEE interested in doing this approach, >>but they were not interested, perhaps because I didn't explain it >>well enough. Now that work has started in IETF, I think it is possible >>that IEEE will converge on the same solution, which would actually >>be good for the industry. >>Radia >> >> >I do not see an easy convergence between IEEE and RBridge proposals >unless the two groups cooperate strongly. >IEEE will likely preserve basic RSTP mechanisms (fast convergence and >distance vector to (multiple) root bridges) with multiple spanning trees >(this is my guess, I do not follow their recent activities), while >RBridge uses IS-IS (link state mechanisms) as basic protocol. > > >Guillermo Ibanez > >>Suping Zhai wrote: >> >> >> >>>hi, >>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>> >>>TIA. >>> >>>Best Regards, >>>zhaisuping@huawei.com >>>Huawei Technologies Co., Ltd. >>>Tel: +86-10-82836882 >>>Fax: +86-10-82836020 >>>2006-02-23 >>> >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > >-- >Guillermo Ib???ez >Departamento de Ingenier??a Telem??tica >Universidad Carlos III de Madrid >1.1.B.11 Colmenarejo 91-6241393 >4.1.F.13 Legan??s 91-6248794 > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1S20Tu14173 for <rbridge@postel.org>; Mon, 27 Feb 2006 18:00:29 -0800 (PST) Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD001AKIZ8AV@lhrga01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 01:33:09 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD00EJEK5WG3@szxga01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 09:58:44 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD00CVFK5V8U@szxga01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 09:58:44 +0800 (CST) Received: from y41566 ([10.70.77.89]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVD00MT5KFISE@szxml01-in.huawei.com> for rbridge@postel.org; Tue, 28 Feb 2006 10:04:30 +0800 (CST) Date: Tue, 28 Feb 2006 09:48:18 +0800 From: robey <robey@huawei.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <002201c63c09$0c86f060$594d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 X-Priority: 3 X-MSMail-priority: Normal References: <313680C9A886D511A06000204840E1CF0DAC1737@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: robey@huawei.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id k1S20Tu14173 Subject: Re: [rbridge] A question about (R)STP and routing protocol / requ est for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2006 02:01:50 -0000 Status: RO Content-Length: 11461 Hi,Eric, Thank for your comments first. I agree with your opinion that the likelihood of frame misorder is not big. Otherwise, about your question of "How does use of symmetric trees impact on out of order delivery?", I can say if symmetric trees is used ,the path destined to one destination before obtaining unicast FDB entries for that destination and the path destined to same destination after obtaining FDB entries through source address learning will be same,so no misorder of frames occur. Best regards Robey ----- Original Message ----- From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Sent: Tuesday, February 28, 2006 3:43 AM Subject: Re: [rbridge] A question about (R)STP and routing protocol / requ est for comments to Abridges draft Robey, I can't answer for Guilllermo's draft, but I can answer for (or comment on) the general case addressed by documents already chartered for the WG. Please see below... --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of robey --> Sent: Friday, February 24, 2006 10:53 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] A question about (R)STP and routing --> protocol / request for comments to Abridges draft --> --> Hi,Guillermo Ibanez, --> --> I have read through your Abridge draft, and think it --> provider a simpler method to achieve shortest path bridges . --> In terms of approaches presented in Abridge draft, when --> packets of one specific traffic destined to same --> destination arrived at edge bridge, if these packets are --> kind of unknown packets, they will be broadcasted on --> ingress tree, then after learing unicast path FDB entry --> for the flow, packets of the traffic will be forwarded on --> the engress tree, in this case it is possible to bring --> about misorder of frames related to the traffic. --> --> How can you solve this problem? Realistically speaking, several potential behaviors are not very likely. One example is the scenario where a lot of frames are sent to a host that has not yet been discovered on the network. Even in the case where this may occur, the degree to which small scale out of order delivery is pathological behavior with today's higher-level protocols is very small. Finally, because the ultimate unicast delivery path will be along the shortest path, the window of opportunity that may result in actual out of order delivery, in transition from flooding to simple delivery, is very small (especially if the traffic stream is a small fraction of link capacity). --> --> Maybe we can create symmetric tree, and still consider --> using ingress tree to forward broadcast/multicast/unknown --> packets and using egress tree to forward unicast packets, --> in this way not only can it overcome the above problem ,but --> also have a simpler method to create FDB entries and can --> avoid address learning (except foraddresses of end nodes) --> which can reduce traffic flooding when topology changes. How does use of symmetric trees impact on out of order delivery? --> --> Best regards --> --> robey --> --> --> --> --> From: "Guillermo Ib??ez" <gibanez@it.uc3m.es> --> To: "Developing a hybrid router/bridge." <rbridge@postel.org> --> Sent: Thursday, February 23, 2006 5:40 PM --> Subject: Re: [rbridge] A question about (R)STP and routing --> protocol / request for comments to Abridges draft --> --> --> > Let me give my opinions interleaved. --> > By the way, as the Abridges draft we submitted last december is --> > somewhere between the current RBridges proposal and the --> IEEE Shortest --> > Path Bridging, we think it would help clarify to obtain --> comments to our --> > draft from the RBridges WG members. --> > Regards --> > Guillermo Ibanez --> > --> > --> > --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri --> dge-00.txt --> > --> > Guillermo Ibanez --> > --> > --> > Radia Perlman wrote: --> > --> >>Suping Zhai, --> >> --> >>You are not the first person to ask these questions. --> >>There is a lot of confusion over what is different --> between RSTP and STP, --> >>and what is different between RSTP and link state routing. --> >>I'll try to explain. --> >> --> >>1) What's the difference between RSTP and STP? --> >> --> >>RSTP and STP are almost identical, are compatible, --> >>and it would be less confusing to think of RSTP as a different --> >>version of the bridge spec than a different protocol. --> >> --> >>RSTP calculates the --> >>same spanning tree, and uses the same algorithm and even --> >>packet formats as STP. Both RSTP and STP calculate a tree --> of shortest paths --> >>from the Root bridge, which is the bridge with lowest ID/priority. --> >> --> >>The major difference between RSTP and STP --> >>is how they avoid temporary loops. --> >>STP did it with a timer. RSTP coordinates between neighbors --> >>to turn on links more quickly after topology changes. --> >> --> >>However, in either case, it is impossible to always avoid --> temporary --> >>loops...the simplest case is when a repeater comes up, or --> if too many --> >>spanning tree messages get lost due to congestion. --> >> --> >>So to summarize, both STP and RSTP use the same basic --> >>algorithm...the heart of algorithm is to calculate a tree --> >>of shortest paths from a single point. --> >>And the resulting tree and data packet --> >>forwarding path is the same in both (because it is the --> >>same algorithm). A single shared loop-free subset --> >>of the physical topology is calculated, upon which data --> packets are --> >>forwarded. --> >> --> >> --> >> --> >>2) What is the difference between RSTP and IS-IS? --> >> --> >>This is harder to answer than the difference between RSTP and STP, --> >>because IS-IS and spanning tree (RSTP/STP) are so very --> different from --> >>each other. IS-IS passes around topology --> >>information so that every RBridge calculates the shortest --> path between --> >>itself --> >>and each --> >>destination. With spanning tree (RSTP/STP) each bridge --> just knows which --> >>subset of its --> >>own ports are "in" or "out" of the spanning tree. If a --> link is not in --> >>the spanning tree, --> >>then it cannot be used, even if it is the shortest path --> between point A --> >>and B, and --> >>pairwise paths can be quite suboptimal. Furthermore, --> traffic is concentrated --> >>on the links in the spanning tree, because no traffic can --> be on links --> >>not in the --> >>spanning tree. --> >> --> >>Also spanning tree bridges learn, based on --> >>seeing data traffic, which --> >>direction the source is. (which of its own local ports lead to the --> >>source of --> >>the data packet). So packets must always arrive from a --> particular source --> >>from --> >>the same direction or else bridges will get confused. In --> contrast, with --> >>IS-IS, --> >>switches can do path splitting; using multiple paths to --> reach a destination. --> >> --> >> --> >> --> > It is important to remember that the standard convergence --> times of RSTP --> > are lower than those of routing protocols, unless --> specific measures for --> > milliseconds convergence are applied. --> > --> >>3) What is difference between RSTP and RBridge approach? --> >> --> >>RBridge incorporates --> >>a TTL into the header of forwarded data packets so a --> temporary loop is --> >>not really bad, so it need not --> >>be very conservative about avoiding loops. Also, --> >>a link state protocol (IS-IS) calculates shortest --> >>pair-wise paths. Also, it can calculate multiple paths to the --> >>destination, and do path splitting. --> >> --> >> --> > Both IEEE Shortest Path Bridging and the Abridges draft --> proposal ( see --> > --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri --> dge-00.txt) --> > obtain shortest paths. They do not allow path splitting, --> but are less --> > complex than IS-IS --> > and do not mix STP and IS-IS protocols in same area. --> > --> >>4) What is the difference between recent work in IEEE to calculate --> >>per-ingress trees, and RBridge approach? --> >> --> >>IEEE may indeed wind up doing the same thing as RBridge. --> Several years --> >>before TRILL I tried to get IEEE interested in doing this --> approach, --> >>but they were not interested, perhaps because I didn't explain it --> >>well enough. Now that work has started in IETF, I think --> it is possible --> >>that IEEE will converge on the same solution, which would actually --> >>be good for the industry. --> >>Radia --> >> --> >> --> > I do not see an easy convergence between IEEE and RBridge --> proposals --> > unless the two groups cooperate strongly. --> > IEEE will likely preserve basic RSTP mechanisms (fast --> convergence and --> > distance vector to (multiple) root bridges) with multiple --> spanning trees --> > (this is my guess, I do not follow their recent --> activities), while --> > RBridge uses IS-IS (link state mechanisms) as basic protocol. --> > --> > --> > Guillermo Ibanez --> > --> >>Suping Zhai wrote: --> >> --> >> --> >> --> >>>hi, --> >>>I am confronted with some questions when reading the --> Rbridge protocol related draft and hope someone can help me --> with details. --> >>>What's the essential difference between (R)STP and --> routing protocol(e.g. IS-IS)? --> >>>How dose the routing protocol(e.g. IS-IS) can optimize --> the routing path while (R)STP can't? --> >>>Can we optimize the (R)STP protocol itself to reach that --> goal? If that's the case, then I think that all RBridge WG --> works can be substituted. And I have seen some work been --> done in IEEE802.1aq which is on the way to the per bridge --> MSTP road. But what I imagine is that should we get a --> comparable simple and untangled solution for the bridge --> network routing path? --> >>> --> >>>TIA. --> >>> --> >>>Best Regards, --> >>>zhaisuping@huawei.com --> >>>Huawei Technologies Co., Ltd. --> >>>Tel: +86-10-82836882 --> >>>Fax: +86-10-82836020 --> >>>2006-02-23 --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>>--------------------------------------------------------- --> --------------- --> >>> --> >>>_______________________________________________ --> >>>rbridge mailing list --> >>>rbridge@postel.org --> >>>http://www.postel.org/mailman/listinfo/rbridge --> >>> --> >>> --> >>> --> >>> --> >> --> >> --> >> --> >>---------------------------------------------------------- --> -------------- --> >> --> >>_______________________________________________ --> >>rbridge mailing list --> >>rbridge@postel.org --> >>http://www.postel.org/mailman/listinfo/rbridge --> >> --> >> --> > --> > -- --> > Guillermo Ib??ez --> > Departamento de Ingenier?a Telem?tica --> > Universidad Carlos III de Madrid --> > 1.1.B.11 Colmenarejo 91-6241393 --> > 4.1.F.13 Legan?s 91-6248794 --> > --> > _______________________________________________ --> > rbridge mailing list --> > rbridge@postel.org --> > http://www.postel.org/mailman/listinfo/rbridge --> > --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1RJhIu28313 for <rbridge@postel.org>; Mon, 27 Feb 2006 11:43:19 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k1RJhAgL010402 for <rbridge@postel.org>; Mon, 27 Feb 2006 14:43:11 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18257 for <rbridge@postel.org>; Mon, 27 Feb 2006 14:43:10 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <FG7R5LFN>; Mon, 27 Feb 2006 14:43:09 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0DAC1737@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 27 Feb 2006 14:43:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k1RJhIu28313 Subject: Re: [rbridge] A question about (R)STP and routing protocol / requ est for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 27 Feb 2006 19:43:42 -0000 Status: RO Content-Length: 10514 Robey, I can't answer for Guilllermo's draft, but I can answer for (or comment on) the general case addressed by documents already chartered for the WG. Please see below... --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of robey --> Sent: Friday, February 24, 2006 10:53 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] A question about (R)STP and routing --> protocol / request for comments to Abridges draft --> --> Hi,Guillermo Ibanez, --> --> I have read through your Abridge draft, and think it --> provider a simpler method to achieve shortest path bridges . --> In terms of approaches presented in Abridge draft, when --> packets of one specific traffic destined to same --> destination arrived at edge bridge, if these packets are --> kind of unknown packets, they will be broadcasted on --> ingress tree, then after learing unicast path FDB entry --> for the flow, packets of the traffic will be forwarded on --> the engress tree, in this case it is possible to bring --> about misorder of frames related to the traffic. --> --> How can you solve this problem? Realistically speaking, several potential behaviors are not very likely. One example is the scenario where a lot of frames are sent to a host that has not yet been discovered on the network. Even in the case where this may occur, the degree to which small scale out of order delivery is pathological behavior with today's higher-level protocols is very small. Finally, because the ultimate unicast delivery path will be along the shortest path, the window of opportunity that may result in actual out of order delivery, in transition from flooding to simple delivery, is very small (especially if the traffic stream is a small fraction of link capacity). --> --> Maybe we can create symmetric tree, and still consider --> using ingress tree to forward broadcast/multicast/unknown --> packets and using egress tree to forward unicast packets, --> in this way not only can it overcome the above problem ,but --> also have a simpler method to create FDB entries and can --> avoid address learning (except foraddresses of end nodes) --> which can reduce traffic flooding when topology changes. How does use of symmetric trees impact on out of order delivery? --> --> Best regards --> --> robey --> --> --> --> --> From: "Guillermo Ib??ez" <gibanez@it.uc3m.es> --> To: "Developing a hybrid router/bridge." <rbridge@postel.org> --> Sent: Thursday, February 23, 2006 5:40 PM --> Subject: Re: [rbridge] A question about (R)STP and routing --> protocol / request for comments to Abridges draft --> --> --> > Let me give my opinions interleaved. --> > By the way, as the Abridges draft we submitted last december is --> > somewhere between the current RBridges proposal and the --> IEEE Shortest --> > Path Bridging, we think it would help clarify to obtain --> comments to our --> > draft from the RBridges WG members. --> > Regards --> > Guillermo Ibanez --> > --> > --> > --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri --> dge-00.txt --> > --> > Guillermo Ibanez --> > --> > --> > Radia Perlman wrote: --> > --> >>Suping Zhai, --> >> --> >>You are not the first person to ask these questions. --> >>There is a lot of confusion over what is different --> between RSTP and STP, --> >>and what is different between RSTP and link state routing. --> >>I'll try to explain. --> >> --> >>1) What's the difference between RSTP and STP? --> >> --> >>RSTP and STP are almost identical, are compatible, --> >>and it would be less confusing to think of RSTP as a different --> >>version of the bridge spec than a different protocol. --> >> --> >>RSTP calculates the --> >>same spanning tree, and uses the same algorithm and even --> >>packet formats as STP. Both RSTP and STP calculate a tree --> of shortest paths --> >>from the Root bridge, which is the bridge with lowest ID/priority. --> >> --> >>The major difference between RSTP and STP --> >>is how they avoid temporary loops. --> >>STP did it with a timer. RSTP coordinates between neighbors --> >>to turn on links more quickly after topology changes. --> >> --> >>However, in either case, it is impossible to always avoid --> temporary --> >>loops...the simplest case is when a repeater comes up, or --> if too many --> >>spanning tree messages get lost due to congestion. --> >> --> >>So to summarize, both STP and RSTP use the same basic --> >>algorithm...the heart of algorithm is to calculate a tree --> >>of shortest paths from a single point. --> >>And the resulting tree and data packet --> >>forwarding path is the same in both (because it is the --> >>same algorithm). A single shared loop-free subset --> >>of the physical topology is calculated, upon which data --> packets are --> >>forwarded. --> >> --> >> --> >> --> >>2) What is the difference between RSTP and IS-IS? --> >> --> >>This is harder to answer than the difference between RSTP and STP, --> >>because IS-IS and spanning tree (RSTP/STP) are so very --> different from --> >>each other. IS-IS passes around topology --> >>information so that every RBridge calculates the shortest --> path between --> >>itself --> >>and each --> >>destination. With spanning tree (RSTP/STP) each bridge --> just knows which --> >>subset of its --> >>own ports are "in" or "out" of the spanning tree. If a --> link is not in --> >>the spanning tree, --> >>then it cannot be used, even if it is the shortest path --> between point A --> >>and B, and --> >>pairwise paths can be quite suboptimal. Furthermore, --> traffic is concentrated --> >>on the links in the spanning tree, because no traffic can --> be on links --> >>not in the --> >>spanning tree. --> >> --> >>Also spanning tree bridges learn, based on --> >>seeing data traffic, which --> >>direction the source is. (which of its own local ports lead to the --> >>source of --> >>the data packet). So packets must always arrive from a --> particular source --> >>from --> >>the same direction or else bridges will get confused. In --> contrast, with --> >>IS-IS, --> >>switches can do path splitting; using multiple paths to --> reach a destination. --> >> --> >> --> >> --> > It is important to remember that the standard convergence --> times of RSTP --> > are lower than those of routing protocols, unless --> specific measures for --> > milliseconds convergence are applied. --> > --> >>3) What is difference between RSTP and RBridge approach? --> >> --> >>RBridge incorporates --> >>a TTL into the header of forwarded data packets so a --> temporary loop is --> >>not really bad, so it need not --> >>be very conservative about avoiding loops. Also, --> >>a link state protocol (IS-IS) calculates shortest --> >>pair-wise paths. Also, it can calculate multiple paths to the --> >>destination, and do path splitting. --> >> --> >> --> > Both IEEE Shortest Path Bridging and the Abridges draft --> proposal ( see --> > --> http://www.ietf.org/internet-drafts/draft-gibanez-trill-abri --> dge-00.txt) --> > obtain shortest paths. They do not allow path splitting, --> but are less --> > complex than IS-IS --> > and do not mix STP and IS-IS protocols in same area. --> > --> >>4) What is the difference between recent work in IEEE to calculate --> >>per-ingress trees, and RBridge approach? --> >> --> >>IEEE may indeed wind up doing the same thing as RBridge. --> Several years --> >>before TRILL I tried to get IEEE interested in doing this --> approach, --> >>but they were not interested, perhaps because I didn't explain it --> >>well enough. Now that work has started in IETF, I think --> it is possible --> >>that IEEE will converge on the same solution, which would actually --> >>be good for the industry. --> >>Radia --> >> --> >> --> > I do not see an easy convergence between IEEE and RBridge --> proposals --> > unless the two groups cooperate strongly. --> > IEEE will likely preserve basic RSTP mechanisms (fast --> convergence and --> > distance vector to (multiple) root bridges) with multiple --> spanning trees --> > (this is my guess, I do not follow their recent --> activities), while --> > RBridge uses IS-IS (link state mechanisms) as basic protocol. --> > --> > --> > Guillermo Ibanez --> > --> >>Suping Zhai wrote: --> >> --> >> --> >> --> >>>hi, --> >>>I am confronted with some questions when reading the --> Rbridge protocol related draft and hope someone can help me --> with details. --> >>>What's the essential difference between (R)STP and --> routing protocol(e.g. IS-IS)? --> >>>How dose the routing protocol(e.g. IS-IS) can optimize --> the routing path while (R)STP can't? --> >>>Can we optimize the (R)STP protocol itself to reach that --> goal? If that's the case, then I think that all RBridge WG --> works can be substituted. And I have seen some work been --> done in IEEE802.1aq which is on the way to the per bridge --> MSTP road. But what I imagine is that should we get a --> comparable simple and untangled solution for the bridge --> network routing path? --> >>> --> >>>TIA. --> >>> --> >>>Best Regards, --> >>>zhaisuping@huawei.com --> >>>Huawei Technologies Co., Ltd. --> >>>Tel: +86-10-82836882 --> >>>Fax: +86-10-82836020 --> >>>2006-02-23 --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>>--------------------------------------------------------- --> --------------- --> >>> --> >>>_______________________________________________ --> >>>rbridge mailing list --> >>>rbridge@postel.org --> >>>http://www.postel.org/mailman/listinfo/rbridge --> >>> --> >>> --> >>> --> >>> --> >> --> >> --> >> --> >>---------------------------------------------------------- --> -------------- --> >> --> >>_______________________________________________ --> >>rbridge mailing list --> >>rbridge@postel.org --> >>http://www.postel.org/mailman/listinfo/rbridge --> >> --> >> --> > --> > -- --> > Guillermo Ib??ez --> > Departamento de Ingenier?a Telem?tica --> > Universidad Carlos III de Madrid --> > 1.1.B.11 Colmenarejo 91-6241393 --> > 4.1.F.13 Legan?s 91-6248794 --> > --> > _______________________________________________ --> > rbridge mailing list --> > rbridge@postel.org --> > http://www.postel.org/mailman/listinfo/rbridge --> > --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1P3quu15923 for <rbridge@postel.org>; Fri, 24 Feb 2006 19:52:56 -0800 (PST) Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV800FTA4QKTA@lhrga01-in.huawei.com> for rbridge@postel.org; Sat, 25 Feb 2006 03:37:34 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV8009O05X8XO@szxga01-in.huawei.com> for rbridge@postel.org; Sat, 25 Feb 2006 12:03:09 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV800MZ45X8QH@szxga01-in.huawei.com> for rbridge@postel.org; Sat, 25 Feb 2006 12:03:08 +0800 (CST) Received: from y41566 ([10.70.77.89]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV800MBS66TQ9@szxml01-in.huawei.com> for rbridge@postel.org; Sat, 25 Feb 2006 12:08:53 +0800 (CST) Date: Sat, 25 Feb 2006 11:52:47 +0800 From: robey <robey@huawei.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <005001c639be$f0d04bb0$594d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=UTF-8 X-Priority: 3 X-MSMail-priority: Normal References: <0IV4006ZFDCCSM@szxml02-in.huawei.com> <43FD44E7.6060700@sun.com> <43FD82F2.7050407@it.uc3m.es> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: robey@huawei.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id k1P3quu15923 Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 25 Feb 2006 03:53:16 -0000 Status: RO Content-Length: 7982 Hi,Guillermo Ibanez, I have read through your Abridge draft, and think it provider a simpler method to achieve shortest path bridges . In terms of approaches presented in Abridge draft, when packets of one specific traffic destined to same destination arrived at edge bridge, if these packets are kind of unknown packets, they will be broadcasted on ingress tree, then after learing unicast path FDB entry for the flow, packets of the traffic will be forwarded on the engress tree, in this case it is possible to bring about misorder of frames related to the traffic.How can you solve this problem? Maybe we can create symmetric tree, and still consider using ingress tree to forward broadcast/multicast/unknown packets and using egress tree to forward unicast packets, in this way not only can it overcome the above problem ,but also have a simpler method to create FDB entries and can avoid address learning (except foraddresses of end nodes) which can reduce traffic flooding when topology changes. Best regards robey From: "Guillermo Ibáñez" <gibanez@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Sent: Thursday, February 23, 2006 5:40 PM Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft > Let me give my opinions interleaved. > By the way, as the Abridges draft we submitted last december is > somewhere between the current RBridges proposal and the IEEE Shortest > Path Bridging, we think it would help clarify to obtain comments to our > draft from the RBridges WG members. > Regards > Guillermo Ibanez > > > http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt > > Guillermo Ibanez > > > Radia Perlman wrote: > >>Suping Zhai, >> >>You are not the first person to ask these questions. >>There is a lot of confusion over what is different between RSTP and STP, >>and what is different between RSTP and link state routing. >>I'll try to explain. >> >>1) What's the difference between RSTP and STP? >> >>RSTP and STP are almost identical, are compatible, >>and it would be less confusing to think of RSTP as a different >>version of the bridge spec than a different protocol. >> >>RSTP calculates the >>same spanning tree, and uses the same algorithm and even >>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>from the Root bridge, which is the bridge with lowest ID/priority. >> >>The major difference between RSTP and STP >>is how they avoid temporary loops. >>STP did it with a timer. RSTP coordinates between neighbors >>to turn on links more quickly after topology changes. >> >>However, in either case, it is impossible to always avoid temporary >>loops...the simplest case is when a repeater comes up, or if too many >>spanning tree messages get lost due to congestion. >> >>So to summarize, both STP and RSTP use the same basic >>algorithm...the heart of algorithm is to calculate a tree >>of shortest paths from a single point. >>And the resulting tree and data packet >>forwarding path is the same in both (because it is the >>same algorithm). A single shared loop-free subset >>of the physical topology is calculated, upon which data packets are >>forwarded. >> >> >> >>2) What is the difference between RSTP and IS-IS? >> >>This is harder to answer than the difference between RSTP and STP, >>because IS-IS and spanning tree (RSTP/STP) are so very different from >>each other. IS-IS passes around topology >>information so that every RBridge calculates the shortest path between >>itself >>and each >>destination. With spanning tree (RSTP/STP) each bridge just knows which >>subset of its >>own ports are "in" or "out" of the spanning tree. If a link is not in >>the spanning tree, >>then it cannot be used, even if it is the shortest path between point A >>and B, and >>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>on the links in the spanning tree, because no traffic can be on links >>not in the >>spanning tree. >> >>Also spanning tree bridges learn, based on >>seeing data traffic, which >>direction the source is. (which of its own local ports lead to the >>source of >>the data packet). So packets must always arrive from a particular source >>from >>the same direction or else bridges will get confused. In contrast, with >>IS-IS, >>switches can do path splitting; using multiple paths to reach a destination. >> >> >> > It is important to remember that the standard convergence times of RSTP > are lower than those of routing protocols, unless specific measures for > milliseconds convergence are applied. > >>3) What is difference between RSTP and RBridge approach? >> >>RBridge incorporates >>a TTL into the header of forwarded data packets so a temporary loop is >>not really bad, so it need not >>be very conservative about avoiding loops. Also, >>a link state protocol (IS-IS) calculates shortest >>pair-wise paths. Also, it can calculate multiple paths to the >>destination, and do path splitting. >> >> > Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see > http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) > obtain shortest paths. They do not allow path splitting, but are less > complex than IS-IS > and do not mix STP and IS-IS protocols in same area. > >>4) What is the difference between recent work in IEEE to calculate >>per-ingress trees, and RBridge approach? >> >>IEEE may indeed wind up doing the same thing as RBridge. Several years >>before TRILL I tried to get IEEE interested in doing this approach, >>but they were not interested, perhaps because I didn't explain it >>well enough. Now that work has started in IETF, I think it is possible >>that IEEE will converge on the same solution, which would actually >>be good for the industry. >>Radia >> >> > I do not see an easy convergence between IEEE and RBridge proposals > unless the two groups cooperate strongly. > IEEE will likely preserve basic RSTP mechanisms (fast convergence and > distance vector to (multiple) root bridges) with multiple spanning trees > (this is my guess, I do not follow their recent activities), while > RBridge uses IS-IS (link state mechanisms) as basic protocol. > > > Guillermo Ibanez > >>Suping Zhai wrote: >> >> >> >>>hi, >>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>> >>>TIA. >>> >>>Best Regards, >>>zhaisuping@huawei.com >>>Huawei Technologies Co., Ltd. >>>Tel: +86-10-82836882 >>>Fax: +86-10-82836020 >>>2006-02-23 >>> >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> > > -- > Guillermo Ibáñez > Departamento de Ingeniería Telemática > Universidad Carlos III de Madrid > 1.1.B.11 Colmenarejo 91-6241393 > 4.1.F.13 Leganés 91-6248794 > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > Received: from huawei.com (lhrga01-in.huawei.com [57.66.76.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1O2amu06435 for <rbridge@postel.org>; Thu, 23 Feb 2006 18:36:49 -0800 (PST) Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600JDN6FBLF@lhrga01-in.huawei.com> for rbridge@postel.org; Fri, 24 Feb 2006 02:18:48 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV6000EK7LXXC@szxga01-in.huawei.com> for rbridge@postel.org; Fri, 24 Feb 2006 10:44:21 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600F2U7LWCY@szxga01-in.huawei.com> for rbridge@postel.org; Fri, 24 Feb 2006 10:44:21 +0800 (CST) Received: from z11024 ([10.111.12.75]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV600GC57PHLT@szxml02-in.huawei.com>; Fri, 24 Feb 2006 10:46:29 +0800 (CST) Date: Fri, 24 Feb 2006 10:34:01 +0800 From: Suping Zhai <zhaisuping@huawei.com> To: Radia Perlman <Radia.Perlman@sun.com>, "rbridge@postel.org" <rbridge@postel.org> Message-id: <0IV600GC77PHLT@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhaisuping@huawei.com Subject: Re: [rbridge] A question about (R)STP and routing protocol X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: zhaisuping@huawei.com, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 24 Feb 2006 02:38:03 -0000 Status: RO Content-Length: 8388 Hi Radia, Thank you at first for you response. See inline my further doubts. >This would be much clearer if I could make little ASCII drawings, but >tonight I'm tired. Maybe I'll >make a pdf drawing and send it to you if I can't explain in words. > >With spanning tree, there is only a single loop-free tree that is >calculated by all the bridges. >Let's say there is one link that is not selected to be in the spanning >tree, and it connects >B1 and B2. If B1 has a packet that needs to get sent to B2, it cannot >use the B1-B2 link, >since that link is not in the spanning tree. The spanning tree path >between any two points can >be quite bad because it is constrained not to use some links. In >contrast, the IS-IS path >can always choose the shortest path between any two points. > >As for whether RSTP/STP can be modified to calculate the same paths as >IS-IS...sure...in the >sense that anything can be modified to be anything else. But it really >would be completely doing >it a different way. The spanning tree algorithm is very different from >Dijkstra/link state routing. > >So, the spanning tree has ALL bridges calculate the SAME spanning >tree...the tree of shortest >paths from the Root bridge to all the other bridges. IS-IS has each >switch calclate a DIFFERENT >graph, which is the graph of shortest paths from that switch to each >destination. ANd I said "graph" >rather than "tree" because with IS-IS you can calculate multiple paths >to a destination. If you do >that (calculate multiple paths), then it's no longer a tree. [zsp]I go through some kinds of topology and use two kinds algorithms, that is using STP algorithm and Dijkstra seperately, and ultimately get the same tree or graph. So perhaps what I should ask is in what situation, with what topology there are different result forwarding tree when using above two mechanisms? Suping > >Even if bridges were modified somehow to calculate the same paths as >IS-IS, they would not >be able to do path splitting (i.e., multiple paths to the same >destination), because all traffic from S >must be received on the same port....by the nature of how bridges do >learning. > >If you do the modifications to achieve the same things as TRILL, you are >basically doing the TRILL >design....replacing spanning tree with link state Dijkstra, doing >endnode learning differently, and >then while you are at it, it would be a good idea to add a TTL to the >header so temporary loops >aren't a problem. > >Radia > >Suping Zhai wrote: > >>Radia, >>Thank you for your detail explanations. >>With the following 2) point, I am not yet clear enough and hope you can help me with that. >>What I think about IS-IS is that, IS-IS router uses the neighbour link state informations, using the Dijakson algorithm to calculate the shortest path to the DR(Designated Router). >>For the STP/RSTP(as I understand, they are almost the same regarding to the algorithm except for some convergence optimization), bridge also use the neighbour link state informations, using algorithm like Dijackson to calculate the tree path from the root bridge to every leaf bridge. >> >>So my question is, in what sense you can differ the result tree or routing path from the IS-IS and STP/RSTP? And are there any difference between the IS-IS and STP/RSTP with regard to the path calculation mechanisms? >>With that my last question is, if STP/RSTP can be optimized to get the same result with what the IS-IS has? >> >>With Kind Regards, >>Suping >> >> >> >>>Suping Zhai, >>> >>>You are not the first person to ask these questions. >>>There is a lot of confusion over what is different between RSTP and STP, >>>and what is different between RSTP and link state routing. >>>I'll try to explain. >>> >>>1) What's the difference between RSTP and STP? >>> >>>RSTP and STP are almost identical, are compatible, >>>and it would be less confusing to think of RSTP as a different >>>version of the bridge spec than a different protocol. >>> >>>RSTP calculates the >>>same spanning tree, and uses the same algorithm and even >>>packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >>> >>> >>>from the Root bridge, which is the bridge with lowest ID/priority. >> >> >>>The major difference between RSTP and STP >>>is how they avoid temporary loops. >>>STP did it with a timer. RSTP coordinates between neighbors >>>to turn on links more quickly after topology changes. >>> >>>However, in either case, it is impossible to always avoid temporary >>>loops...the simplest case is when a repeater comes up, or if too many >>>spanning tree messages get lost due to congestion. >>> >>>So to summarize, both STP and RSTP use the same basic >>>algorithm...the heart of algorithm is to calculate a tree >>>of shortest paths from a single point. >>>And the resulting tree and data packet >>>forwarding path is the same in both (because it is the >>>same algorithm). A single shared loop-free subset >>>of the physical topology is calculated, upon which data packets are >>>forwarded. >>> >>>2) What is the difference between RSTP and IS-IS? >>> >>>This is harder to answer than the difference between RSTP and STP, >>>because IS-IS and spanning tree (RSTP/STP) are so very different from >>>each other. IS-IS passes around topology >>>information so that every RBridge calculates the shortest path between >>>itself >>>and each >>>destination. With spanning tree (RSTP/STP) each bridge just knows which >>>subset of its >>>own ports are "in" or "out" of the spanning tree. If a link is not in >>>the spanning tree, >>>then it cannot be used, even if it is the shortest path between point A >>>and B, and >>>pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >>>on the links in the spanning tree, because no traffic can be on links >>>not in the >>>spanning tree. >>> >>>Also spanning tree bridges learn, based on >>>seeing data traffic, which >>>direction the source is. (which of its own local ports lead to the >>>source of >>>the data packet). So packets must always arrive from a particular source >>>from >>>the same direction or else bridges will get confused. In contrast, with >>>IS-IS, >>>switches can do path splitting; using multiple paths to reach a destination. >>> >>>3) What is difference between RSTP and RBridge approach? >>> >>>RBridge incorporates >>>a TTL into the header of forwarded data packets so a temporary loop is >>>not really bad, so it need not >>>be very conservative about avoiding loops. Also, >>>a link state protocol (IS-IS) calculates shortest >>>pair-wise paths. Also, it can calculate multiple paths to the >>>destination, and do path splitting. >>> >>>4) What is the difference between recent work in IEEE to calculate >>>per-ingress trees, and RBridge approach? >>> >>>IEEE may indeed wind up doing the same thing as RBridge. Several years >>>before TRILL I tried to get IEEE interested in doing this approach, >>>but they were not interested, perhaps because I didn't explain it >>>well enough. Now that work has started in IETF, I think it is possible >>>that IEEE will converge on the same solution, which would actually >>>be good for the industry. >>> >>>Radia >>> >>> >>>Suping Zhai wrote: >>> >>> >>> >>>>hi, >>>>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>>>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>>>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>>>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >>>> >>>>TIA. >>>> >>>>Best Regards, >>>>zhaisuping@huawei.com >>>>Huawei Technologies Co., Ltd. >>>>Tel: +86-10-82836882 >>>>Fax: +86-10-82836020 >>>>2006-02-23 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>_______________________________________________ >>>>rbridge mailing list >>>>rbridge@postel.org >>>>http://www.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >> >> >> >> Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1N9eCu00138 for <rbridge@postel.org>; Thu, 23 Feb 2006 01:40:12 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38739A3479 for <rbridge@postel.org>; Thu, 23 Feb 2006 10:40:02 +0100 (CET) Received: from [163.117.203.119] (unknown [163.117.203.119]) by smtp01.uc3m.es (Postfix) with ESMTP id 9AC2BA33E8 for <rbridge@postel.org>; Thu, 23 Feb 2006 10:40:00 +0100 (CET) Message-ID: <43FD82F2.7050407@it.uc3m.es> Date: Thu, 23 Feb 2006 10:40:02 +0100 From: =?UTF-8?B?R3VpbGxlcm1vIEliw6HDsWV6?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <0IV4006ZFDCCSM@szxml02-in.huawei.com> <43FD44E7.6060700@sun.com> In-Reply-To: <43FD44E7.6060700@sun.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] A question about (R)STP and routing protocol / request for comments to Abridges draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 23 Feb 2006 09:42:07 -0000 Status: RO Content-Length: 6316 Let me give my opinions interleaved. By the way, as the Abridges draft we submitted last december is somewhere between the current RBridges proposal and the IEEE Shortest Path Bridging, we think it would help clarify to obtain comments to our draft from the RBridges WG members. Regards Guillermo Ibanez http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt Guillermo Ibanez Radia Perlman wrote: >Suping Zhai, > >You are not the first person to ask these questions. >There is a lot of confusion over what is different between RSTP and STP, >and what is different between RSTP and link state routing. >I'll try to explain. > >1) What's the difference between RSTP and STP? > >RSTP and STP are almost identical, are compatible, >and it would be less confusing to think of RSTP as a different >version of the bridge spec than a different protocol. > >RSTP calculates the >same spanning tree, and uses the same algorithm and even >packet formats as STP. Both RSTP and STP calculate a tree of shortest paths >from the Root bridge, which is the bridge with lowest ID/priority. > >The major difference between RSTP and STP >is how they avoid temporary loops. >STP did it with a timer. RSTP coordinates between neighbors >to turn on links more quickly after topology changes. > >However, in either case, it is impossible to always avoid temporary >loops...the simplest case is when a repeater comes up, or if too many >spanning tree messages get lost due to congestion. > >So to summarize, both STP and RSTP use the same basic >algorithm...the heart of algorithm is to calculate a tree >of shortest paths from a single point. >And the resulting tree and data packet >forwarding path is the same in both (because it is the >same algorithm). A single shared loop-free subset >of the physical topology is calculated, upon which data packets are >forwarded. > > > >2) What is the difference between RSTP and IS-IS? > >This is harder to answer than the difference between RSTP and STP, >because IS-IS and spanning tree (RSTP/STP) are so very different from >each other. IS-IS passes around topology >information so that every RBridge calculates the shortest path between >itself >and each >destination. With spanning tree (RSTP/STP) each bridge just knows which >subset of its >own ports are "in" or "out" of the spanning tree. If a link is not in >the spanning tree, >then it cannot be used, even if it is the shortest path between point A >and B, and >pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated >on the links in the spanning tree, because no traffic can be on links >not in the >spanning tree. > >Also spanning tree bridges learn, based on >seeing data traffic, which >direction the source is. (which of its own local ports lead to the >source of >the data packet). So packets must always arrive from a particular source >from >the same direction or else bridges will get confused. In contrast, with >IS-IS, >switches can do path splitting; using multiple paths to reach a destination. > > > It is important to remember that the standard convergence times of RSTP are lower than those of routing protocols, unless specific measures for milliseconds convergence are applied. >3) What is difference between RSTP and RBridge approach? > >RBridge incorporates >a TTL into the header of forwarded data packets so a temporary loop is >not really bad, so it need not >be very conservative about avoiding loops. Also, >a link state protocol (IS-IS) calculates shortest >pair-wise paths. Also, it can calculate multiple paths to the >destination, and do path splitting. > > Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt) obtain shortest paths. They do not allow path splitting, but are less complex than IS-IS and do not mix STP and IS-IS protocols in same area. >4) What is the difference between recent work in IEEE to calculate >per-ingress trees, and RBridge approach? > >IEEE may indeed wind up doing the same thing as RBridge. Several years >before TRILL I tried to get IEEE interested in doing this approach, >but they were not interested, perhaps because I didn't explain it >well enough. Now that work has started in IETF, I think it is possible >that IEEE will converge on the same solution, which would actually >be good for the industry. >Radia > > I do not see an easy convergence between IEEE and RBridge proposals unless the two groups cooperate strongly. IEEE will likely preserve basic RSTP mechanisms (fast convergence and distance vector to (multiple) root bridges) with multiple spanning trees (this is my guess, I do not follow their recent activities), while RBridge uses IS-IS (link state mechanisms) as basic protocol. Guillermo Ibanez >Suping Zhai wrote: > > > >>hi, >>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? >> >>TIA. >> >>Best Regards, >>zhaisuping@huawei.com >>Huawei Technologies Co., Ltd. >>Tel: +86-10-82836882 >>Fax: +86-10-82836020 >>2006-02-23 >> >> >> >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge >> >> >> >> > > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > -- Guillermo Ibáñez Departamento de Ingeniería Telemática Universidad Carlos III de Madrid 1.1.B.11 Colmenarejo 91-6241393 4.1.F.13 Leganés 91-6248794 Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1N5FWu16765 for <rbridge@postel.org>; Wed, 22 Feb 2006 21:15:32 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IV400FG9JXI0L00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 22 Feb 2006 21:15:18 -0800 (PST) Received: from sun.com ([129.150.20.98]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IV400KENJXDAT10@mail.sunlabs.com> for rbridge@postel.org; Wed, 22 Feb 2006 21:15:16 -0800 (PST) Date: Wed, 22 Feb 2006 21:15:19 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <0IV4006ZFDCCSM@szxml02-in.huawei.com> To: zhaisuping@huawei.com, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43FD44E7.6060700@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <0IV4006ZFDCCSM@szxml02-in.huawei.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] A question about (R)STP and routing protocol X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 23 Feb 2006 05:16:12 -0000 Status: RO Content-Length: 4479 Suping Zhai, You are not the first person to ask these questions. There is a lot of confusion over what is different between RSTP and STP, and what is different between RSTP and link state routing. I'll try to explain. 1) What's the difference between RSTP and STP? RSTP and STP are almost identical, are compatible, and it would be less confusing to think of RSTP as a different version of the bridge spec than a different protocol. RSTP calculates the same spanning tree, and uses the same algorithm and even packet formats as STP. Both RSTP and STP calculate a tree of shortest paths from the Root bridge, which is the bridge with lowest ID/priority. The major difference between RSTP and STP is how they avoid temporary loops. STP did it with a timer. RSTP coordinates between neighbors to turn on links more quickly after topology changes. However, in either case, it is impossible to always avoid temporary loops...the simplest case is when a repeater comes up, or if too many spanning tree messages get lost due to congestion. So to summarize, both STP and RSTP use the same basic algorithm...the heart of algorithm is to calculate a tree of shortest paths from a single point. And the resulting tree and data packet forwarding path is the same in both (because it is the same algorithm). A single shared loop-free subset of the physical topology is calculated, upon which data packets are forwarded. 2) What is the difference between RSTP and IS-IS? This is harder to answer than the difference between RSTP and STP, because IS-IS and spanning tree (RSTP/STP) are so very different from each other. IS-IS passes around topology information so that every RBridge calculates the shortest path between itself and each destination. With spanning tree (RSTP/STP) each bridge just knows which subset of its own ports are "in" or "out" of the spanning tree. If a link is not in the spanning tree, then it cannot be used, even if it is the shortest path between point A and B, and pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated on the links in the spanning tree, because no traffic can be on links not in the spanning tree. Also spanning tree bridges learn, based on seeing data traffic, which direction the source is. (which of its own local ports lead to the source of the data packet). So packets must always arrive from a particular source from the same direction or else bridges will get confused. In contrast, with IS-IS, switches can do path splitting; using multiple paths to reach a destination. 3) What is difference between RSTP and RBridge approach? RBridge incorporates a TTL into the header of forwarded data packets so a temporary loop is not really bad, so it need not be very conservative about avoiding loops. Also, a link state protocol (IS-IS) calculates shortest pair-wise paths. Also, it can calculate multiple paths to the destination, and do path splitting. 4) What is the difference between recent work in IEEE to calculate per-ingress trees, and RBridge approach? IEEE may indeed wind up doing the same thing as RBridge. Several years before TRILL I tried to get IEEE interested in doing this approach, but they were not interested, perhaps because I didn't explain it well enough. Now that work has started in IETF, I think it is possible that IEEE will converge on the same solution, which would actually be good for the industry. Radia Suping Zhai wrote: >hi, >I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. >What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? >How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? >Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? > >TIA. > >Best Regards, >zhaisuping@huawei.com >Huawei Technologies Co., Ltd. >Tel: +86-10-82836882 >Fax: +86-10-82836020 >2006-02-23 > > > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1N34Su09534 for <rbridge@postel.org>; Wed, 22 Feb 2006 19:04:29 -0800 (PST) Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV400CUXD9U0N@usaga01-in.huawei.com> for rbridge@postel.org; Wed, 22 Feb 2006 18:51:30 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV400631E02DK@szxga02-in.huawei.com> for rbridge@postel.org; Thu, 23 Feb 2006 11:07:14 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV4003YXDZYHW@szxga02-in.huawei.com> for rbridge@postel.org; Thu, 23 Feb 2006 11:07:14 +0800 (CST) Received: from z11024 ([10.111.12.75]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV4006ZCDCCSM@szxml02-in.huawei.com>; Thu, 23 Feb 2006 10:53:01 +0800 (CST) Date: Thu, 23 Feb 2006 10:40:33 +0800 From: Suping Zhai <zhaisuping@huawei.com> To: Radia Perlman <Radia.Perlman@Sun.COM>, "rbridge@postel.org" <rbridge@postel.org> Message-id: <0IV4006ZFDCCSM@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhaisuping@huawei.com Subject: [rbridge] A question about (R)STP and routing protocol X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: zhaisuping@huawei.com, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 23 Feb 2006 03:04:45 -0000 Status: RO Content-Length: 800 hi, I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details. What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path? TIA. Best Regards, zhaisuping@huawei.com Huawei Technologies Co., Ltd. Tel: +86-10-82836882 Fax: +86-10-82836020 2006-02-23 Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1ICQis11332 for <rbridge@postel.org>; Sat, 18 Feb 2006 04:26:44 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 31F40A316F for <rbridge@postel.org>; Sat, 18 Feb 2006 13:26:38 +0100 (CET) Received: from [163.117.203.150] (unknown [163.117.203.150]) by smtp01.uc3m.es (Postfix) with ESMTP id 52002A317A for <rbridge@postel.org>; Sat, 18 Feb 2006 13:26:37 +0100 (CET) Message-ID: <43F7127E.9090803@it.uc3m.es> Date: Sat, 18 Feb 2006 13:26:38 +0100 From: =?windows-1252?Q?Guillermo_Ib=E1=F1ez?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <3B141581359DE54092847AF2FC15328A015E7165@ex1.corp.fabric7.com> In-Reply-To: <3B141581359DE54092847AF2FC15328A015E7165@ex1.corp.fabric7.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] VLAN and learning questions X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 18 Feb 2006 12:26:54 -0000 Status: RO Content-Length: 1936 Regarding 2, this is also called dual-MAC learning, as used in Global Open Ethernet and others. I agree it is an efficient mechanism although for big networks the ARP broadcast may not be acceptable. Regards Guillermo Jianlin Zeng wrote: > Hi, > > I?ve studied the document draft-perlman-trill-rbridge-protocol-00.txt > and have the following questions/suggestions: > > 1. Should the VLAN tag be carried on the outer header only? Legacy > bridges needs the VLAN tag from outer header if the frame is not > received from the default VLAN of the ingress port. RBridge can > always derive VLAN of the received frame based on VLAN tag in > the outer header or default port VLAN if the tag is not there. > 2. Regarding learning of end node information, would the action of > having designated RBridges to query/learn end node information > and broadcast to every RBridges consume too much bandwidth and > processing power? This requires huge network and processing > resources as network gets bigger. For deployments that don?t > require ARP/ND proxy, each RBridge can learn the (Designated > RBridge address, end node address) information directly from the > SA in the outer header and SA in the inner header. This doesn?t > need extra broadcasting packets and can be implemented in the > hardware. An aging mechanism similar to legacy bridges can be > implemented by each RBridge to keep the end node information > database fresh enough. > > Thanks, > > Jianlin > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > -- Guillermo Ib??ez Departamento de Ingenier?a Telem?tica Universidad Carlos III de Madrid 1.1.B.11 Colmenarejo 91-6241393 4.1.F.13 Legan?s 91-6248794 Received: from corp.fabric7.com (ext-103.mv.fabric7.com [68.120.107.103]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1I0x6s27319 for <rbridge@postel.org>; Fri, 17 Feb 2006 16:59:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Feb 2006 16:59:06 -0800 Message-ID: <3B141581359DE54092847AF2FC15328A015E7166@ex1.corp.fabric7.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Endnode learning from data packets vs from link stateinformation Thread-Index: AcY0GtV8MGpH92sFT6qaDYPCI9lg9AABv0KQ From: "Jianlin Zeng" <jzeng@fabric7.com> To: <Radia.Perlman@Sun.COM>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jzeng@fabric7.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k1I0x6s27319 Subject: Re: [rbridge] Endnode learning from data packets vs from link stateinformation X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 18 Feb 2006 01:00:01 -0000 Status: RO Content-Length: 4360 Hi Radia, Thanks for the answer. As you pointed out, it's a tradeoff to pick which direction and go with it. The biggest advantages of RBridge as you described in the draft is shortest paths forwarding with TTL vs STP. This along is already a huge improvement over current layer 2 networks. If the draft can define a base that can achieve this goal and is scalable and simple to implement, it will be much easier to be adopted by current switch vendors. The fancy features like ARP/ND proxy/mix link types etc can be defined as optional add-on features to make RBridge even more attractive. Jianlin -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Friday, February 17, 2006 3:12 PM To: Developing a hybrid router/bridge. Subject: [rbridge] Endnode learning from data packets vs from link stateinformation Jianlin Zeng, Both really good questions. I prefer (when I'm reading email threads) to have only one technical topic in each thread, so I took the liberty of changing the subject line and in this reply, only asking about endnode learning. It is an interesting variant, as you propose, to not bother broadcasting endnode information in link state information, and only figure it out from encapsulated data packets. However, for most data packets, only the "egress RBridge" is in the shim header, not the "ingress RBridge". As you point out though, if we have the source address in the OUTER header be the ingress RBridge's MAC address, then RBridges can do the mapping of ("ingress RBridge MAC address, endnode MAC address"). Currently, the internet draft specifies that in the outer header, the SA is the transmitting RBridge, so the SA in the outer header would change at each hop. There are a couple of worries I'd have about using original RBridge as the SA in the outer header rather than the transmitting RBridge on that hop. a) Might it confuse bridge learning if they see the MAC address of the original RBridge coming from different directions? Maybe this wouldn't be a problem because the destination address in the outer header would always be one local to that bridged link. b) IS-IS uses a single 6-byte ID for the RBridge, whereas it might have multiple MAC addresses. I suppose we could add information into the LSP to indicate "variant MAC addresses", since IS-IS would, without us adding that field, only tell us how to reach the system ID of the destination RBridge. c) I was thinking about potentially mixing link types at some point in the future, and I think it would be easier to do this if the outer header was link-specific, so this would allow RBridge encapsulated packets to traverse some mythical kind of link, with say, 4 byte addresses. If we were to do something like that, we wouldn't be able to put in the original RBridge MAC address into the SA of that type of header. There might be more issues, but it would be interesting to look at the tradeoffs. I'm not sure whether it's going to be easy to definitely decide this, so this might be one of those cases where we should just pick one direction and run with it. Radia > 2. Regarding learning of end node information, would the action of > having designated RBridges to query/learn end node information and > broadcast to every RBridges consume too much bandwidth and > processing power? This requires huge network and processing > resources as network gets bigger. For deployments that don't > require ARP/ND proxy, each RBridge can learn the (Designated > RBridge address, end node address) information directly from the > SA in the outer header and SA in the inner header. This doesn't > need extra broadcasting packets and can be implemented in the > hardware. An aging mechanism similar to legacy bridges can be > implemented by each RBridge to keep the end node information > database fresh enough. > > > > Thanks, > > Jianlin > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1HNCFs24475 for <rbridge@postel.org>; Fri, 17 Feb 2006 15:12:15 -0800 (PST) Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1HNBDdS013979 for <rbridge@postel.org>; Fri, 17 Feb 2006 15:12:15 -0800 (PST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IUU00901TR599@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Fri, 17 Feb 2006 18:12:12 -0500 (EST) Received: from Sun.COM (sr1-umpk-17.SFBay.Sun.COM [129.146.11.199]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IUU00LP8TS8SV@bur-mail2.east.sun.com> for rbridge@postel.org; Fri, 17 Feb 2006 18:12:12 -0500 (EST) Date: Fri, 17 Feb 2006 15:12:07 -0800 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <3B141581359DE54092847AF2FC15328A015E7165@ex1.corp.fabric7.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43F65847.9050408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <3B141581359DE54092847AF2FC15328A015E7165@ex1.corp.fabric7.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by boreas.isi.edu id k1HNCFs24475 Subject: [rbridge] Endnode learning from data packets vs from link state information X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Radia.Perlman@Sun.COM, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 17 Feb 2006 23:13:33 -0000 Status: RO Content-Length: 3331 Jianlin Zeng, Both really good questions. I prefer (when I'm reading email threads) to have only one technical topic in each thread, so I took the liberty of changing the subject line and in this reply, only asking about endnode learning. It is an interesting variant, as you propose, to not bother broadcasting endnode information in link state information, and only figure it out from encapsulated data packets. However, for most data packets, only the "egress RBridge" is in the shim header, not the "ingress RBridge". As you point out though, if we have the source address in the OUTER header be the ingress RBridge's MAC address, then RBridges can do the mapping of ("ingress RBridge MAC address, endnode MAC address"). Currently, the internet draft specifies that in the outer header, the SA is the transmitting RBridge, so the SA in the outer header would change at each hop. There are a couple of worries I'd have about using original RBridge as the SA in the outer header rather than the transmitting RBridge on that hop. a) Might it confuse bridge learning if they see the MAC address of the original RBridge coming from different directions? Maybe this wouldn't be a problem because the destination address in the outer header would always be one local to that bridged link. b) IS-IS uses a single 6-byte ID for the RBridge, whereas it might have multiple MAC addresses. I suppose we could add information into the LSP to indicate "variant MAC addresses", since IS-IS would, without us adding that field, only tell us how to reach the system ID of the destination RBridge. c) I was thinking about potentially mixing link types at some point in the future, and I think it would be easier to do this if the outer header was link-specific, so this would allow RBridge encapsulated packets to traverse some mythical kind of link, with say, 4 byte addresses. If we were to do something like that, we wouldn't be able to put in the original RBridge MAC address into the SA of that type of header. There might be more issues, but it would be interesting to look at the tradeoffs. I'm not sure whether it's going to be easy to definitely decide this, so this might be one of those cases where we should just pick one direction and run with it. Radia > 2. Regarding learning of end node information, would the action of > having designated RBridges to query/learn end node information and > broadcast to every RBridges consume too much bandwidth and > processing power? This requires huge network and processing > resources as network gets bigger. For deployments that don?t > require ARP/ND proxy, each RBridge can learn the (Designated > RBridge address, end node address) information directly from the > SA in the outer header and SA in the inner header. This doesn?t > need extra broadcasting packets and can be implemented in the > hardware. An aging mechanism similar to legacy bridges can be > implemented by each RBridge to keep the end node information > database fresh enough. > > > > Thanks, > > Jianlin > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge Received: from corp.fabric7.com (ext-103.mv.fabric7.com [68.120.107.103]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1HML4s07255 for <rbridge@postel.org>; Fri, 17 Feb 2006 14:21:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63410.6F2FA1B3" Date: Fri, 17 Feb 2006 14:21:01 -0800 Message-ID: <3B141581359DE54092847AF2FC15328A015E7165@ex1.corp.fabric7.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VLAN and learning questions Thread-Index: AcY0EG9ZnegOHK7LSLuNf5OKtAMwrg== From: "Jianlin Zeng" <jzeng@fabric7.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jzeng@fabric7.com Subject: [rbridge] VLAN and learning questions X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 17 Feb 2006 22:21:55 -0000 Status: RO Content-Length: 4819 This is a multi-part message in MIME format. ------_=_NextPart_001_01C63410.6F2FA1B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I've studied the document draft-perlman-trill-rbridge-protocol-00.txt and have the following questions/suggestions: =20 1. Should the VLAN tag be carried on the outer header only? Legacy bridges needs the VLAN tag from outer header if the frame is not received from the default VLAN of the ingress port. RBridge can always derive VLAN of the received frame based on VLAN tag in the outer header or default port VLAN if the tag is not there. 2. Regarding learning of end node information, would the action of having designated RBridges to query/learn end node information and broadcast to every RBridges consume too much bandwidth and processing power? This requires huge network and processing resources as network gets bigger. For deployments that don't require ARP/ND proxy, each RBridge can learn the (Designated RBridge address, end node address) information directly from the SA in the outer header and SA in the inner header. This doesn't need extra broadcasting packets and can be implemented in the hardware. An aging mechanism similar to legacy bridges can be implemented by each RBridge to keep the end node information database fresh enough. =20 Thanks, Jianlin ------_=_NextPart_001_01C63410.6F2FA1B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)"> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hi,</span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'> </span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>I’ve studied the document = draft-perlman-trill-rbridge-protocol-00.txt and have the following questions/suggestions:</span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'> </span></font></p> <ol start=3D1 type=3D1> <li class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Should the VLAN tag be carried on the outer = header only? Legacy bridges needs the VLAN tag from outer header if the = frame is not received from the default VLAN of the ingress port. RBridge can = always derive VLAN of the received frame based on VLAN tag in the outer = header or default port VLAN if the tag is not there.</span></font></li> <li class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Regarding learning of end node information, = would the action of having designated RBridges to query/learn end node = information and broadcast to every RBridges consume too much bandwidth and = processing power? This requires huge network and processing resources as = network gets bigger. For deployments that don’t require ARP/ND proxy, each = RBridge can learn the (Designated RBridge address, end node address) = information directly from the SA in the outer header and SA in the inner = header. This doesn’t need extra broadcasting packets and can be = implemented in the hardware. An aging mechanism similar to legacy bridges can be implemented by each RBridge to keep the end node information = database fresh enough.</span></font></li> </ol> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'> </span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Thanks,</span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Jianlin</span></font></p> </div> </body> </html> ------_=_NextPart_001_01C63410.6F2FA1B3-- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1DJ72427809; Mon, 13 Feb 2006 11:07:02 -0800 (PST) Message-ID: <43F0D8DD.4010904@isi.edu> Date: Mon, 13 Feb 2006 11:07:09 -0800 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [rbridge] rbridge protocol docment now available X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 13 Feb 2006 19:08:08 -0000 Status: RO Content-Length: 1710 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, The following document has been submitted as an individual I-D. We would like to offer it as a WG document, as per discussions in Vancouver. It is currently available at: http://www.postel.org/rbridge/draft-perlman-trill-rbridge-protocol-00.txt It should appear in the usual I-D places shortly as well. Joe and Radia - --- TRILL Working Group R. Perlman Internet Draft Sun Expires: August 2006 J. Touch USC/ISI February 13, 2006 Rbridges: Base Protocol Specification draft-perlman-trill-rbridge-protocol-00.txt ... Abstract RBridges provide the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. The design allows for zero configuration of switches within a campus, optimal pair-wise routing, safe forwarding even during periods of temporary loops, and the ability to cut down on ARP/ND traffic. The design also supports VLANs, and allows forwarding tables to be based on RBridge destinations (rather than endnode destinations), which allows internal routing tables to be substantially smaller than in conventional bridge systems. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8NjdE5f5cImnZrsRAgeAAJwKYmzhzbkPsuUnYL0WpSIvDly5OgCgim20 rLo+2U1Zmo5nmjky5C+UPbk= =A2xh -----END PGP SIGNATURE----- Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1A5sf409636 for <rbridge@postel.org>; Thu, 9 Feb 2006 21:54:43 -0800 (PST) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1A69NL5010275 for <rbridge@postel.org>; Thu, 9 Feb 2006 23:09:23 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k1A690O1027303 for <rbridge@postel.org>; Fri, 10 Feb 2006 00:09:00 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <DPBJKD80>; Fri, 10 Feb 2006 00:54:35 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810CA94D2D@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> To: "TRILL <rbridge@postel.org>" <rbridge@postel.org> Date: Fri, 10 Feb 2006 00:54:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Subject: [rbridge] Call for items for the March meeting agenda X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 10 Feb 2006 05:55:23 -0000 Status: RO Content-Length: 451 Hi, Erik and I are starting to work on the agenda for the March meeting. Our major documents are obvious items but we welcome other suggestions for topics or presentations. Thanks, Donald ========================================================= Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories +1-508-786-7554 (work) 111 Locke Drive +1-508-634-2066 (home) Marlboro, MA 01752 USA Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k14KTd624923 for <rbridge@postel.org>; Sat, 4 Feb 2006 12:29:39 -0800 (PST) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k14KiG1E011858 for <rbridge@postel.org>; Sat, 4 Feb 2006 13:44:16 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k14KhmAL026934 for <rbridge@postel.org>; Sat, 4 Feb 2006 14:43:48 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <DPBJJD43>; Sat, 4 Feb 2006 15:29:37 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810C937F9F@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Date: Sat, 4 Feb 2006 15:29:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 04 Feb 2006 20:30:17 -0000 Status: RO Content-Length: 431 Thanks, Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Thursday, February 02, 2006 11:20 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair Welcome aboard! Joe _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k148Dd623967 for <rbridge@postel.org>; Sat, 4 Feb 2006 00:13:39 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8F7D983AED for <rbridge@postel.org>; Sat, 4 Feb 2006 09:13:33 +0100 (CET) Received: from [163.117.203.121] (unknown [163.117.203.121]) by smtp03.uc3m.es (Postfix) with ESMTP id 9000D83730 for <rbridge@postel.org>; Sat, 4 Feb 2006 09:13:32 +0100 (CET) Message-ID: <43E4622C.5010100@it.uc3m.es> Date: Sat, 04 Feb 2006 09:13:32 +0100 From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <gibanez@it.uc3m.es> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <62173B970AE0A044AED8723C3BCF23810C80E485@ma19exm01.e6.bcs.mot.com> <43E2D9E4.9090609@isi.edu> <43E3B1D0.2020705@sun.com> In-Reply-To: <43E3B1D0.2020705@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] Where do VLAN tags go in forwarded frames? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 04 Feb 2006 08:14:23 -0000 Status: RO Content-Length: 1873 Just following the line of thought of Radia and thinking aloud... On one hand, duplicating the VLAN tag is an additional complexity and not fully justified. On the other hand, if restrictions on the difusion of frames are required, the duplication of VLAN tag will be required, specially if standard bridges must also limit the difusion of unknown destinations and multicasts. If VLAN tag is duplicated, the objection is then that complexity introduced is something closet to MAC in MAC encapsulation plus VLAN stacking plus IS-IS, just for a campus network. Guillermo Radia Perlman wrote: >How do RBridges know a packet is for a particular VLAN? For originating >frames, it would be the same as for bridges, i.e., sometimes the endnode >fills it in, sometimes a bridge between the RBridge and the endnode fills >it in, and sometimes the RBridge fills it in. (I assume bridges today >are configured as to whether they should add VLAN tags for untagged packets >from a particular link?) > >However, for packets in transit between RBridges, is there any reason >to duplicate the VLAN tag into the outer header? (review...the original >frame is "inside", then there's a shim header with ingress/egress RBridge >and TTL, and an "outer" Ethernet header with Ethertype >"RBridge-forwarded frame".) >It doesn't seem necessary for correctness, but it might be more convenient >for RBridge forwarding (only for unknown destinations and multicasts) >if they didn't need to look inside at the inner header to find out if >the scope of delivery is just to a VLAN. > >Radia > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > > -- Guillermo Ib??ez Departamento de Ingenier?a Telem?tica Universidad Carlos III de Madrid 1.1.B.11 Colmenarejo 91-6241393 4.1.F.13 Legan?s 91-6248794 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k13L62626181 for <rbridge@postel.org>; Fri, 3 Feb 2006 13:06:03 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k13L5qgx015281; Fri, 3 Feb 2006 16:05:56 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13789; Fri, 3 Feb 2006 16:05:52 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <DC3CLHL8>; Fri, 3 Feb 2006 16:05:51 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0DAC167A@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Radia Perlman'" <Radia.Perlman@sun.com> Date: Fri, 3 Feb 2006 16:05:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] Where do VLAN tags go in forwarded frames? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 03 Feb 2006 21:06:42 -0000 Status: RO Content-Length: 3937 Radia, Please see below... -- Eric --> --> How do RBridges know a packet is for a particular VLAN? --> Without going into the details (most people won't really want to hear them, and those who might can find them in appropriate 802.## specifications), there is a code point in the basic Ethernet/802.3 header to determine which (of several) encapsulations applies to this frame. If the code point indicates it is VLAN tagged, then the forwarding device may look at the appropriate offset to determine which VLAN this frame applies to. --> --> For originating frames, it would be the same as for bridges, --> i.e., sometimes the endnode fills it in, sometimes a bridge --> between the RBridge and the endnode fills it in, and sometimes --> the RBridge fills it in. (I assume bridges today are configured --> as to whether they should add VLAN tags for untagged packets --> from a particular link?) --> There is a concept of "port-based" VLANs - in which the port to VLAN information is (typically) configured. If frames are received on such a port, and the forwarding device determines that they need to be forwarded on one or more ports that use VLAN-tagged frames (to allow support of multiple VLANs on the port), the receiving port-to-VLAN information is used to map the frame encapsulation for a transmitting (forwarding) port. This may done on a port by port basis, but it is typically the case that a single VLAN is identified by a common tag on all ports for any individual device (thus allowing for identical VLAN-tagged encapsulation to be used). Forwarding from port-based VLAN port to port-based VLAN port (where both are mapped to the same VLAN context), or from VLAN-tagged port to VLAN-tagged port (where the mappings of VLAN tag values are the same) - requires no special forwarding or encapuslation activities. --> --> However, for packets in transit between RBridges, is there any --> reason to duplicate the VLAN tag into the outer header? --> (review...the original frame is "inside", then there's a shim --> header with ingress/egress RBridge and TTL, and an "outer" --> Ethernet header with Ethertype "RBridge-forwarded frame".) --> This depends on whether this additional level of multiplexing is required to support the number of potential encapsulations required. In the MPLS label encapsulated approach proposed at the last meeting, this might not be required. We could - for example - use different labels associated with the same egress to de- multiplex different VLAN contexts. Given that this would allow for intermediate RBridges to easily distinguish forwarding on a VLAN basis, using a single field look-up, this might be highly desirable (and probably should be considered, if it is not already). Also it is not necessary that an outer VLAN tag mapping would be on a one-to-one basis with the innner VLAN tag in any case - unless this was desired in order to reduce requirements for configuration. --> --> It doesn't seem necessary for correctness, but it might be more --> convenient for RBridge forwarding (only for unknown destinations --> and multicasts) if they didn't need to look inside at the inner --> header to find out if the scope of delivery is just to a VLAN. --> It would be a matter of using one off-set verses another, as long as a two field look-up is required in any case. The real issue is whether or not it is appropriate to assume "correct" format using well understood off-set values is guaranteed in RBridge forwarded frames. As long as formatting is reasonably consistent (having a smallish number of possible, easily distinguishable, formats), it should not matter whether you look N bits into the frame or N+M bits into the frame to find a VLAN tag. --> --> Radia --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k13JfC626929 for <rbridge@postel.org>; Fri, 3 Feb 2006 11:41:12 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IU40040AMOG3S00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 03 Feb 2006 11:41:04 -0800 (PST) Received: from sun.com ([129.150.20.210]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IU40050NMOF1S00@mail.sunlabs.com> for rbridge@postel.org; Fri, 03 Feb 2006 11:41:04 -0800 (PST) Date: Fri, 03 Feb 2006 11:41:04 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <43E2D9E4.9090609@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43E3B1D0.2020705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <62173B970AE0A044AED8723C3BCF23810C80E485@ma19exm01.e6.bcs.mot.com> <43E2D9E4.9090609@isi.edu> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Where do VLAN tags go in forwarded frames? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 03 Feb 2006 19:42:13 -0000 Status: RO Content-Length: 955 How do RBridges know a packet is for a particular VLAN? For originating frames, it would be the same as for bridges, i.e., sometimes the endnode fills it in, sometimes a bridge between the RBridge and the endnode fills it in, and sometimes the RBridge fills it in. (I assume bridges today are configured as to whether they should add VLAN tags for untagged packets from a particular link?) However, for packets in transit between RBridges, is there any reason to duplicate the VLAN tag into the outer header? (review...the original frame is "inside", then there's a shim header with ingress/egress RBridge and TTL, and an "outer" Ethernet header with Ethertype "RBridge-forwarded frame".) It doesn't seem necessary for correctness, but it might be more convenient for RBridge forwarding (only for unknown destinations and multicasts) if they didn't need to look inside at the inner header to find out if the scope of delivery is just to a VLAN. Radia Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k134KB604395 for <rbridge@postel.org>; Thu, 2 Feb 2006 20:20:11 -0800 (PST) Received: from [128.9.176.132] (ras32.isi.edu [128.9.176.132]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k134Jsq05416; Thu, 2 Feb 2006 20:19:54 -0800 (PST) Message-ID: <43E2D9E4.9090609@isi.edu> Date: Thu, 02 Feb 2006 20:19:48 -0800 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <62173B970AE0A044AED8723C3BCF23810C80E485@ma19exm01.e6.bcs.mot.com> In-Reply-To: <62173B970AE0A044AED8723C3BCF23810C80E485@ma19exm01.e6.bcs.mot.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0DFC1878EEC0DF2EEAB09E86" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 03 Feb 2006 04:21:07 -0000 Status: RO Content-Length: 722 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0DFC1878EEC0DF2EEAB09E86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Welcome aboard! Joe --------------enig0DFC1878EEC0DF2EEAB09E86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD4tnkE5f5cImnZrsRAm6sAJ43NoHMc8Q1oLKf1pMGRqc0AkqjAgCgp4HV iMdE2jQlCoefr8vayqbrOVQ= =wfMN -----END PGP SIGNATURE----- --------------enig0DFC1878EEC0DF2EEAB09E86-- Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k128mI624437 for <rbridge@postel.org>; Thu, 2 Feb 2006 00:48:19 -0800 (PST) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k128lv2J031585; Thu, 2 Feb 2006 09:47:58 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k128lv3k015632; Thu, 2 Feb 2006 09:47:57 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 09:47:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 2 Feb 2006 09:47:54 +0100 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CF06A@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Unnecessary flooding through ST Thread-Index: AcYnedCc+5H2Sxf6QfelwK/lbVOpKAAWvhpQ From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org>, "Wojtek Paprowicz" <quasarus@gazeta.pl> X-OriginalArrivalTime: 02 Feb 2006 08:47:54.0879 (UTC) FILETIME=[5BD438F0:01C627D5] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rute.sofia@siemens.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k128mI624437 Subject: Re: [rbridge] Unnecessary flooding through ST X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 02 Feb 2006 08:49:00 -0000 Status: RO Content-Length: 1904 Hello, > --> I know of no reason why this would not also happen if we > --> were to replace RBridges with IS-IS routers. > > After thinking a little further about this, I must conclude > that the last sentence above is not correct, as stated and > without further amplification. > > I thought it made a good "short answer", but it does not. > > Strictly speaking, the statement might be true for flooding > between RBridges. Even in this limited sense, however, the > amount of flooding required would be much less, since the > exposure to L2 addresses would be limited to the addresses > of the local IS-IS routers on any single shared media. > > In terms of flooding into the network via egress RBridges, > clearly this would not happen if the RBridge was replaced > by an IS-IS router. > > Consequently, notwithstanding the potential mitigation > techniques and factors, the extent of flooding in the case > pointed out by Wojtek Paprowicz could be much worse than > would be the case without the interactions between bridge > learning, STP and the SPF computation. > > That is, if there was an additonal delay in "learning" as > a result of requiring a new SPF computation. > Wojtek is indeed speaking of the last case you are mentioning, i.e., besides IS-IS, you still have the flooding performed in the ST. It is a fact that IS-IS has to be tuned and that anyway the spfdelay timer may give rise to the same problems. But the problem here is indeed allowing Rbridges to try to get info about destinations in two ways 1) on demand as usual, by means of the ST; 2) without requesting, by means of IS-IS. This makes things worse. This is in fact what Rbridges for now describes as a concept and is a potential source of problems for convergence. You mentioned that some people are working on ways to reduce the need for flooding. Can you please point out some sources? Regards, Rute Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k11LYb603528 for <rbridge@postel.org>; Wed, 1 Feb 2006 13:34:37 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k11LYPgx013775; Wed, 1 Feb 2006 16:34:25 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19171; Wed, 1 Feb 2006 16:34:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <DC3C23J0>; Wed, 1 Feb 2006 16:34:24 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0C8863EF@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Wojtek Paprowicz'" <quasarus@gazeta.pl> Date: Wed, 1 Feb 2006 16:34:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] Unnecessary flooding through ST X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Feb 2006 21:34:56 -0000 Status: RO Content-Length: 4693 One correction, below (sorry for the lengthy discussion)... --- [SNIP] --- --> --> The process of exchanging LSPs takes very little time. --> --> However, if Rbridge A received another frame addressed --> --> to host B it will flood it again because the SPF --> --> computation didn't take place yet. spfDelay typically --> --> takes 5s (but can be tuned). Does this mean that during --> --> that time any transmission from host A to host B in the --> --> provided scenario will be carried by means of the ST? --> --> --> --> There are schemes for reducing the impact of flooding for --> unknown destinations. For example, some bridges may limit --> the periodicity for flooding to each unknown destination. --> --> There are problems with doing this in certain corner cases --> and it should not be a required behavior, so cases will --> arise in which continuous flooding will happen. --> --> However, there are some natural limiting factors where some --> higher layer protocol is involved - depending on the need --> for HostB to eventually ACK at the higher layer for frames --> it receives from HostA. Consequently, HostA will - at some --> point - stop sending frames to HostB until is has received --> something from HostB in return. --> --> There may be some very small delay between the time that --> HostA starts getting replies from HostB, and the time when --> RBridgeA receives (and acts on) an update from RBridgeB. --> During that time, some degree of flooding may continue. --> --> I know of no reason why this would not also happen if we --> were to replace RBridges with IS-IS routers. After thinking a little further about this, I must conclude that the last sentence above is not correct, as stated and without further amplification. I thought it made a good "short answer", but it does not. Strictly speaking, the statement might be true for flooding between RBridges. Even in this limited sense, however, the amount of flooding required would be much less, since the exposure to L2 addresses would be limited to the addresses of the local IS-IS routers on any single shared media. In terms of flooding into the network via egress RBridges, clearly this would not happen if the RBridge was replaced by an IS-IS router. Consequently, notwithstanding the potential mitigation techniques and factors, the extent of flooding in the case pointed out by Wojtek Paprowicz could be much worse than would be the case without the interactions between bridge learning, STP and the SPF computation. That is, if there was an additonal delay in "learning" as a result of requiring a new SPF computation. My understanding of how we will use SPF routing in general, however, is that an SPF computation should not be required for addition of new destination reachability information, as long as the SPF computation to the egress RBridge has previously been completed (and we have not also received an indication that inter-RBridge topology has changed). Instead, the new entry would simply be added as a "learned" destination associated with a specific egress RBridge for which a shortest path has already been determined. Consequently, an SPF computation would only be required if it has not previously been done for the egress from which ingress RBridges have "learned" a new destination address. The question then gets back to how likely is this scenario and - assuming it is likely enough to be a problem - does it make sense to do something about it (e.g. - use a shorter delay value) in computing an SPF for "learned" destinations? Since, in the worst case, an SPF computation might not have been completed for the specific egress RBridge from which a new destination was learned, other RBridges (that might need to forward frames toward that egress) would either have to perform that computation very quickly, or would flood frames associated with that (and possibly many other) destination(s) throughout the entire broadcast domain. As that should happen - at most - one time for each egress RBridge, this does end up making the likelihood that it may happen comparable (within the RBridge campus) to what it would be if RBridges were replaced with routers. The potential for longer term flooding throughout the entire broadcast domain, however, argues that SPF computations MUST be performed each time a new RBridge is discovered and that - at least initially - flooding may need to be inhibited until shortest paths have been computed to all known RBridges. In addition, it may be necessary to always inhibit flooding (via the IRT) whenever a new RBridge is discovered. But that is a matter for further study... --> --- [SNIP] --- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k11Idi629576 for <rbridge@postel.org>; Wed, 1 Feb 2006 10:39:45 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k11Ic5gx008470; Wed, 1 Feb 2006 13:38:05 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21923; Wed, 1 Feb 2006 13:38:05 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <DC3C2GSH>; Wed, 1 Feb 2006 13:38:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0C8863E9@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Wojtek Paprowicz'" <quasarus@gazeta.pl> Date: Wed, 1 Feb 2006 13:38:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] Unnecessary flooding through ST X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Feb 2006 18:39:57 -0000 Status: RO Content-Length: 5621 Wojtek Paprowicz, These are good points you bring up. --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Wojtek Paprowicz --> Sent: Wednesday, February 01, 2006 9:15 AM --> To: rbridge@postel.org --> Subject: [rbridge] Unnecessary flooding through ST --> --> Hello, --> --> I would like to ask all of you a question which is very --> important to me. Basically, Rbridges run IS-IS but not --> only. They use spanning tree (ST) for, among others, --> broadcast transmission. --> In order to avoid potential confusion, we are trying to use the term "Ingress RBridge Tree" as opposed to "Spanning Tree" in this case. This tree would be used for flooding, broadcast and possibly layer 2 multicast (at least as a default mode). --> However, ST they use is calculated based on the information --> stored LSP database. As far as I know, in IS-IS, we have --> spfDelay timer which determines the minimum time between --> the start of two consecutive SPF computations. Let's assume --> a network below: --> --> HostA <> RbridgeA <> RbridgeB <> HostB --> --> Rbridge A received a frame from a host A to unknown --> destination (let's assume that host B just attached --> to the network). --> This example is somewhat unusual because HostA has to at least suspect that HostB is attached to the network or it would not be sending frames to it. However a similar scenario might arise by moving HostB - from, for example, a third port on RBridgeA to the port on RBridgeB to which you show it attached above. In this case, however, frames addressed to HostB will - in the worst case - be unicast routed to the "old location" until such time as either HostB is rediscovered at the "new location" or the existing RBridge table entries for HostB are "aged out". Even in this case, it is extremely unlikely both HostA and HostB would be unknown. --> --> The receiving Rbridge A floods the frame by means of --> the ST but also exchanges the information about the --> sending host if it was also unknown. As host B just --> attached it will be recognized by Rbridge B very soon. --> Rbridge B will generate LSP to inform others of a new --> host. Rbridge A receives this LSP with the info on --> host B inside and updates its LSP database. --> This seems correct, assuming both hosts are unknown. --> The process of exchanging LSPs takes very little time. --> However, if Rbridge A received another frame addressed --> to host B it will flood it again because the SPF --> computation didn't take place yet. spfDelay typically --> takes 5s (but can be tuned). Does this mean that during --> that time any transmission from host A to host B in the --> provided scenario will be carried by means of the ST? --> There are schemes for reducing the impact of flooding for unknown destinations. For example, some bridges may limit the periodicity for flooding to each unknown destination. There are problems with doing this in certain corner cases and it should not be a required behavior, so cases will arise in which continuous flooding will happen. However, there are some natural limiting factors where some higher layer protocol is involved - depending on the need for HostB to eventually ACK at the higher layer for frames it receives from HostA. Consequently, HostA will - at some point - stop sending frames to HostB until is has received something from HostB in return. There may be some very small delay between the time that HostA starts getting replies from HostB, and the time when RBridgeA receives (and acts on) an update from RBridgeB. During that time, some degree of flooding may continue. I know of no reason why this would not also happen if we were to replace RBridges with IS-IS routers. --> --> In other words, Rbridge A will be flooding the network --> with frames from host A to host B for maximum 5s or less, --> if the spfDelay timer was triggered earlier, till it re- --> computes its routing and forwarding table. --> It may turn out that we can work with a smaller value for a delay timer in computing shortest paths. Also, as a mitigating factor, it is worth noting that the use of an SPF routing protocol will ensure that all RBridges (at least within a common VLAN context) are updated at about the same time when any new destination is learned by any of those same RBridges. This means that it is not necessary for each of N-1 RBridges to flood at least one frame for all destinations "discovered" at an Nth RBridge - assuming full connectivity among N RBridges. Consequently, this should result in less flooding in densely connected RBridge topologies. Finally, some people within the working group are working to define optimizations that will further reduce the need for flooding, as well as potentially reduce the use of the entire IRT (Ingress RBridge Tree) in the multicast case. --> --> I will be very thankful for your explanation on that. --> Please forgive me if I have misunderstood some aspects --> of Rbridges and troubled you unnecessarily. --> --> ------------------------ --> With kind regards, --> --> Wojtek Paprowicz --> student of the University of Science and Technology AGH --> Cracow, Poland --> ------------------------ --> --> --> -- --> Wysokie Obroty Magazyn - nowy miesiecznik motoryzacyjny. --> Pierwszy numer juz w sprzedazy. --> Wiecej informacji na: http://auto.gazeta.pl/auto/0,0.html --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from imail1.gazeta.pl (imail1.gazeta.pl [193.42.231.143]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k11EFQ628314 for <rbridge@postel.org>; Wed, 1 Feb 2006 06:15:26 -0800 (PST) Received: from poczta.gazeta.pl (unverified [193.42.231.60]) by (imail1.gazeta.pl) with ESMTP id 14099515 for <rbridge@postel.org>; Wed, 01 Feb 2006 15:14:49 +0300 Received: from PENTA (unverified [83.18.187.6]) by mailic01.gazeta.pl (mailic01.gazeta.pl) with ESMTP id 15945538 for <rbridge@postel.org>; Wed, 01 Feb 2006 15:14:44 +0100 Date: Wed, 1 Feb 2006 15:14:43 +0100 From: Wojtek Paprowicz <quasarus@gazeta.pl> X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <117684448.20060201151443@gazeta.pl> To: rbridge@postel.org In-Reply-To: <62173B970AE0A044AED8723C3BCF23810C80E485@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF23810C80E485@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NotAscii: charset=us-ascii X-IP-stats: Incoming Outgoing Last 0, First 97, in=5539588, out=1, spam=0 Known=true X-External-IP: 193.42.231.60 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: quasarus@gazeta.pl Subject: [rbridge] Unnecessary flooding through ST X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Wojtek Paprowicz <quasarus@gazeta.pl>, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Feb 2006 14:16:08 -0000 Status: RO Content-Length: 2030 Hello, I would like to ask all of you a question which is very important to me. Basically, Rbridges run IS-IS but not only. They use spanning tree (ST) for, among others, broadcast transmission. However, ST they use is calculated based on the information stored LSP database. As far as I know, in IS-IS, we have spfDelay timer which determines the minimum time between the start of two consecutive SPF computations. Let's assume a network below: HostA <> RbridgeA <> RbridgeB <> HostB Rbridge A received a frame from a host A to unknown destination (let's assume that host B just attached to the network). The receiving Rbridge A floods the frame by means of the ST but also exchnages the information about the sending host if it was also unknown. As host B just attached it will be recognized by Rbridge B very soon. Rbridge B will generate LSP to inform others of a new host. Rbridge A receives this LSP with the info on host B inside and updates its LSP database. The process of exchanging LSPs takes very little time. However, if Rbridge A received another frame addressed to host B it will flood it again because the SPF computation didn't take place yet. spfDelay typically takes 5s (but can be tuned). Does this mean that during that time any transmission from host A to host B in the provided scenario will be carried by means of the ST? In other words, Rbridge A will be flooding the network with frames from host A to host B for maximum 5s or less, if the spfDelay timer was triggered earlier, till it re-computes its routing and forwarding table. I will be very thankful for your explanation on that. Please forgive me if I have misunderstood some aspects of Rbridges and troubled you unnecessarily. ------------------------ With kind regards, Wojtek Paprowicz student of the University of Science and Technology AGH Cracow, Poland ------------------------ -- Wysokie Obroty Magazyn - nowy miesiecznik motoryzacyjny. Pierwszy numer juz w sprzedazy. Wiecej informacji na: http://auto.gazeta.pl/auto/0,0.html
- [rbridge] A question about (R)STP and routing pro… Suping Zhai
- [rbridge] A question about (R)STP and routing pro… Radia Perlman
- [rbridge] A question about (R)STP and routing pro… Guillermo Ibáñez
- [rbridge] A question about (R)STP and routing pro… Suping Zhai
- [rbridge] A question about (R)STP and routing pro… robey
- [rbridge] A question about (R)STP and routing pro… Guillermo Ibáñez
- [rbridge] A question about (R)STP and routing pro… robey