[rbridge] Plea for references (Re: How should...)
gibanez at it.uc3m.es ( Guillermo Ibáñez ) Fri, 28 October 2005 10:40 UTC
From: "gibanez at it.uc3m.es"
Date: Fri, 28 Oct 2005 12:40:22 +0200
Subject: [rbridge] Plea for references (Re: How should...)
In-Reply-To: <7D69B9A3DC2340F65D7AC5D3@B50854F0A9192E8EC6CDA126>
References: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> <7D69B9A3DC2340F65D7AC5D3@B50854F0A9192E8EC6CDA126>
Message-ID: <43620016.4050406@it.uc3m.es>
Harald Tveit Alvestrand wrote: > > > --On 26. oktober 2005 07:06 -0700 Vishwas Manral <Vishwas at sinett.com> > wrote: > >> >> Hi Guillermo, >> >> One address you may have missed out is the Pause Frame address >> 01-80-C2-00-00-01. >> >> Besides I am not sure but addresses 01-80-C2-00-00-00 to >> 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 >> devices). >> > > one prayer from us less clued-in to the specifications: > could people try to mention "chapter and verse" of the IEEE > specifications when they come up with these nuggets of information? > (IEEE 802.1D-2004, 7.12.3) Guillermo > It helps those of us who are still learning figure out which documents > we have to read for which context.... > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge at 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 j9SAeSL08130 for <rbridge@postel.org>; Fri, 28 Oct 2005 03:40:28 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 737B983BD6 for <rbridge@postel.org>; Fri, 28 Oct 2005 12:40:22 +0200 (CEST) Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id A43A583BC3 for <rbridge@postel.org>; Fri, 28 Oct 2005 12:40:21 +0200 (CEST) Message-ID: <43620016.4050406@it.uc3m.es> Date: Fri, 28 Oct 2005 12:40:22 +0200 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: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> <7D69B9A3DC2340F65D7AC5D3@B50854F0A9192E8EC6CDA126> In-Reply-To: <7D69B9A3DC2340F65D7AC5D3@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] Plea for references (Re: How should...) 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, 28 Oct 2005 10:40:56 -0000 Status: RO Content-Length: 955 Harald Tveit Alvestrand wrote: > > > --On 26. oktober 2005 07:06 -0700 Vishwas Manral <Vishwas@sinett.com> > wrote: > >> >> Hi Guillermo, >> >> One address you may have missed out is the Pause Frame address >> 01-80-C2-00-00-01. >> >> Besides I am not sure but addresses 01-80-C2-00-00-00 to >> 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 >> devices). >> > > one prayer from us less clued-in to the specifications: > could people try to mention "chapter and verse" of the IEEE > specifications when they come up with these nuggets of information? > (IEEE 802.1D-2004, 7.12.3) Guillermo > It helps those of us who are still learning figure out which documents > we have to read for which context.... > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S9IrL17286 for <rbridge@postel.org>; Fri, 28 Oct 2005 02:18:53 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A568258085 for <rbridge@postel.org>; Fri, 28 Oct 2005 11:18:11 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25593-01 for <rbridge@postel.org>; Fri, 28 Oct 2005 11:18:07 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 369C92596C4 for <rbridge@postel.org>; Fri, 28 Oct 2005 11:17:57 +0200 (CEST) Date: Fri, 28 Oct 2005 05:26:30 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <7D69B9A3DC2340F65D7AC5D3@B50854F0A9192E8EC6CDA126> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> References: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========A77A90DAA87DA9E4F41A==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: [rbridge] Plea for references (Re: How should...) 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, 28 Oct 2005 09:18:55 -0000 Status: RO Content-Length: 1158 --==========A77A90DAA87DA9E4F41A========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 26. oktober 2005 07:06 -0700 Vishwas Manral <Vishwas@sinett.com> = wrote: > > Hi Guillermo, > > One address you may have missed out is the Pause Frame address > 01-80-C2-00-00-01. > > Besides I am not sure but addresses 01-80-C2-00-00-00 to > 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 = devices). > one prayer from us less clued-in to the specifications: could people try to mention "chapter and verse" of the IEEE specifications=20 when they come up with these nuggets of information? It helps those of us who are still learning figure out which documents we=20 have to read for which context.... --==========A77A90DAA87DA9E4F41A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD4DBQFDYZpmOMj+2+WY0F4RAiORAKDYu/lj+cgNsUYbR0hxQJfIXxOmSQCVGZ2m 6N1RQ8iW00Fv1SLmllgOLg== =eoW0 -----END PGP SIGNATURE----- --==========A77A90DAA87DA9E4F41A==========-- 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 j9S99ZL14530 for <rbridge@postel.org>; Fri, 28 Oct 2005 02:09:36 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A32AC83B4A for <rbridge@postel.org>; Fri, 28 Oct 2005 11:09:29 +0200 (CEST) Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id DB4C87D47D for <rbridge@postel.org>; Fri, 28 Oct 2005 11:09:28 +0200 (CEST) Message-ID: <4361EAC9.3070807@it.uc3m.es> Date: Fri, 28 Oct 2005 11:09:29 +0200 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: [rbridge] Subcase for RBridges? 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, 28 Oct 2005 09:09:57 -0000 Status: RO Content-Length: 1499 I have a question regarding next-hop destination RBridge addressing. It could be avoided whitin campus cores. One objection that can be made to RBridges and other proposals that keep compatibility with bridged islands is that the double-encapsulated frame is addressed to next-hop RBridge instead of to destination RBridge. This is necessary as, if not, the frame could be duplicated by intermediate RBridges that receive copies of the frame. As in some cases it is foreseable that RBridges will form the core of the campus network due to their advantages regarding segmentation, links usage, etc, I wonder whether it is worth to consider the subcase of confined RBridges whithin a core area formed by RBridges linked by point to point links. Point to point links are an standard requirement for RSTP protocol (required for fast convergence) and common practice in campus networks by performance and security reasons. Ports of RBridges linked to RBridges ( core ports) execute RBridges protocol with double encapsulation and ports connected to standard bridges islands (sbridge ports) act as the "B1" standard bridge as proposed by Radia for RBridge/Bridge optional implementation. Assuming an scenario like this, RBridges might address directly the encapsulated frame to destination RBridge and only the TTL field would need to be changed at each RBridge. It is not the general and standard scenario, but it could be in practice quite common, given their advantages. Guillermo Received: from smtp.ya.com (smtp02.ya.com [62.151.11.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9QEIQL21151 for <rbridge@postel.org>; Wed, 26 Oct 2005 07:18:26 -0700 (PDT) Received: from [80.37.137.39] (helo=[10.0.0.4]) by smtp.ya.com with esmtp id 1EUm6W-00027s-00 for rbridge@postel.org; Wed, 26 Oct 2005 16:18:12 +0200 Message-ID: <435F9022.8080709@it.uc3m.es> Date: Wed, 26 Oct 2005 16:18:10 +0200 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: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> 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] How should RBridges recognize spanning tree messages? 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, 26 Oct 2005 14:18:30 -0000 Status: RO Content-Length: 3757 Vishwas Manral wrote: >Hi Guillermo, > >One address you may have missed out is the Pause Frame address 01-80-C2-00-00-01. > > > Right. I did not try to be exhaustive. Pause are for full duplex control, link local. >Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 devices). > > So do I. Guillermo >Thanks, >Vishwas >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Guillermo Ib??ez >Sent: Wednesday, October 26, 2005 6:44 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] How should RBridges recognize spanning tree messages? > >See below current related addresses and usage according *my >interpretation* of bridges standard: > >Radia Perlman wrote: > > > >>Another interesting question....exactly how should an RBridge recognize >>a BPDU in order to >>discard it? If I remember correctly, the layer 2 multicast address used >>for BPDUs (including >>"topology change notifications") is only used for bridge messages. If >>that's true, then >>is that the criteria RBridges should use, i.e., discard any messages >>sent to that layer 2 >>multicast address? >> >> >> >> >> > >Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting >BPDUs (they are confined by bridges to same LAN segment). Bridges DO NOT >forward these frames. Neither should RBridges ! >It seems that any messages to that address should be discarded because >even bridges do not forward them (they process them). >However, I would recommend to ask the IEEE. > > > >>It's conceivable that there is some management thing that might be sent >>to "all bridges". >> >> >> >I see this in the standard: >All LANs Bridge Management group address : 01-80-C2-00-00-10. I think >they should be forwarded. > > > >>that case, it's possible we'd want such messages forwarded across the >>RBridges, and treated >>like other layer 2 multicasts within what I was calling the "campus". Or >>a case could be >>made that such a message should go only to the bridged island, just as >>such messages would >>not be forwarded through routers. >> >> >> >> >> >I think that not forwarding multicast addresses by RBridges should be >exceptional. The bridged domain should be kept manageable at campus >level without fragmentation. in bridged islands. > > > >>But if that layer 2 address is only used for spanning tree (including >>topology change notifications), >>then it's safe for RBridges to look no further than the layer 2 >>destination address, in terms >>of what should be discarded. >> >> >> >> >> >It seems safe (asking the IEEE). > > > >>If not (if that layer 2 address is used both for spanning tree messages >>which RBridges should >>discard, and for other messages that RBridges should forward), then we >>should specify >>which fields other than the layer 2 header destination address that >>RBridges would need to >>look at in order to know what to discard. >> >> >> >> >> >If no confirmation from IEEE regarding Bridge Group Address usage, it >might be safer if RBridges look also at the protocol ID (0). >Guillermo > > > >>Radia >> >> >> >> >> >> >Other addresses: >GMRP group address : 01-80-C2-00-00-20 (used by GARP PDUs) . >GVRP group address: 01-80-C2-00-00-21 (used by GARP PDUs). >I did not follow the multicast discusion entirely so I am not aware of >the position regarding this. Bridges that do not support GMRP or GVRP >forward these frames. Bridges that support terminate and process them. > > > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > > Received: from smtp.ya.com (smtp04.ya.com [62.151.11.162]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9QE9CL18356 for <rbridge@postel.org>; Wed, 26 Oct 2005 07:09:13 -0700 (PDT) Received: from [80.37.137.39] (helo=[10.0.0.4]) by smtp.ya.com with esmtp id 1EUlxm-00016c-00 for rbridge@postel.org; Wed, 26 Oct 2005 16:09:11 +0200 Message-ID: <435F8DFC.40603@it.uc3m.es> Date: Wed, 26 Oct 2005 16:09:00 +0200 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: <313680C9A886D511A06000204840E1CF0C886017@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C886017@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 26 Oct 2005 14:09:28 -0000 Status: RO Content-Length: 10858 OK GI Gray, Eric wrote: >Guillermo, > > Thanks! By the way, it is not absolutely necessary >to give explicit directions on how to insert or modify the >text you propose. Trust me, I probably can get the intent >right, once I've seen proposed text and minor corrections >on the mailing list... :-) > >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Guillermo Ib??ez >--> Sent: Wednesday, October 26, 2005 2:43 AM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> Radia Perlman wrote: >--> >--> > No objection to inclusion of the text proposed by >--> Guillermo, as long >--> > as it's clear it's not mandatory for all RBridges to >--> > be combined bridge/RBridges. >--> > >--> > >--> OK. Add this sentence explicitly: "It is not mandatory for >--> RBridges be >--> combined bridge/RBridges". >--> Guillermo >--> >--> > >--> > Guillermo Ib??ez wrote: >--> > >--> >>Eric, Radia : >--> >> >--> >>I have use Radia?s text as much as possible to describe >--> it as a first >--> >>proposal and added a final sentence on the default value >--> for RBridges. >--> >>Feel free to correct english expressions. >--> >>Guillermo >--> >> >--> >> >--> >>RBridge indirect participation in bridged island spanning tree. >--> >>--------------------------------------------------------------- >--> >>RBridges by default do not participate in spanning tree >--> in other way than ignoring received BPDUs. It is an >--> objective of RBridge specification to be independent of >--> bridges specifications as much as possible. >--> >> However it may be convenient for RBridges in some >--> circumstances to participate in the spanning tree and >--> contend to be root bridge of the spanning tree formed in >--> the bridged island they are attached to. In these cases it >--> is possible to build a device that's logically the same as >--> a bridge glued onto an RBridge. The following schema applies: >--> >> >--> >> ?-----------? >--> >> bridged island-----B1----RB1 ? >--> >> ?-----------? >--> >> >--> >> RBridge/bridge box >--> >> >--> >>where B1 is a bridge with two ports...a pt-to-pt link to >--> RBRidge RB1, and a link to the bridged LAN. The "RB1" >--> portion of this box acts as an standard RBridge, it neither >--> forwards, nor initiates spanning tree messages. The "B1" >--> portion acts as two-port standard 802.1D bridge, and does >--> participate in spanning tree. Its priority for root >--> election can be set in the standard way. To minimize >--> configurafion, it may be convenient in some implementations >--> to make the standard B1 bridge priority a function of the >--> configurable RBridge priority for IS-IS Designated RBridge >--> election. In this way Designated RBridge will participate >--> and contend (as B1) to be elected also as root bridge of >--> the bridged island and only one priority configuration is required. >--> >> >--> >>In environments using such implementations, if the >--> default bridge priority for B1 is lower than standard >--> bridges priority, RBridges/bridges like B1 will become >--> roots of their bridged islands, contending only with other >--> RBridges connected to same island for root election. >--> >> >--> >> >--> >> >--> >> >--> >> >--> >> >--> >>Gray, Eric wrote: >--> >> >--> >> >--> >> >--> >>>I think we should leave that sort of determination to the >--> >>>supposed wisdom of the successful implementer. But I won't >--> >>>object to text along these lines if someone else wants to >--> >>>write it... >--> >>> >--> >>>-- >--> >>>Eric >--> >>> >--> >>>--> -----Original Message----- >--> >>>--> From: rbridge-bounces@postel.org >--> >>>--> [mailto:rbridge-bounces@postel.org]On >--> >>>--> Behalf Of Radia Perlman >--> >>>--> Sent: Saturday, October 22, 2005 4:59 PM >--> >>>--> To: Developing a hybrid router/bridge. >--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >>>--> >--> >>>--> >--> >>>--> And another thought. Although I don't think we should >--> >>>--> include the notion of >--> >>>--> a combined bridge/RBridge in the spec for RBridges, >--> >>>--> just a suggestion for anyone that wants to build >--> this beast... >--> >>>--> >--> >>>--> It would be nice to minimize configuration, so especially >--> >>>--> if the reason >--> >>>--> for making a >--> >>>--> bridge/RBridge is to >--> >>>--> make an RBridge have higher priority for being >--> bridge spanning tree >--> >>>--> Root, have the priority for >--> >>>--> bridge Root be a function of the RBridge IS-IS DR priority, >--> >>>--> so you only >--> >>>--> have to set one >--> >>>--> of them. >--> >>>--> >--> >>>--> We don't have to debate this, since this if it's not >--> in the RBridge >--> >>>--> spec, vendors can >--> >>>--> do whatever they want. But it's perhaps good to have >--> >>>--> suggestions posted >--> >>>--> publicly. >--> >>>--> >--> >>>--> Radia >--> >>>--> >--> >>>--> >--> >>>--> >--> >>>--> Peter Ashwood-Smith wrote: >--> >>>--> >--> >>>--> >Likewise. >--> >>>--> > >--> >>>--> > >--> >>>--> > >--> >>>--> >>-----Original Message----- >--> >>>--> >>From: rbridge-bounces@postel.org >--> >>>--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric >--> >>>--> >>Sent: Friday, October 21, 2005 6:16 PM >--> >>>--> >>To: 'Developing a hybrid router/bridge.' >--> >>>--> >>Subject: Re: [rbridge] RBridge/bridge interaction >--> >>>--> >> >--> >>>--> >> >--> >>>--> >>I also agree that this is a quite feasible approach. >--> >>>--> >> >--> >>>--> >>-- >--> >>>--> >>Eric >--> >>>--> >> >--> >>>--> >>--> -----Original Message----- >--> >>>--> >>--> From: rbridge-bounces@postel.org >--> >>>--> >>--> [mailto:rbridge-bounces@postel.org]On >--> >>>--> >>--> Behalf Of Guillermo Ib??ez >--> >>>--> >>--> Sent: Friday, October 21, 2005 6:01 PM >--> >>>--> >>--> To: Developing a hybrid router/bridge. >--> >>>--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >>>--> >>--> >--> >>>--> >>--> >--> >>>--> >>--> Right. In this way both views are covered. I >--> fully agree. >--> >>>--> >>Guillermo >--> >>>--> >>--> >--> >>>--> >>--> Radia Perlman wrote: >--> >>>--> >>--> >--> >>>--> >>--> >Actually, here's a suggestion that may make >--> us all happy. >--> >>>--> >>--> > >--> >>>--> >>--> >Keep the design of RBridge independent of bridges. >--> >>>--> >>RBridges do not >--> >>>--> >>--> >participate >--> >>>--> >>--> >in spanning tree (other than throwing away BPDUs). >--> >>>--> >>--> > >--> >>>--> >>--> >However, to get the functionality that Guillermo >--> >>>--> >>--> wants....allow someone >--> >>>--> >>--> >to build a device that's logically the >--> >>>--> >>--> >same as a bridge glued onto an RBridge. To >--> the rest of the >--> >>>--> >>--> world it >--> >>>--> >>--> >would look >--> >>>--> >>--> >like this: >--> >>>--> >>--> > >--> >>>--> >>--> >bridged island----B1----RB1 >--> >>>--> >>--> > >--> >>>--> >>--> >where B1 is a bridge with two ports...a >--> pt-to-pt link to >--> >>>--> >>--> RBRidge RB1, >--> >>>--> >>--> >and a link to the >--> >>>--> >>--> >bridged LAN. >--> >>>--> >>--> > >--> >>>--> >>--> >The "RB1" portion of this box does what the >--> architecture >--> >>>--> >>--> of an RBridge >--> >>>--> >>--> >does...it neither >--> >>>--> >>--> >forwards, nor initiates spanning tree messages. >--> >>>--> >>--> > >--> >>>--> >>--> >However, the "B1" portion of the box acts >--> like a vanilla >--> >>>--> >>--> bridge, and >--> >>>--> >>--> >does participate in >--> >>>--> >>--> >spanning tree. And it can be configured to >--> have whatever >--> >>>--> >>--> priority people >--> >>>--> >>--> >want. >--> >>>--> >>--> > >--> >>>--> >>--> >If it's commercially important for RBridges >--> to have the >--> >>>--> >>--> capability of >--> >>>--> >>--> >participating in >--> >>>--> >>--> >the bridge protocol, it can be done this way without >--> >>>--> >>--> defining it into >--> >>>--> >>--> >either the RBridge >--> >>>--> >>--> >or bridge functionality. >--> >>>--> >>--> > >--> >>>--> >>--> >Radia >--> >>>--> >>--> > >--> >>>--> >>--> > >--> >>>--> >>--> > >--> >>>--> >>--> >Guillermo Ib??ez wrote: >--> >>>--> >>--> > >--> >>>--> >>--> > >--> >>>--> >>--> > >--> >>>--> >>--> >>Root bridge planning is something required in campus >--> >>>--> >>--> networks, it just >--> >>>--> >>--> >>means configure the 16 bit priority of the >--> preffered root >--> >>>--> >>--> bridge (and >--> >>>--> >>--> >>perhaps a root reserve) with a low enough >--> value under the >--> >>>--> >>--> default value. >--> >>>--> >>--> >> >--> >>>--> >>--> >> >--> >>>--> >>--> >> >--> >>>--> >>--> > >--> >>>--> >>--> > >--> >>>--> >>--> >_______________________________________________ >--> >>>--> >>--> >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 >>>>--> > >>>>--> > >>>>--> >>>>--> _______________________________________________ >>>>--> 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 >> >> >> >> >_______________________________________________ >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 sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9QE3ML16176 for <rbridge@postel.org>; Wed, 26 Oct 2005 07:03:22 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Oct 2005 07:06:47 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2A6EBD0@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] How should RBridges recognize spanning tree messages? Thread-Index: AcXaMgHEA7YWTM1wQVePflU3cmX1EAAA0qJQ From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9QE3ML16176 Subject: Re: [rbridge] How should RBridges recognize spanning tree messages? 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, 26 Oct 2005 14:03:57 -0000 Status: RO Content-Length: 3279 Hi Guillermo, One address you may have missed out is the Pause Frame address 01-80-C2-00-00-01. Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 devices). Thanks, Vishwas -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Guillermo Ib??ez Sent: Wednesday, October 26, 2005 6:44 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] How should RBridges recognize spanning tree messages? See below current related addresses and usage according *my interpretation* of bridges standard: Radia Perlman wrote: >Another interesting question....exactly how should an RBridge recognize >a BPDU in order to >discard it? If I remember correctly, the layer 2 multicast address used >for BPDUs (including >"topology change notifications") is only used for bridge messages. If >that's true, then >is that the criteria RBridges should use, i.e., discard any messages >sent to that layer 2 >multicast address? > > > Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting BPDUs (they are confined by bridges to same LAN segment). Bridges DO NOT forward these frames. Neither should RBridges ! It seems that any messages to that address should be discarded because even bridges do not forward them (they process them). However, I would recommend to ask the IEEE. >It's conceivable that there is some management thing that might be sent >to "all bridges". > I see this in the standard: All LANs Bridge Management group address : 01-80-C2-00-00-10. I think they should be forwarded. >that case, it's possible we'd want such messages forwarded across the >RBridges, and treated >like other layer 2 multicasts within what I was calling the "campus". Or >a case could be >made that such a message should go only to the bridged island, just as >such messages would >not be forwarded through routers. > > > I think that not forwarding multicast addresses by RBridges should be exceptional. The bridged domain should be kept manageable at campus level without fragmentation. in bridged islands. >But if that layer 2 address is only used for spanning tree (including >topology change notifications), >then it's safe for RBridges to look no further than the layer 2 >destination address, in terms >of what should be discarded. > > > It seems safe (asking the IEEE). >If not (if that layer 2 address is used both for spanning tree messages >which RBridges should >discard, and for other messages that RBridges should forward), then we >should specify >which fields other than the layer 2 header destination address that >RBridges would need to >look at in order to know what to discard. > > > If no confirmation from IEEE regarding Bridge Group Address usage, it might be safer if RBridges look also at the protocol ID (0). Guillermo >Radia > > > > Other addresses: GMRP group address : 01-80-C2-00-00-20 (used by GARP PDUs) . GVRP group address: 01-80-C2-00-00-21 (used by GARP PDUs). I did not follow the multicast discusion entirely so I am not aware of the position regarding this. Bridges that do not support GMRP or GVRP forward these frames. Bridges that support terminate and process them. 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 j9QDj0L10858 for <rbridge@postel.org>; Wed, 26 Oct 2005 06:45:01 -0700 (PDT) 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 j9QDisp1002939 for <rbridge@postel.org>; Wed, 26 Oct 2005 09:44:54 -0400 (EDT) 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 JAA14383 for <rbridge@postel.org>; Wed, 26 Oct 2005 09:44:54 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX0PGY>; Wed, 26 Oct 2005 10:44:53 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C886017@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 26 Oct 2005 10:44:51 -0300 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 j9QDj0L10858 Subject: Re: [rbridge] RBridge/bridge interaction 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, 26 Oct 2005 13:45:31 -0000 Status: RO Content-Length: 10338 Guillermo, Thanks! By the way, it is not absolutely necessary to give explicit directions on how to insert or modify the text you propose. Trust me, I probably can get the intent right, once I've seen proposed text and minor corrections on the mailing list... :-) -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Wednesday, October 26, 2005 2:43 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> Radia Perlman wrote: --> --> > No objection to inclusion of the text proposed by --> Guillermo, as long --> > as it's clear it's not mandatory for all RBridges to --> > be combined bridge/RBridges. --> > --> > --> OK. Add this sentence explicitly: "It is not mandatory for --> RBridges be --> combined bridge/RBridges". --> Guillermo --> --> > --> > Guillermo Ib??ez wrote: --> > --> >>Eric, Radia : --> >> --> >>I have use Radia?s text as much as possible to describe --> it as a first --> >>proposal and added a final sentence on the default value --> for RBridges. --> >>Feel free to correct english expressions. --> >>Guillermo --> >> --> >> --> >>RBridge indirect participation in bridged island spanning tree. --> >>--------------------------------------------------------------- --> >>RBridges by default do not participate in spanning tree --> in other way than ignoring received BPDUs. It is an --> objective of RBridge specification to be independent of --> bridges specifications as much as possible. --> >> However it may be convenient for RBridges in some --> circumstances to participate in the spanning tree and --> contend to be root bridge of the spanning tree formed in --> the bridged island they are attached to. In these cases it --> is possible to build a device that's logically the same as --> a bridge glued onto an RBridge. The following schema applies: --> >> --> >> ?-----------? --> >> bridged island-----B1----RB1 ? --> >> ?-----------? --> >> --> >> RBridge/bridge box --> >> --> >>where B1 is a bridge with two ports...a pt-to-pt link to --> RBRidge RB1, and a link to the bridged LAN. The "RB1" --> portion of this box acts as an standard RBridge, it neither --> forwards, nor initiates spanning tree messages. The "B1" --> portion acts as two-port standard 802.1D bridge, and does --> participate in spanning tree. Its priority for root --> election can be set in the standard way. To minimize --> configurafion, it may be convenient in some implementations --> to make the standard B1 bridge priority a function of the --> configurable RBridge priority for IS-IS Designated RBridge --> election. In this way Designated RBridge will participate --> and contend (as B1) to be elected also as root bridge of --> the bridged island and only one priority configuration is required. --> >> --> >>In environments using such implementations, if the --> default bridge priority for B1 is lower than standard --> bridges priority, RBridges/bridges like B1 will become --> roots of their bridged islands, contending only with other --> RBridges connected to same island for root election. --> >> --> >> --> >> --> >> --> >> --> >> --> >>Gray, Eric wrote: --> >> --> >> --> >> --> >>>I think we should leave that sort of determination to the --> >>>supposed wisdom of the successful implementer. But I won't --> >>>object to text along these lines if someone else wants to --> >>>write it... --> >>> --> >>>-- --> >>>Eric --> >>> --> >>>--> -----Original Message----- --> >>>--> From: rbridge-bounces@postel.org --> >>>--> [mailto:rbridge-bounces@postel.org]On --> >>>--> Behalf Of Radia Perlman --> >>>--> Sent: Saturday, October 22, 2005 4:59 PM --> >>>--> To: Developing a hybrid router/bridge. --> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>>--> --> >>>--> --> >>>--> And another thought. Although I don't think we should --> >>>--> include the notion of --> >>>--> a combined bridge/RBridge in the spec for RBridges, --> >>>--> just a suggestion for anyone that wants to build --> this beast... --> >>>--> --> >>>--> It would be nice to minimize configuration, so especially --> >>>--> if the reason --> >>>--> for making a --> >>>--> bridge/RBridge is to --> >>>--> make an RBridge have higher priority for being --> bridge spanning tree --> >>>--> Root, have the priority for --> >>>--> bridge Root be a function of the RBridge IS-IS DR priority, --> >>>--> so you only --> >>>--> have to set one --> >>>--> of them. --> >>>--> --> >>>--> We don't have to debate this, since this if it's not --> in the RBridge --> >>>--> spec, vendors can --> >>>--> do whatever they want. But it's perhaps good to have --> >>>--> suggestions posted --> >>>--> publicly. --> >>>--> --> >>>--> Radia --> >>>--> --> >>>--> --> >>>--> --> >>>--> Peter Ashwood-Smith wrote: --> >>>--> --> >>>--> >Likewise. --> >>>--> > --> >>>--> > --> >>>--> > --> >>>--> >>-----Original Message----- --> >>>--> >>From: rbridge-bounces@postel.org --> >>>--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric --> >>>--> >>Sent: Friday, October 21, 2005 6:16 PM --> >>>--> >>To: 'Developing a hybrid router/bridge.' --> >>>--> >>Subject: Re: [rbridge] RBridge/bridge interaction --> >>>--> >> --> >>>--> >> --> >>>--> >>I also agree that this is a quite feasible approach. --> >>>--> >> --> >>>--> >>-- --> >>>--> >>Eric --> >>>--> >> --> >>>--> >>--> -----Original Message----- --> >>>--> >>--> From: rbridge-bounces@postel.org --> >>>--> >>--> [mailto:rbridge-bounces@postel.org]On --> >>>--> >>--> Behalf Of Guillermo Ib??ez --> >>>--> >>--> Sent: Friday, October 21, 2005 6:01 PM --> >>>--> >>--> To: Developing a hybrid router/bridge. --> >>>--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>>--> >>--> --> >>>--> >>--> --> >>>--> >>--> Right. In this way both views are covered. I --> fully agree. --> >>>--> >>Guillermo --> >>>--> >>--> --> >>>--> >>--> Radia Perlman wrote: --> >>>--> >>--> --> >>>--> >>--> >Actually, here's a suggestion that may make --> us all happy. --> >>>--> >>--> > --> >>>--> >>--> >Keep the design of RBridge independent of bridges. --> >>>--> >>RBridges do not --> >>>--> >>--> >participate --> >>>--> >>--> >in spanning tree (other than throwing away BPDUs). --> >>>--> >>--> > --> >>>--> >>--> >However, to get the functionality that Guillermo --> >>>--> >>--> wants....allow someone --> >>>--> >>--> >to build a device that's logically the --> >>>--> >>--> >same as a bridge glued onto an RBridge. To --> the rest of the --> >>>--> >>--> world it --> >>>--> >>--> >would look --> >>>--> >>--> >like this: --> >>>--> >>--> > --> >>>--> >>--> >bridged island----B1----RB1 --> >>>--> >>--> > --> >>>--> >>--> >where B1 is a bridge with two ports...a --> pt-to-pt link to --> >>>--> >>--> RBRidge RB1, --> >>>--> >>--> >and a link to the --> >>>--> >>--> >bridged LAN. --> >>>--> >>--> > --> >>>--> >>--> >The "RB1" portion of this box does what the --> architecture --> >>>--> >>--> of an RBridge --> >>>--> >>--> >does...it neither --> >>>--> >>--> >forwards, nor initiates spanning tree messages. --> >>>--> >>--> > --> >>>--> >>--> >However, the "B1" portion of the box acts --> like a vanilla --> >>>--> >>--> bridge, and --> >>>--> >>--> >does participate in --> >>>--> >>--> >spanning tree. And it can be configured to --> have whatever --> >>>--> >>--> priority people --> >>>--> >>--> >want. --> >>>--> >>--> > --> >>>--> >>--> >If it's commercially important for RBridges --> to have the --> >>>--> >>--> capability of --> >>>--> >>--> >participating in --> >>>--> >>--> >the bridge protocol, it can be done this way without --> >>>--> >>--> defining it into --> >>>--> >>--> >either the RBridge --> >>>--> >>--> >or bridge functionality. --> >>>--> >>--> > --> >>>--> >>--> >Radia --> >>>--> >>--> > --> >>>--> >>--> > --> >>>--> >>--> > --> >>>--> >>--> >Guillermo Ib??ez wrote: --> >>>--> >>--> > --> >>>--> >>--> > --> >>>--> >>--> > --> >>>--> >>--> >>Root bridge planning is something required in campus --> >>>--> >>--> networks, it just --> >>>--> >>--> >>means configure the 16 bit priority of the --> preffered root --> >>>--> >>--> bridge (and --> >>>--> >>--> >>perhaps a root reserve) with a low enough --> value under the --> >>>--> >>--> default value. --> >>>--> >>--> >> --> >>>--> >>--> >> --> >>>--> >>--> >> --> >>>--> >>--> > --> >>>--> >>--> > --> >>>--> >>--> >_______________________________________________ --> >>>--> >>--> >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 >>>--> > >>>--> > >>>--> >>>--> _______________________________________________ >>>--> 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 > > _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from smtp.ya.com (smtp02.ya.com [62.151.11.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9QDEPL01980 for <rbridge@postel.org>; Wed, 26 Oct 2005 06:14:26 -0700 (PDT) Received: from [80.37.137.39] (helo=[10.0.0.4]) by smtp.ya.com with esmtp id 1EUl6m-0004R3-00 for rbridge@postel.org; Wed, 26 Oct 2005 15:14:24 +0200 Message-ID: <435F812E.8050705@it.uc3m.es> Date: Wed, 26 Oct 2005 15:14:22 +0200 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: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.com> <435E01F9.7090202@it.uc3m.es> <435E846F.6050300@sun.com> In-Reply-To: <435E846F.6050300@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] How should RBridges recognize spanning tree messages? 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, 26 Oct 2005 13:15:29 -0000 Status: RO Content-Length: 2888 See below current related addresses and usage according *my interpretation* of bridges standard: Radia Perlman wrote: >Another interesting question....exactly how should an RBridge recognize >a BPDU in order to >discard it? If I remember correctly, the layer 2 multicast address used >for BPDUs (including >"topology change notifications") is only used for bridge messages. If >that's true, then >is that the criteria RBridges should use, i.e., discard any messages >sent to that layer 2 >multicast address? > > > Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting BPDUs (they are confined by bridges to same LAN segment). Bridges DO NOT forward these frames. Neither should RBridges ! It seems that any messages to that address should be discarded because even bridges do not forward them (they process them). However, I would recommend to ask the IEEE. >It's conceivable that there is some management thing that might be sent >to "all bridges". > I see this in the standard: All LANs Bridge Management group address : 01-80-C2-00-00-10. I think they should be forwarded. >that case, it's possible we'd want such messages forwarded across the >RBridges, and treated >like other layer 2 multicasts within what I was calling the "campus". Or >a case could be >made that such a message should go only to the bridged island, just as >such messages would >not be forwarded through routers. > > > I think that not forwarding multicast addresses by RBridges should be exceptional. The bridged domain should be kept manageable at campus level without fragmentation. in bridged islands. >But if that layer 2 address is only used for spanning tree (including >topology change notifications), >then it's safe for RBridges to look no further than the layer 2 >destination address, in terms >of what should be discarded. > > > It seems safe (asking the IEEE). >If not (if that layer 2 address is used both for spanning tree messages >which RBridges should >discard, and for other messages that RBridges should forward), then we >should specify >which fields other than the layer 2 header destination address that >RBridges would need to >look at in order to know what to discard. > > > If no confirmation from IEEE regarding Bridge Group Address usage, it might be safer if RBridges look also at the protocol ID (0). Guillermo >Radia > > > > Other addresses: GMRP group address : 01-80-C2-00-00-20 (used by GARP PDUs) . GVRP group address: 01-80-C2-00-00-21 (used by GARP PDUs). I did not follow the multicast discusion entirely so I am not aware of the position regarding this. Bridges that do not support GMRP or GVRP forward these frames. Bridges that support terminate and process them. ______________________________________________ >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 j9Q6goL15553 for <rbridge@postel.org>; Tue, 25 Oct 2005 23:42:50 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E12CA82300 for <rbridge@postel.org>; Wed, 26 Oct 2005 08:42:43 +0200 (CEST) Received: from [163.117.203.92] (unknown [163.117.203.92]) by smtp03.uc3m.es (Postfix) with ESMTP id C118482319 for <rbridge@postel.org>; Wed, 26 Oct 2005 08:42:42 +0200 (CEST) Message-ID: <435F2562.9070100@it.uc3m.es> Date: Wed, 26 Oct 2005 08:42:42 +0200 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: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.com> <435E01F9.7090202@it.uc3m.es> <435E83E4.2050101@sun.com> In-Reply-To: <435E83E4.2050101@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] RBridge/bridge interaction 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, 26 Oct 2005 06:43:56 -0000 Status: RO Content-Length: 8630 Radia Perlman wrote: > No objection to inclusion of the text proposed by Guillermo, as long > as it's clear it's not mandatory for all RBridges to > be combined bridge/RBridges. > > OK. Add this sentence explicitly: "It is not mandatory for RBridges be combined bridge/RBridges". Guillermo > > Guillermo Ib??ez wrote: > >>Eric, Radia : >> >>I have use Radia?s text as much as possible to describe it as a first >>proposal and added a final sentence on the default value for RBridges. >>Feel free to correct english expressions. >>Guillermo >> >> >>RBridge indirect participation in bridged island spanning tree. >>--------------------------------------------------------------- >>RBridges by default do not participate in spanning tree in other way than ignoring received BPDUs. It is an objective of RBridge specification to be independent of bridges specifications as much as possible. >> However it may be convenient for RBridges in some circumstances to participate in the spanning tree and contend to be root bridge of the spanning tree formed in the bridged island they are attached to. In these cases it is possible to build a device that's logically the same as a bridge glued onto an RBridge. The following schema applies: >> >> ?-----------? >> bridged island-----B1----RB1 ? >> ?-----------? >> >> RBridge/bridge box >> >>where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box acts as an standard RBridge, it neither forwards, nor initiates spanning tree messages. The "B1" portion acts as two-port standard 802.1D bridge, and does participate in spanning tree. Its priority for root election can be set in the standard way. To minimize configurafion, it may be convenient in some implementations to make the standard B1 bridge priority a function of the configurable RBridge priority for IS-IS Designated RBridge election. In this way Designated RBridge will participate and contend (as B1) to be elected also as root bridge of the bridged island and only one priority configuration is required. >> >>In environments using such implementations, if the default bridge priority for B1 is lower than standard bridges priority, RBridges/bridges like B1 will become roots of their bridged islands, contending only with other RBridges connected to same island for root election. >> >> >> >> >> >> >>Gray, Eric wrote: >> >> >> >>>I think we should leave that sort of determination to the >>>supposed wisdom of the successful implementer. But I won't >>>object to text along these lines if someone else wants to >>>write it... >>> >>>-- >>>Eric >>> >>>--> -----Original Message----- >>>--> From: rbridge-bounces@postel.org >>>--> [mailto:rbridge-bounces@postel.org]On >>>--> Behalf Of Radia Perlman >>>--> Sent: Saturday, October 22, 2005 4:59 PM >>>--> To: Developing a hybrid router/bridge. >>>--> Subject: Re: [rbridge] RBridge/bridge interaction >>>--> >>>--> >>>--> And another thought. Although I don't think we should >>>--> include the notion of >>>--> a combined bridge/RBridge in the spec for RBridges, >>>--> just a suggestion for anyone that wants to build this beast... >>>--> >>>--> It would be nice to minimize configuration, so especially >>>--> if the reason >>>--> for making a >>>--> bridge/RBridge is to >>>--> make an RBridge have higher priority for being bridge spanning tree >>>--> Root, have the priority for >>>--> bridge Root be a function of the RBridge IS-IS DR priority, >>>--> so you only >>>--> have to set one >>>--> of them. >>>--> >>>--> We don't have to debate this, since this if it's not in the RBridge >>>--> spec, vendors can >>>--> do whatever they want. But it's perhaps good to have >>>--> suggestions posted >>>--> publicly. >>>--> >>>--> Radia >>>--> >>>--> >>>--> >>>--> Peter Ashwood-Smith wrote: >>>--> >>>--> >Likewise. >>>--> > >>>--> > >>>--> > >>>--> >>-----Original Message----- >>>--> >>From: rbridge-bounces@postel.org >>>--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric >>>--> >>Sent: Friday, October 21, 2005 6:16 PM >>>--> >>To: 'Developing a hybrid router/bridge.' >>>--> >>Subject: Re: [rbridge] RBridge/bridge interaction >>>--> >> >>>--> >> >>>--> >>I also agree that this is a quite feasible approach. >>>--> >> >>>--> >>-- >>>--> >>Eric >>>--> >> >>>--> >>--> -----Original Message----- >>>--> >>--> From: rbridge-bounces@postel.org >>>--> >>--> [mailto:rbridge-bounces@postel.org]On >>>--> >>--> Behalf Of Guillermo Ib??ez >>>--> >>--> Sent: Friday, October 21, 2005 6:01 PM >>>--> >>--> To: Developing a hybrid router/bridge. >>>--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction >>>--> >>--> >>>--> >>--> >>>--> >>--> Right. In this way both views are covered. I fully agree. >>>--> >>Guillermo >>>--> >>--> >>>--> >>--> Radia Perlman wrote: >>>--> >>--> >>>--> >>--> >Actually, here's a suggestion that may make us all happy. >>>--> >>--> > >>>--> >>--> >Keep the design of RBridge independent of bridges. >>>--> >>RBridges do not >>>--> >>--> >participate >>>--> >>--> >in spanning tree (other than throwing away BPDUs). >>>--> >>--> > >>>--> >>--> >However, to get the functionality that Guillermo >>>--> >>--> wants....allow someone >>>--> >>--> >to build a device that's logically the >>>--> >>--> >same as a bridge glued onto an RBridge. To the rest of the >>>--> >>--> world it >>>--> >>--> >would look >>>--> >>--> >like this: >>>--> >>--> > >>>--> >>--> >bridged island----B1----RB1 >>>--> >>--> > >>>--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to >>>--> >>--> RBRidge RB1, >>>--> >>--> >and a link to the >>>--> >>--> >bridged LAN. >>>--> >>--> > >>>--> >>--> >The "RB1" portion of this box does what the architecture >>>--> >>--> of an RBridge >>>--> >>--> >does...it neither >>>--> >>--> >forwards, nor initiates spanning tree messages. >>>--> >>--> > >>>--> >>--> >However, the "B1" portion of the box acts like a vanilla >>>--> >>--> bridge, and >>>--> >>--> >does participate in >>>--> >>--> >spanning tree. And it can be configured to have whatever >>>--> >>--> priority people >>>--> >>--> >want. >>>--> >>--> > >>>--> >>--> >If it's commercially important for RBridges to have the >>>--> >>--> capability of >>>--> >>--> >participating in >>>--> >>--> >the bridge protocol, it can be done this way without >>>--> >>--> defining it into >>>--> >>--> >either the RBridge >>>--> >>--> >or bridge functionality. >>>--> >>--> > >>>--> >>--> >Radia >>>--> >>--> > >>>--> >>--> > >>>--> >>--> > >>>--> >>--> >Guillermo Ib??ez wrote: >>>--> >>--> > >>>--> >>--> > >>>--> >>--> > >>>--> >>--> >>Root bridge planning is something required in campus >>>--> >>--> networks, it just >>>--> >>--> >>means configure the 16 bit priority of the preffered root >>>--> >>--> bridge (and >>>--> >>--> >>perhaps a root reserve) with a low enough value under the >>>--> >>--> default value. >>>--> >>--> >> >>>--> >>--> >> >>>--> >>--> >> >>>--> >>--> > >>>--> >>--> > >>>--> >>--> >_______________________________________________ >>>--> >>--> >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 >>>--> > >>>--> > >>>--> >>>--> _______________________________________________ >>>--> 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 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 j9PJFvL25049 for <rbridge@postel.org>; Tue, 25 Oct 2005 12:15:57 -0700 (PDT) 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 <0IOX0051RK6GS910@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 25 Oct 2005 12:15:52 -0700 (PDT) Received: from sun.com ([129.150.24.92]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOX003JXK6FTF60@mail.sunlabs.com> for rbridge@postel.org; Tue, 25 Oct 2005 12:15:52 -0700 (PDT) Date: Tue, 25 Oct 2005 12:15:59 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <435E01F9.7090202@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435E846F.6050300@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: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.com> <435E01F9.7090202@it.uc3m.es> 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] How should RBridges recognize spanning tree messages? 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, 25 Oct 2005 19:16:52 -0000 Status: RO Content-Length: 1343 Another interesting question....exactly how should an RBridge recognize a BPDU in order to discard it? If I remember correctly, the layer 2 multicast address used for BPDUs (including "topology change notifications") is only used for bridge messages. If that's true, then is that the criteria RBridges should use, i.e., discard any messages sent to that layer 2 multicast address? It's conceivable that there is some management thing that might be sent to "all bridges". In that case, it's possible we'd want such messages forwarded across the RBridges, and treated like other layer 2 multicasts within what I was calling the "campus". Or a case could be made that such a message should go only to the bridged island, just as such messages would not be forwarded through routers. But if that layer 2 address is only used for spanning tree (including topology change notifications), then it's safe for RBridges to look no further than the layer 2 destination address, in terms of what should be discarded. If not (if that layer 2 address is used both for spanning tree messages which RBridges should discard, and for other messages that RBridges should forward), then we should specify which fields other than the layer 2 header destination address that RBridges would need to look at in order to know what to discard. Radia 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 j9PJDfL24402 for <rbridge@postel.org>; Tue, 25 Oct 2005 12:13:41 -0700 (PDT) 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 <0IOX0051KK2LS910@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 25 Oct 2005 12:13:33 -0700 (PDT) Received: from sun.com ([129.150.24.92]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOX003JSK2KTF60@mail.sunlabs.com> for rbridge@postel.org; Tue, 25 Oct 2005 12:13:33 -0700 (PDT) Date: Tue, 25 Oct 2005 12:13:40 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <435E01F9.7090202@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435E83E4.2050101@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1cW9761bbl6Yh/fho+frXA)" X-Accept-Language: en-us, en References: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.com> <435E01F9.7090202@it.uc3m.es> 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] RBridge/bridge interaction 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, 25 Oct 2005 19:14:28 -0000 Status: RO Content-Length: 19763 This is a multi-part message in MIME format. --Boundary_(ID_1cW9761bbl6Yh/fho+frXA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT No objection to inclusion of the text proposed by Guillermo, as long as it's clear it's not mandatory for all RBridges to be combined bridge/RBridges. Guillermo Ib??ez wrote: >Eric, Radia : > >I have use Radia?s text as much as possible to describe it as a first >proposal and added a final sentence on the default value for RBridges. >Feel free to correct english expressions. >Guillermo > > >RBridge indirect participation in bridged island spanning tree. >--------------------------------------------------------------- >RBridges by default do not participate in spanning tree in other way than ignoring received BPDUs. It is an objective of RBridge specification to be independent of bridges specifications as much as possible. > However it may be convenient for RBridges in some circumstances to participate in the spanning tree and contend to be root bridge of the spanning tree formed in the bridged island they are attached to. In these cases it is possible to build a device that's logically the same as a bridge glued onto an RBridge. The following schema applies: > > ?-----------? > bridged island-----B1----RB1 ? > ?-----------? > > RBridge/bridge box > >where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box acts as an standard RBridge, it neither forwards, nor initiates spanning tree messages. The "B1" portion acts as two-port standard 802.1D bridge, and does participate in spanning tree. Its priority for root election can be set in the standard way. To minimize configurafion, it may be convenient in some implementations to make the standard B1 bridge priority a function of the configurable RBridge priority for IS-IS Designated RBridge election. In this way Designated RBridge will participate and contend (as B1) to be elected also as root bridge of the bridged island and only one priority configuration is required. > >In environments using such implementations, if the default bridge priority for B1 is lower than standard bridges priority, RBridges/bridges like B1 will become roots of their bridged islands, contending only with other RBridges connected to same island for root election. > > > > > > >Gray, Eric wrote: > > > >>I think we should leave that sort of determination to the >>supposed wisdom of the successful implementer. But I won't >>object to text along these lines if someone else wants to >>write it... >> >>-- >>Eric >> >>--> -----Original Message----- >>--> From: rbridge-bounces@postel.org >>--> [mailto:rbridge-bounces@postel.org]On >>--> Behalf Of Radia Perlman >>--> Sent: Saturday, October 22, 2005 4:59 PM >>--> To: Developing a hybrid router/bridge. >>--> Subject: Re: [rbridge] RBridge/bridge interaction >>--> >>--> >>--> And another thought. Although I don't think we should >>--> include the notion of >>--> a combined bridge/RBridge in the spec for RBridges, >>--> just a suggestion for anyone that wants to build this beast... >>--> >>--> It would be nice to minimize configuration, so especially >>--> if the reason >>--> for making a >>--> bridge/RBridge is to >>--> make an RBridge have higher priority for being bridge spanning tree >>--> Root, have the priority for >>--> bridge Root be a function of the RBridge IS-IS DR priority, >>--> so you only >>--> have to set one >>--> of them. >>--> >>--> We don't have to debate this, since this if it's not in the RBridge >>--> spec, vendors can >>--> do whatever they want. But it's perhaps good to have >>--> suggestions posted >>--> publicly. >>--> >>--> Radia >>--> >>--> >>--> >>--> Peter Ashwood-Smith wrote: >>--> >>--> >Likewise. >>--> > >>--> > >>--> > >>--> >>-----Original Message----- >>--> >>From: rbridge-bounces@postel.org >>--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric >>--> >>Sent: Friday, October 21, 2005 6:16 PM >>--> >>To: 'Developing a hybrid router/bridge.' >>--> >>Subject: Re: [rbridge] RBridge/bridge interaction >>--> >> >>--> >> >>--> >>I also agree that this is a quite feasible approach. >>--> >> >>--> >>-- >>--> >>Eric >>--> >> >>--> >>--> -----Original Message----- >>--> >>--> From: rbridge-bounces@postel.org >>--> >>--> [mailto:rbridge-bounces@postel.org]On >>--> >>--> Behalf Of Guillermo Ib??ez >>--> >>--> Sent: Friday, October 21, 2005 6:01 PM >>--> >>--> To: Developing a hybrid router/bridge. >>--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction >>--> >>--> >>--> >>--> >>--> >>--> Right. In this way both views are covered. I fully agree. >>--> >>Guillermo >>--> >>--> >>--> >>--> Radia Perlman wrote: >>--> >>--> >>--> >>--> >Actually, here's a suggestion that may make us all happy. >>--> >>--> > >>--> >>--> >Keep the design of RBridge independent of bridges. >>--> >>RBridges do not >>--> >>--> >participate >>--> >>--> >in spanning tree (other than throwing away BPDUs). >>--> >>--> > >>--> >>--> >However, to get the functionality that Guillermo >>--> >>--> wants....allow someone >>--> >>--> >to build a device that's logically the >>--> >>--> >same as a bridge glued onto an RBridge. To the rest of the >>--> >>--> world it >>--> >>--> >would look >>--> >>--> >like this: >>--> >>--> > >>--> >>--> >bridged island----B1----RB1 >>--> >>--> > >>--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to >>--> >>--> RBRidge RB1, >>--> >>--> >and a link to the >>--> >>--> >bridged LAN. >>--> >>--> > >>--> >>--> >The "RB1" portion of this box does what the architecture >>--> >>--> of an RBridge >>--> >>--> >does...it neither >>--> >>--> >forwards, nor initiates spanning tree messages. >>--> >>--> > >>--> >>--> >However, the "B1" portion of the box acts like a vanilla >>--> >>--> bridge, and >>--> >>--> >does participate in >>--> >>--> >spanning tree. And it can be configured to have whatever >>--> >>--> priority people >>--> >>--> >want. >>--> >>--> > >>--> >>--> >If it's commercially important for RBridges to have the >>--> >>--> capability of >>--> >>--> >participating in >>--> >>--> >the bridge protocol, it can be done this way without >>--> >>--> defining it into >>--> >>--> >either the RBridge >>--> >>--> >or bridge functionality. >>--> >>--> > >>--> >>--> >Radia >>--> >>--> > >>--> >>--> > >>--> >>--> > >>--> >>--> >Guillermo Ib??ez wrote: >>--> >>--> > >>--> >>--> > >>--> >>--> > >>--> >>--> >>Root bridge planning is something required in campus >>--> >>--> networks, it just >>--> >>--> >>means configure the 16 bit priority of the preffered root >>--> >>--> bridge (and >>--> >>--> >>perhaps a root reserve) with a low enough value under the >>--> >>--> default value. >>--> >>--> >> >>--> >>--> >> >>--> >>--> >> >>--> >>--> > >>--> >>--> > >>--> >>--> >_______________________________________________ >>--> >>--> >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 >>--> > >>--> > >>--> >>--> _______________________________________________ >>--> 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 > > --Boundary_(ID_1cW9761bbl6Yh/fho+frXA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> No objection to inclusion of the text proposed by Guillermo, as long as it's clear it's not mandatory for all RBridges to<br> be combined bridge/RBridges.<br> <br> <br> <br> Guillermo Ibáñez wrote:<br> <blockquote type="cite" cite="mid435E01F9.7090202@it.uc3m.es"> <pre wrap="">Eric, Radia : I have use Radia´s text as much as possible to describe it as a first proposal and added a final sentence on the default value for RBridges. Feel free to correct english expressions. Guillermo RBridge indirect participation in bridged island spanning tree. --------------------------------------------------------------- RBridges by default do not participate in spanning tree in other way than ignoring received BPDUs. It is an objective of RBridge specification to be independent of bridges specifications as much as possible. However it may be convenient for RBridges in some circumstances to participate in the spanning tree and contend to be root bridge of the spanning tree formed in the bridged island they are attached to. In these cases it is possible to build a device that's logically the same as a bridge glued onto an RBridge. The following schema applies: ¡-----------¡ bridged island-----B1----RB1 ¡ ¡-----------¡ RBridge/bridge box where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box acts as an standard RBridge, it neither forwards, nor initiates spanning tree messages. The "B1" portion acts as two-port standard 802.1D bridge, and does participate in spanning tree. Its priority for root election can be set in the standard way. To minimize configurafion, it may be convenient in some implementations to make the standard B1 bridge priority a function of the configurable RBridge priority for IS-IS Designated RBridge election. In this way Designated RBridge will participate and contend (as B1) to be elected also as root bridge of the bridged island and only one priority configuration is required. In environments using such implementations, if the default bridge priority for B1 is lower than standard bridges priority, RBridges/bridges like B1 will become roots of their bridged islands, contending only with other RBridges connected to same island for root election. Gray, Eric wrote: </pre> <blockquote type="cite"> <pre wrap="">I think we should leave that sort of determination to the supposed wisdom of the successful implementer. But I won't object to text along these lines if someone else wants to write it... -- Eric --> -----Original Message----- --> From: <a class="moz-txt-link-abbreviated" href="mailto:rbridge-bounces@postel.org">rbridge-bounces@postel.org</a> --> [<a class="moz-txt-link-freetext" href="mailto:rbridge-bounces@postel.org">mailto:rbridge-bounces@postel.org</a>]On --> Behalf Of Radia Perlman --> Sent: Saturday, October 22, 2005 4:59 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> And another thought. Although I don't think we should --> include the notion of --> a combined bridge/RBridge in the spec for RBridges, --> just a suggestion for anyone that wants to build this beast... --> --> It would be nice to minimize configuration, so especially --> if the reason --> for making a --> bridge/RBridge is to --> make an RBridge have higher priority for being bridge spanning tree --> Root, have the priority for --> bridge Root be a function of the RBridge IS-IS DR priority, --> so you only --> have to set one --> of them. --> --> We don't have to debate this, since this if it's not in the RBridge --> spec, vendors can --> do whatever they want. But it's perhaps good to have --> suggestions posted --> publicly. --> --> Radia --> --> --> --> Peter Ashwood-Smith wrote: --> --> >Likewise. --> > --> > --> > --> >>-----Original Message----- --> >>From: <a class="moz-txt-link-abbreviated" href="mailto:rbridge-bounces@postel.org">rbridge-bounces@postel.org</a> --> >>[<a class="moz-txt-link-freetext" href="mailto:rbridge-bounces@postel.org">mailto:rbridge-bounces@postel.org</a>] On Behalf Of Gray, Eric --> >>Sent: Friday, October 21, 2005 6:16 PM --> >>To: 'Developing a hybrid router/bridge.' --> >>Subject: Re: [rbridge] RBridge/bridge interaction --> >> --> >> --> >>I also agree that this is a quite feasible approach. --> >> --> >>-- --> >>Eric --> >> --> >>--> -----Original Message----- --> >>--> From: <a class="moz-txt-link-abbreviated" href="mailto:rbridge-bounces@postel.org">rbridge-bounces@postel.org</a> --> >>--> [<a class="moz-txt-link-freetext" href="mailto:rbridge-bounces@postel.org">mailto:rbridge-bounces@postel.org</a>]On --> >>--> Behalf Of Guillermo Ibáñez --> >>--> Sent: Friday, October 21, 2005 6:01 PM --> >>--> To: Developing a hybrid router/bridge. --> >>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>--> --> >>--> --> >>--> Right. In this way both views are covered. I fully agree. --> >>Guillermo --> >>--> --> >>--> Radia Perlman wrote: --> >>--> --> >>--> >Actually, here's a suggestion that may make us all happy. --> >>--> > --> >>--> >Keep the design of RBridge independent of bridges. --> >>RBridges do not --> >>--> >participate --> >>--> >in spanning tree (other than throwing away BPDUs). --> >>--> > --> >>--> >However, to get the functionality that Guillermo --> >>--> wants....allow someone --> >>--> >to build a device that's logically the --> >>--> >same as a bridge glued onto an RBridge. To the rest of the --> >>--> world it --> >>--> >would look --> >>--> >like this: --> >>--> > --> >>--> >bridged island----B1----RB1 --> >>--> > --> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to --> >>--> RBRidge RB1, --> >>--> >and a link to the --> >>--> >bridged LAN. --> >>--> > --> >>--> >The "RB1" portion of this box does what the architecture --> >>--> of an RBridge --> >>--> >does...it neither --> >>--> >forwards, nor initiates spanning tree messages. --> >>--> > --> >>--> >However, the "B1" portion of the box acts like a vanilla --> >>--> bridge, and --> >>--> >does participate in --> >>--> >spanning tree. And it can be configured to have whatever --> >>--> priority people --> >>--> >want. --> >>--> > --> >>--> >If it's commercially important for RBridges to have the --> >>--> capability of --> >>--> >participating in --> >>--> >the bridge protocol, it can be done this way without --> >>--> defining it into --> >>--> >either the RBridge --> >>--> >or bridge functionality. --> >>--> > --> >>--> >Radia --> >>--> > --> >>--> > --> >>--> > --> >>--> >Guillermo Ibáñez wrote: --> >>--> > --> >>--> > --> >>--> > --> >>--> >>Root bridge planning is something required in campus --> >>--> networks, it just --> >>--> >>means configure the 16 bit priority of the preffered root --> >>--> bridge (and --> >>--> >>perhaps a root reserve) with a low enough value under the --> >>--> default value. --> >>--> >> --> >>--> >> --> >>--> >> --> >>--> > --> >>--> > --> >>--> >_______________________________________________ --> >>--> >rbridge mailing list --> >>--> ><a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> --> <a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> --> >>--> > --> >>--> > --> >>--> > --> >>--> _______________________________________________ --> >>--> rbridge mailing list --> >>--> <a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> --> <a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> --> >>--> --> >>_______________________________________________ --> >>rbridge mailing list --> >><a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> <a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> --> >> --> >> --> >> --> >> --> >_______________________________________________ --> >rbridge mailing list --> ><a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> --> ><a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> --> > --> > --> --> _______________________________________________ --> rbridge mailing list --> <a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> --> <a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> --> _______________________________________________ rbridge mailing list <a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> <a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> </pre> </blockquote> <pre wrap=""><!---->_______________________________________________ rbridge mailing list <a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> <a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a> </pre> </blockquote> </body> </html> --Boundary_(ID_1cW9761bbl6Yh/fho+frXA)-- 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 j9PEiPL29913 for <rbridge@postel.org>; Tue, 25 Oct 2005 07:44:27 -0700 (PDT) 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 j9PEiJp1012289 for <rbridge@postel.org>; Tue, 25 Oct 2005 10:44:19 -0400 (EDT) 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 KAA29987 for <rbridge@postel.org>; Tue, 25 Oct 2005 10:44:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX9MXJ>; Tue, 25 Oct 2005 11:44:18 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C886006@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, 25 Oct 2005 11:44:13 -0300 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 j9PEiPL29913 Subject: Re: [rbridge] RBridge/bridge interaction 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, 25 Oct 2005 14:46:49 -0000 Status: RO Content-Length: 9044 Guillermo, Thank-you for the suggested text! -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Tuesday, October 25, 2005 5:56 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> Eric, Radia : --> --> According to Eric suggestion to include text, I have used --> Radia?s text --> (as clarifying as usual) to describe it and added a final --> sentence (not --> mandatory) on the default value for RBridges. Feel free to --> "improve" it. --> Guillermo --> --> --> RBridge indirect participation in bridged island spanning tree. --> --------------------------------------------------------------- --> RBridges by default do not participate in spanning tree in --> other way than ignoring received BPDUs. It is an objective --> of RBridge specification to be independent of bridges --> specifications as much as possible. --> However it may be convenient for RBridges in some --> circumstances to participate in the spanning tree and --> contend to be root bridge of the spanning tree formed in --> the bridged island they are attached to. In these cases it --> is possible to build a device that's logically the same as --> a bridge glued onto an RBridge. The following schema applies: --> --> ?-----------? --> bridged island-----B1----RB1 ? --> ?-----------? --> --> RBridge/bridge box --> --> where B1 is a bridge with two ports...a pt-to-pt link to --> RBRidge RB1, and a link to the bridged LAN. The "RB1" --> portion of this box acts as an standard RBridge, it neither --> forwards, nor initiates spanning tree messages. The "B1" --> portion acts as two-port standard 802.1D bridge, and does --> participate in spanning tree. Its priority for root --> election can be set in the standard way. To minimize --> configurafion, it may be convenient in some implementations --> to make the standard B1 bridge priority a function of the --> configurable RBridge priority for IS-IS Designated RBridge --> election. In this way Designated RBridge will participate --> and contend (as B1) to be elected also as root bridge of --> the bridged island and only one priority configuration is required. --> --> If (in environments using such implementations) the default --> bridge priority for B1 is lower than standard bridge --> priority, by default RBridges/bridges like B1 shown will --> become roots of their bridged islands, contending only with --> other RBridges connected to same island for root election. --> --> --> --> --> Gray, Eric wrote: --> --> >I think we should leave that sort of determination to the --> >supposed wisdom of the successful implementer. But I won't --> >object to text along these lines if someone else wants to --> >write it... --> > --> >-- --> >Eric --> > --> >--> -----Original Message----- --> >--> From: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org]On --> >--> Behalf Of Radia Perlman --> >--> Sent: Saturday, October 22, 2005 4:59 PM --> >--> To: Developing a hybrid router/bridge. --> >--> Subject: Re: [rbridge] RBridge/bridge interaction --> >--> --> >--> --> >--> And another thought. Although I don't think we should --> >--> include the notion of --> >--> a combined bridge/RBridge in the spec for RBridges, --> >--> just a suggestion for anyone that wants to build this beast... --> >--> --> >--> It would be nice to minimize configuration, so especially --> >--> if the reason --> >--> for making a --> >--> bridge/RBridge is to --> >--> make an RBridge have higher priority for being bridge --> spanning tree --> >--> Root, have the priority for --> >--> bridge Root be a function of the RBridge IS-IS DR priority, --> >--> so you only --> >--> have to set one --> >--> of them. --> >--> --> >--> We don't have to debate this, since this if it's not --> in the RBridge --> >--> spec, vendors can --> >--> do whatever they want. But it's perhaps good to have --> >--> suggestions posted --> >--> publicly. --> >--> --> >--> Radia --> >--> --> >--> --> >--> --> >--> Peter Ashwood-Smith wrote: --> >--> --> >--> >Likewise. --> >--> > --> >--> > --> >--> > --> >--> >>-----Original Message----- --> >--> >>From: rbridge-bounces@postel.org --> >--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric --> >--> >>Sent: Friday, October 21, 2005 6:16 PM --> >--> >>To: 'Developing a hybrid router/bridge.' --> >--> >>Subject: Re: [rbridge] RBridge/bridge interaction --> >--> >> --> >--> >> --> >--> >>I also agree that this is a quite feasible approach. --> >--> >> --> >--> >>-- --> >--> >>Eric --> >--> >> --> >--> >>--> -----Original Message----- --> >--> >>--> From: rbridge-bounces@postel.org --> >--> >>--> [mailto:rbridge-bounces@postel.org]On --> >--> >>--> Behalf Of Guillermo Ib??ez --> >--> >>--> Sent: Friday, October 21, 2005 6:01 PM --> >--> >>--> To: Developing a hybrid router/bridge. --> >--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >--> >>--> --> >--> >>--> --> >--> >>--> Right. In this way both views are covered. I --> fully agree. --> >--> >>Guillermo --> >--> >>--> --> >--> >>--> Radia Perlman wrote: --> >--> >>--> --> >--> >>--> >Actually, here's a suggestion that may make us --> all happy. --> >--> >>--> > --> >--> >>--> >Keep the design of RBridge independent of bridges. --> >--> >>RBridges do not --> >--> >>--> >participate --> >--> >>--> >in spanning tree (other than throwing away BPDUs). --> >--> >>--> > --> >--> >>--> >However, to get the functionality that Guillermo --> >--> >>--> wants....allow someone --> >--> >>--> >to build a device that's logically the --> >--> >>--> >same as a bridge glued onto an RBridge. To the --> rest of the --> >--> >>--> world it --> >--> >>--> >would look --> >--> >>--> >like this: --> >--> >>--> > --> >--> >>--> >bridged island----B1----RB1 --> >--> >>--> > --> >--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to --> >--> >>--> RBRidge RB1, --> >--> >>--> >and a link to the --> >--> >>--> >bridged LAN. --> >--> >>--> > --> >--> >>--> >The "RB1" portion of this box does what the architecture --> >--> >>--> of an RBridge --> >--> >>--> >does...it neither --> >--> >>--> >forwards, nor initiates spanning tree messages. --> >--> >>--> > --> >--> >>--> >However, the "B1" portion of the box acts like a vanilla --> >--> >>--> bridge, and --> >--> >>--> >does participate in --> >--> >>--> >spanning tree. And it can be configured to have whatever --> >--> >>--> priority people --> >--> >>--> >want. --> >--> >>--> > --> >--> >>--> >If it's commercially important for RBridges to have the --> >--> >>--> capability of --> >--> >>--> >participating in --> >--> >>--> >the bridge protocol, it can be done this way without --> >--> >>--> defining it into --> >--> >>--> >either the RBridge --> >--> >>--> >or bridge functionality. --> >--> >>--> > --> >--> >>--> >Radia --> >--> >>--> > --> >--> >>--> > --> >--> >>--> > --> >--> >>--> >Guillermo Ib??ez wrote: --> >--> >>--> > --> >--> >>--> > --> >--> >>--> > --> >--> >>--> >>Root bridge planning is something required in campus --> >--> >>--> networks, it just --> >--> >>--> >>means configure the 16 bit priority of the --> preffered root --> >--> >>--> bridge (and --> >--> >>--> >>perhaps a root reserve) with a low enough --> value under the --> >--> >>--> default value. --> >--> >>--> >> --> >--> >>--> >> --> >--> >>--> >> --> >--> >>--> > --> >--> >>--> > --> >--> >>--> >_______________________________________________ --> >--> >>--> >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 --> >--> > --> >--> > --> >--> --> >--> _______________________________________________ --> >--> 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 j9PE3GL18731 for <rbridge@postel.org>; Tue, 25 Oct 2005 07:03:16 -0700 (PDT) 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 j9PE39p1011235 for <rbridge@postel.org>; Tue, 25 Oct 2005 10:03:10 -0400 (EDT) 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 KAA24461 for <rbridge@postel.org>; Tue, 25 Oct 2005 10:03:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX9LN9>; Tue, 25 Oct 2005 11:03:08 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C886002@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, 25 Oct 2005 11:02:58 -0300 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 j9PE3GL18731 Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl e 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, 25 Oct 2005 14:03:47 -0000 Status: RO Content-Length: 6184 Guillermo, I am not sure where you get the statement "the goal now is to get rid of IP address dependencies." You assert this, but that does not make it true. As far as I know, the goal has been - and yet remains - to make the solution as near "zero configuration" as possible, including actual "zero configuration" in at least some (possibly simplistic) deployment scenarios. If we look back over previous discussion(s), it seems clear that one of the reasons for undertaking this effort is to merge the at least near-zero configuration of bridges with efficient link utilization typical of shortest path routing. Do people think that has changed? -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Tuesday, October 25, 2005 7:29 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now --> availabl e --> --> --> Eric, --> --> Gray, Eric wrote: --> --> >Guillermo, --> > --> > We should talk - possibly off-line - about word-smithing --> >the text around STP/RSTP. I would prefer not to try to guess --> >what people would like me to say about this (or other) issue(s). --> >For one thing, it would be nice if you could provide detailed --> >references (organization, authors - if listed - dates, etc.). --> > --> > --> > Bearing in mind that this document is aimed at nailing --> >down what the requirements are for routing protocol - extensions, --> >compatibility, etc. - we should not spend to much time and energy --> >on making sure that what this draft says on non-routing related --> >reuirements. --> > --> Agree --> --> >Instead, I think we should make sure that the set --> >of drafts/RFCs that the WG develops are consistent. Admittedly, --> >since the over-all requirements, framework and architecture IDs --> >are not out yet, this is the current draft to address such issues --> >with. However, the wording in this draft reflects the original --> >words in the draft cited in the WG charter. --> > --> > As for "zero configuration", this is a goal. If we cannot --> >achieve it, that is one thing - but I do not think we want to --> >start by weasle-wording our goals. --> > --> I was just trying to be precise, the goal now is get rid of IP --> addresses dependencies. --> --> > I don't think anyone believes --> >we're going to get by with zero-configuration in every case, but --> >then we're not saying that this goal MUST be achieved in every --> >case. So, I think we should not complicate our goals by overly --> >qualifying them too much. Down that way is a slippery slope... --> > --> > --> > --> Well, I think that when zero configuration was stated, only --> referred to --> IP addresses and subnetting independency. --> When VLAN configuration issue has been identified, it has --> been excluded --> from the WG (assume some external method or tool is used). As VLAN --> configuration is among the most significant efforts, it is --> misleading to --> continue using the general term --> zero-configuration without precision of what is meant. --> --> >-- --> >Eric --> > --> >--> -----Original Message----- --> >--> From: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org]On --> >--> Behalf Of Guillermo Ib??ez --> >--> Sent: Monday, October 24, 2005 6:48 AM --> >--> To: Developing a hybrid router/bridge. --> >--> Subject: Re: [rbridge] R-Bridge Routing Requirements --> draft is now --> >--> available --> >--> --> >--> --> >--> Eric, --> >--> Some comments on draft, --> >--> - When mentioning Spanning Tree Protocol (STP), is --> convenient to --> >--> distinguish and/or mention both spanning tree protocols : --> >--> legacy STP and --> >--> Rapid Spanning Tree Protocol RSTP (802.1D). In general, I --> >--> recommend to --> >--> use the term RSTP for clarity whenever possible and add a --> >--> sentence like: --> >--> "...The current IEEE standard specifies RSTP, although both --> >--> STP and RSTP --> >--> bridges will exist and must be supported.... --> >--> - In the abstract, "zero configuration" is mentioned. If --> >--> VLANs must be --> >--> configured, I do not think real zero configuration can be --> >--> claimed. May --> >--> be it should say "zero IP addresses/subnets configuration" --> >--> or something --> >--> like that. --> >--> - Some name or acronym for the spanning trees between --> >--> Rbridges would --> >--> help to reduce the confusion created by two types of --> spanning trees --> >--> coexisting : STP(RSTP) and between Rbridges. A --> >--> possibility is to call --> >--> them *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees). --> >--> --> >--> Guillermo --> >--> --> >--> --> >--> --> >--> Gray, Eric wrote: --> >--> --> >--> >The draft "Routing Requirements in Support of R-Bridges" - --> >--> submitted last --> >--> >Friday - is now available at: --> >--> > --> >--> >http://www.ietf.org/internet-drafts/draft-gray-rbridge-rout --> >ing-reqs-00.txt --> > --> > --> >>This draft borrows heavily from the earlier --> draft-perlman-rbridge-03.txt --> >>and is very preliminary. I am looking for input for the --> various sections --> >>- particularly those that currently only contain "TBD" :-) --> >> --> >>This was one of the drafts that the working group felt --> would be required --> >>at the last meeting. --> >> --> >>-- --> >>Eric Gray --> >>_______________________________________________ --> >>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 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 j9PDSNL08744 for <rbridge@postel.org>; Tue, 25 Oct 2005 06:28:24 -0700 (PDT) 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 j9PDSHp1010050 for <rbridge@postel.org>; Tue, 25 Oct 2005 09:28:17 -0400 (EDT) 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 JAA18724 for <rbridge@postel.org>; Tue, 25 Oct 2005 09:28:16 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX9KAF>; Tue, 25 Oct 2005 10:28:16 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FFE@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, 25 Oct 2005 10:28:13 -0300 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] R-Bridge Routing Requirements draft is now availabl e 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, 25 Oct 2005 13:29:25 -0000 Status: RO Content-Length: 2720 Harald, The difference between flooding and broadcast is not really small, nor is it necessarily a nit. Flooding is a bridge-local phenomena associated with bridge learning, and not with explicitly multicast/broadcast traffic. People frequently equate it with broadcast because that is the worst-case for consideration in most bridging concerns. Flooding stops at each point along the spanning tree where the destination address has already been learned, or has not yet been aged out. That behavior is substantially different from either multicast or broadcast distribution. Also, we need to be careful when classifying one thing as a "special case" of another. Some people once classified VPN services as a "special case" of traffic engineering. It is altogether too easy to fall into a mental snare that way. For example, in this case (considering broadcast, multi- cast and flooding), broadcast is the simplest thing to do and multicast and flooding are both different variations of it. In each case (multicast verses flooding), there is a method (or circumstance) under which propagation terminates early in comparison with broadcast. To do broadcast, you need neither of these two complications; to do either multicast or flooding, you need not include the capability to do the other. Consequently, we would be better off thinking of flooding and multicast as distinct "special cases" of broadcast. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Harald Tveit Alvestrand --> Sent: Monday, October 24, 2005 10:54 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now --> availabl e --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier, you wrote: --On 24. oktober 2005 13:28 -0300 "Gray, Eric" <Eric.Gray@marconi.com> wrote: > Harald, > > I am not sure that multicast distribution trees is going > to be sufficiently unambiguous. There will be both multicast > and flooding to take into account and these are not the same. I was thinking of broadcast ("flooding") as a special kind of multicast..... I don't know how, inside the rbridge cloud, distributing to the "all RBridges" multicast is different from distributing a broadcast. But that's a nit, and may be obvious once the drafts are out. for the unicast stuff, I think it makes sense to abandon the "tree" term, just because using the term makes people think of the particular way in which the RSTP algorithm configures forwarding tables in bridges..... 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 j9PBSvL04561 for <rbridge@postel.org>; Tue, 25 Oct 2005 04:28:58 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B72C09D339 for <rbridge@postel.org>; Tue, 25 Oct 2005 13:28:51 +0200 (CEST) Received: from [163.117.139.228] (gibanez.it.uc3m.es [163.117.139.228]) by smtp01.uc3m.es (Postfix) with ESMTP id 8D8139D343 for <rbridge@postel.org>; Tue, 25 Oct 2005 13:28:50 +0200 (CEST) Message-ID: <435E16F2.2050101@it.uc3m.es> Date: Tue, 25 Oct 2005 13:28:50 +0200 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: <313680C9A886D511A06000204840E1CF0C885FE7@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FE7@whq-msgusr-02.pit.comms.marconi.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] R-Bridge Routing Requirements draft is now availabl e 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, 25 Oct 2005 11:29:24 -0000 Status: RO Content-Length: 4460 Eric, Gray, Eric wrote: >Guillermo, > > We should talk - possibly off-line - about word-smithing >the text around STP/RSTP. I would prefer not to try to guess >what people would like me to say about this (or other) issue(s). >For one thing, it would be nice if you could provide detailed >references (organization, authors - if listed - dates, etc.). > > > Bearing in mind that this document is aimed at nailing >down what the requirements are for routing protocol - extensions, >compatibility, etc. - we should not spend to much time and energy >on making sure that what this draft says on non-routing related >reuirements. > Agree >Instead, I think we should make sure that the set >of drafts/RFCs that the WG develops are consistent. Admittedly, >since the over-all requirements, framework and architecture IDs >are not out yet, this is the current draft to address such issues >with. However, the wording in this draft reflects the original >words in the draft cited in the WG charter. > > As for "zero configuration", this is a goal. If we cannot >achieve it, that is one thing - but I do not think we want to >start by weasle-wording our goals. > I was just trying to be precise, the goal now is get rid of IP addresses dependencies. > I don't think anyone believes >we're going to get by with zero-configuration in every case, but >then we're not saying that this goal MUST be achieved in every >case. So, I think we should not complicate our goals by overly >qualifying them too much. Down that way is a slippery slope... > > > Well, I think that when zero configuration was stated, only referred to IP addresses and subnetting independency. When VLAN configuration issue has been identified, it has been excluded from the WG (assume some external method or tool is used). As VLAN configuration is among the most significant efforts, it is misleading to continue using the general term zero-configuration without precision of what is meant. >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Guillermo Ib??ez >--> Sent: Monday, October 24, 2005 6:48 AM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now >--> available >--> >--> >--> Eric, >--> Some comments on draft, >--> - When mentioning Spanning Tree Protocol (STP), is convenient to >--> distinguish and/or mention both spanning tree protocols : >--> legacy STP and >--> Rapid Spanning Tree Protocol RSTP (802.1D). In general, I >--> recommend to >--> use the term RSTP for clarity whenever possible and add a >--> sentence like: >--> "...The current IEEE standard specifies RSTP, although both >--> STP and RSTP >--> bridges will exist and must be supported.... >--> - In the abstract, "zero configuration" is mentioned. If >--> VLANs must be >--> configured, I do not think real zero configuration can be >--> claimed. May >--> be it should say "zero IP addresses/subnets configuration" >--> or something >--> like that. >--> - Some name or acronym for the spanning trees between >--> Rbridges would >--> help to reduce the confusion created by two types of spanning trees >--> coexisting : STP(RSTP) and between Rbridges. A >--> possibility is to call >--> them *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees). >--> >--> Guillermo >--> >--> >--> >--> Gray, Eric wrote: >--> >--> >The draft "Routing Requirements in Support of R-Bridges" - >--> submitted last >--> >Friday - is now available at: >--> > >--> >http://www.ietf.org/internet-drafts/draft-gray-rbridge-rout >ing-reqs-00.txt > > >>This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt >>and is very preliminary. I am looking for input for the various sections >>- particularly those that currently only contain "TBD" :-) >> >>This was one of the drafts that the working group felt would be required >>at the last meeting. >> >>-- >>Eric Gray >>_______________________________________________ >>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 smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9P9xSL13628 for <rbridge@postel.org>; Tue, 25 Oct 2005 02:59:28 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3393F82016 for <rbridge@postel.org>; Tue, 25 Oct 2005 11:59:22 +0200 (CEST) Received: from [163.117.139.228] (gibanez.it.uc3m.es [163.117.139.228]) by smtp03.uc3m.es (Postfix) with ESMTP id E855581FF5 for <rbridge@postel.org>; Tue, 25 Oct 2005 11:59:21 +0200 (CEST) Message-ID: <435E01F9.7090202@it.uc3m.es> Date: Tue, 25 Oct 2005 11:59:21 +0200 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: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 25 Oct 2005 10:00:21 -0000 Status: RO Content-Length: 7505 Eric, Radia : I have use Radia?s text as much as possible to describe it as a first proposal and added a final sentence on the default value for RBridges. Feel free to correct english expressions. Guillermo RBridge indirect participation in bridged island spanning tree. --------------------------------------------------------------- RBridges by default do not participate in spanning tree in other way than ignoring received BPDUs. It is an objective of RBridge specification to be independent of bridges specifications as much as possible. However it may be convenient for RBridges in some circumstances to participate in the spanning tree and contend to be root bridge of the spanning tree formed in the bridged island they are attached to. In these cases it is possible to build a device that's logically the same as a bridge glued onto an RBridge. The following schema applies: ?-----------? bridged island-----B1----RB1 ? ?-----------? RBridge/bridge box where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box acts as an standard RBridge, it neither forwards, nor initiates spanning tree messages. The "B1" portion acts as two-port standard 802.1D bridge, and does participate in spanning tree. Its priority for root election can be set in the standard way. To minimize configurafion, it may be convenient in some implementations to make the standard B1 bridge priority a function of the configurable RBridge priority for IS-IS Designated RBridge election. In this way Designated RBridge will participate and contend (as B1) to be elected also as root bridge of the bridged island and only one priority configuration is required. In environments using such implementations, if the default bridge priority for B1 is lower than standard bridges priority, RBridges/bridges like B1 will become roots of their bridged islands, contending only with other RBridges connected to same island for root election. Gray, Eric wrote: >I think we should leave that sort of determination to the >supposed wisdom of the successful implementer. But I won't >object to text along these lines if someone else wants to >write it... > >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Radia Perlman >--> Sent: Saturday, October 22, 2005 4:59 PM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> And another thought. Although I don't think we should >--> include the notion of >--> a combined bridge/RBridge in the spec for RBridges, >--> just a suggestion for anyone that wants to build this beast... >--> >--> It would be nice to minimize configuration, so especially >--> if the reason >--> for making a >--> bridge/RBridge is to >--> make an RBridge have higher priority for being bridge spanning tree >--> Root, have the priority for >--> bridge Root be a function of the RBridge IS-IS DR priority, >--> so you only >--> have to set one >--> of them. >--> >--> We don't have to debate this, since this if it's not in the RBridge >--> spec, vendors can >--> do whatever they want. But it's perhaps good to have >--> suggestions posted >--> publicly. >--> >--> Radia >--> >--> >--> >--> Peter Ashwood-Smith wrote: >--> >--> >Likewise. >--> > >--> > >--> > >--> >>-----Original Message----- >--> >>From: rbridge-bounces@postel.org >--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric >--> >>Sent: Friday, October 21, 2005 6:16 PM >--> >>To: 'Developing a hybrid router/bridge.' >--> >>Subject: Re: [rbridge] RBridge/bridge interaction >--> >> >--> >> >--> >>I also agree that this is a quite feasible approach. >--> >> >--> >>-- >--> >>Eric >--> >> >--> >>--> -----Original Message----- >--> >>--> From: rbridge-bounces@postel.org >--> >>--> [mailto:rbridge-bounces@postel.org]On >--> >>--> Behalf Of Guillermo Ib??ez >--> >>--> Sent: Friday, October 21, 2005 6:01 PM >--> >>--> To: Developing a hybrid router/bridge. >--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >>--> >--> >>--> >--> >>--> Right. In this way both views are covered. I fully agree. >--> >>Guillermo >--> >>--> >--> >>--> Radia Perlman wrote: >--> >>--> >--> >>--> >Actually, here's a suggestion that may make us all happy. >--> >>--> > >--> >>--> >Keep the design of RBridge independent of bridges. >--> >>RBridges do not >--> >>--> >participate >--> >>--> >in spanning tree (other than throwing away BPDUs). >--> >>--> > >--> >>--> >However, to get the functionality that Guillermo >--> >>--> wants....allow someone >--> >>--> >to build a device that's logically the >--> >>--> >same as a bridge glued onto an RBridge. To the rest of the >--> >>--> world it >--> >>--> >would look >--> >>--> >like this: >--> >>--> > >--> >>--> >bridged island----B1----RB1 >--> >>--> > >--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to >--> >>--> RBRidge RB1, >--> >>--> >and a link to the >--> >>--> >bridged LAN. >--> >>--> > >--> >>--> >The "RB1" portion of this box does what the architecture >--> >>--> of an RBridge >--> >>--> >does...it neither >--> >>--> >forwards, nor initiates spanning tree messages. >--> >>--> > >--> >>--> >However, the "B1" portion of the box acts like a vanilla >--> >>--> bridge, and >--> >>--> >does participate in >--> >>--> >spanning tree. And it can be configured to have whatever >--> >>--> priority people >--> >>--> >want. >--> >>--> > >--> >>--> >If it's commercially important for RBridges to have the >--> >>--> capability of >--> >>--> >participating in >--> >>--> >the bridge protocol, it can be done this way without >--> >>--> defining it into >--> >>--> >either the RBridge >--> >>--> >or bridge functionality. >--> >>--> > >--> >>--> >Radia >--> >>--> > >--> >>--> > >--> >>--> > >--> >>--> >Guillermo Ib??ez wrote: >--> >>--> > >--> >>--> > >--> >>--> > >--> >>--> >>Root bridge planning is something required in campus >--> >>--> networks, it just >--> >>--> >>means configure the 16 bit priority of the preffered root >--> >>--> bridge (and >--> >>--> >>perhaps a root reserve) with a low enough value under the >--> >>--> default value. >--> >>--> >> >--> >>--> >> >--> >>--> >> >--> >>--> > >--> >>--> > >--> >>--> >_______________________________________________ >--> >>--> >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 >--> > >--> > >--> >--> _______________________________________________ >--> 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 smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9P9tjL12363 for <rbridge@postel.org>; Tue, 25 Oct 2005 02:55:46 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 92CC881F2E for <rbridge@postel.org>; Tue, 25 Oct 2005 11:55:39 +0200 (CEST) Received: from [163.117.139.228] (gibanez.it.uc3m.es [163.117.139.228]) by smtp03.uc3m.es (Postfix) with ESMTP id 922D981FFF for <rbridge@postel.org>; Tue, 25 Oct 2005 11:55:38 +0200 (CEST) Message-ID: <435E011A.4000805@it.uc3m.es> Date: Tue, 25 Oct 2005 11:55:38 +0200 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: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FE5@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 25 Oct 2005 09:56:23 -0000 Status: RO Content-Length: 7551 Eric, Radia : According to Eric suggestion to include text, I have used Radia?s text (as clarifying as usual) to describe it and added a final sentence (not mandatory) on the default value for RBridges. Feel free to "improve" it. Guillermo RBridge indirect participation in bridged island spanning tree. --------------------------------------------------------------- RBridges by default do not participate in spanning tree in other way than ignoring received BPDUs. It is an objective of RBridge specification to be independent of bridges specifications as much as possible. However it may be convenient for RBridges in some circumstances to participate in the spanning tree and contend to be root bridge of the spanning tree formed in the bridged island they are attached to. In these cases it is possible to build a device that's logically the same as a bridge glued onto an RBridge. The following schema applies: ?-----------? bridged island-----B1----RB1 ? ?-----------? RBridge/bridge box where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box acts as an standard RBridge, it neither forwards, nor initiates spanning tree messages. The "B1" portion acts as two-port standard 802.1D bridge, and does participate in spanning tree. Its priority for root election can be set in the standard way. To minimize configurafion, it may be convenient in some implementations to make the standard B1 bridge priority a function of the configurable RBridge priority for IS-IS Designated RBridge election. In this way Designated RBridge will participate and contend (as B1) to be elected also as root bridge of the bridged island and only one priority configuration is required. If (in environments using such implementations) the default bridge priority for B1 is lower than standard bridge priority, by default RBridges/bridges like B1 shown will become roots of their bridged islands, contending only with other RBridges connected to same island for root election. Gray, Eric wrote: >I think we should leave that sort of determination to the >supposed wisdom of the successful implementer. But I won't >object to text along these lines if someone else wants to >write it... > >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Radia Perlman >--> Sent: Saturday, October 22, 2005 4:59 PM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> And another thought. Although I don't think we should >--> include the notion of >--> a combined bridge/RBridge in the spec for RBridges, >--> just a suggestion for anyone that wants to build this beast... >--> >--> It would be nice to minimize configuration, so especially >--> if the reason >--> for making a >--> bridge/RBridge is to >--> make an RBridge have higher priority for being bridge spanning tree >--> Root, have the priority for >--> bridge Root be a function of the RBridge IS-IS DR priority, >--> so you only >--> have to set one >--> of them. >--> >--> We don't have to debate this, since this if it's not in the RBridge >--> spec, vendors can >--> do whatever they want. But it's perhaps good to have >--> suggestions posted >--> publicly. >--> >--> Radia >--> >--> >--> >--> Peter Ashwood-Smith wrote: >--> >--> >Likewise. >--> > >--> > >--> > >--> >>-----Original Message----- >--> >>From: rbridge-bounces@postel.org >--> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric >--> >>Sent: Friday, October 21, 2005 6:16 PM >--> >>To: 'Developing a hybrid router/bridge.' >--> >>Subject: Re: [rbridge] RBridge/bridge interaction >--> >> >--> >> >--> >>I also agree that this is a quite feasible approach. >--> >> >--> >>-- >--> >>Eric >--> >> >--> >>--> -----Original Message----- >--> >>--> From: rbridge-bounces@postel.org >--> >>--> [mailto:rbridge-bounces@postel.org]On >--> >>--> Behalf Of Guillermo Ib??ez >--> >>--> Sent: Friday, October 21, 2005 6:01 PM >--> >>--> To: Developing a hybrid router/bridge. >--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >>--> >--> >>--> >--> >>--> Right. In this way both views are covered. I fully agree. >--> >>Guillermo >--> >>--> >--> >>--> Radia Perlman wrote: >--> >>--> >--> >>--> >Actually, here's a suggestion that may make us all happy. >--> >>--> > >--> >>--> >Keep the design of RBridge independent of bridges. >--> >>RBridges do not >--> >>--> >participate >--> >>--> >in spanning tree (other than throwing away BPDUs). >--> >>--> > >--> >>--> >However, to get the functionality that Guillermo >--> >>--> wants....allow someone >--> >>--> >to build a device that's logically the >--> >>--> >same as a bridge glued onto an RBridge. To the rest of the >--> >>--> world it >--> >>--> >would look >--> >>--> >like this: >--> >>--> > >--> >>--> >bridged island----B1----RB1 >--> >>--> > >--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to >--> >>--> RBRidge RB1, >--> >>--> >and a link to the >--> >>--> >bridged LAN. >--> >>--> > >--> >>--> >The "RB1" portion of this box does what the architecture >--> >>--> of an RBridge >--> >>--> >does...it neither >--> >>--> >forwards, nor initiates spanning tree messages. >--> >>--> > >--> >>--> >However, the "B1" portion of the box acts like a vanilla >--> >>--> bridge, and >--> >>--> >does participate in >--> >>--> >spanning tree. And it can be configured to have whatever >--> >>--> priority people >--> >>--> >want. >--> >>--> > >--> >>--> >If it's commercially important for RBridges to have the >--> >>--> capability of >--> >>--> >participating in >--> >>--> >the bridge protocol, it can be done this way without >--> >>--> defining it into >--> >>--> >either the RBridge >--> >>--> >or bridge functionality. >--> >>--> > >--> >>--> >Radia >--> >>--> > >--> >>--> > >--> >>--> > >--> >>--> >Guillermo Ib??ez wrote: >--> >>--> > >--> >>--> > >--> >>--> > >--> >>--> >>Root bridge planning is something required in campus >--> >>--> networks, it just >--> >>--> >>means configure the 16 bit priority of the preffered root >--> >>--> bridge (and >--> >>--> >>perhaps a root reserve) with a low enough value under the >--> >>--> default value. >--> >>--> >> >--> >>--> >> >--> >>--> >> >--> >>--> > >--> >>--> > >--> >>--> >_______________________________________________ >--> >>--> >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 >--> > >--> > >--> >--> _______________________________________________ >--> 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 eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9P35qL01344 for <rbridge@postel.org>; Mon, 24 Oct 2005 20:05:53 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB8DF258079 for <rbridge@postel.org>; Tue, 25 Oct 2005 05:05:13 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26545-02 for <rbridge@postel.org>; Tue, 25 Oct 2005 05:05:09 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 01D62258077 for <rbridge@postel.org>; Tue, 25 Oct 2005 05:05:07 +0200 (CEST) Date: Mon, 24 Oct 2005 19:53:40 -0700 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <38C2DF2445CA93637959F416@B50854F0A9192E8EC6CDA126> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FE8@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885FE8@whq-msgusr-02.pit.comm s.marconi.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========60CF60F89C2539DAE611==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl e 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, 25 Oct 2005 03:06:23 -0000 Status: RO Content-Length: 1316 --==========60CF60F89C2539DAE611========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 24. oktober 2005 13:28 -0300 "Gray, Eric" <Eric.Gray@marconi.com>=20 wrote: > Harald, > > I am not sure that multicast distribution trees is going > to be sufficiently unambiguous. There will be both multicast > and flooding to take into account and these are not the same. I was thinking of broadcast ("flooding") as a special kind of=20 multicast..... I don't know how, inside the rbridge cloud, distributing to=20 the "all RBridges" multicast is different from distributing a broadcast.=20 But that's a nit, and may be obvious once the drafts are out. for the unicast stuff, I think it makes sense to abandon the "tree" term,=20 just because using the term makes people think of the particular way in=20 which the RSTP algorithm configures forwarding tables in bridges..... --==========60CF60F89C2539DAE611========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDXZ40OMj+2+WY0F4RAiu1AJwNuhGTKM54h+WIUgrLTu+h21T9pwCgvp1p jQecvoumjv17yypflNdo/80= =fjhE -----END PGP SIGNATURE----- --==========60CF60F89C2539DAE611==========-- 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 j9OJOSL15855 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:24:29 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D98D39D2DE for <rbridge@postel.org>; Mon, 24 Oct 2005 21:24:22 +0200 (CEST) Received: from 11B111 (unknown [163.117.54.184]) by smtp01.uc3m.es (Postfix) with ESMTP id 550F69D2E3 for <rbridge@postel.org>; Mon, 24 Oct 2005 21:24:22 +0200 (CEST) From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <gibanez@it.uc3m.es> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 24 Oct 2005 21:24:22 +0200 Message-ID: <000001c5d8d0$8a0afbe0$b83675a3@ad.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <435CF876.2080708@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9OJOSL15855 Subject: Re: [rbridge] RBridge/bridge interaction 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, 24 Oct 2005 19:25:18 -0000 Status: RO Content-Length: 2958 -----Mensaje original----- De: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] En nombre de Erik Nordmark Enviado el: lunes, 24 de octubre de 2005 17:07 Para: Developing a hybrid router/bridge. CC: Radia.Perlman@sun.com Asunto: Re: [rbridge] RBridge/bridge interaction Guillermo Ib??ez wrote: > I see the standard root election mechanism of spanning tree islands as > the fastest and simpler mechanism for DR Rbridge designation. I see the > DR Rbridge as being necessarily the ROOT bridge of that sbridged cloud > (or "link"). The root bridge of a standard spanning tree is the > "natural" source and sink point for the spanning tree. To do so, the DR > must issue BPDUs to become the root bridge. This is part of what I > mentioned days ago as PARTICIPATE PER PORT, but may be we should call it > SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs > to contend to be the root bridge of the link). > The consequence of this DR election mechanism is that the priority > configured at Rbridges as bridge ID would determine their also their > election priority as DRs. I think this keep both domains coordinated > with a single mechanism. But I don't think it is possible in 802.1D to guarantee that the RBridges become the 802.1D root bridges as seen from the bridges. It could be that there is one or more bridges that are configured so that they are the most likely to be selected as 802.1D root bridges. GI> If priority is configured with very low value, this is unlikely to happen. It is the network administrator who decides when setting the bridges priorities. If nothing is configured, the default priority value is in the middle of the range, so if the default priority value for Rbridges is lower, one Rbridge will be always root if nothing specially configured. GI> May be the term "necessarily" is excesive. The reason to contend as root bridges is two fold: optimize paths and ensure uniqueness and fast election of DR Rbridge via root bridge election, linking both processes. This also may improve network predictability and understability, although I do not know details on the pros and cons of standar IS-IS DR election. My understanding is that it is slower and requires the spanning tree established. Root bridge election DOES NOT Require the spanning tree established and forwarding frames. This might be the MAIN argument in favour of using root bridge election for DR Rbridge designation. Presumably we'd want RBridges to function even when applied to such a network (even though the paths might not be "optimal"). GI> I agree, it can not be mandatory. Erik GI> With Radia's proposal of an optional combined implementation Rbridge+ bridge, it can be set up this way. The bridge participates and contends to be root. GI> Guillermo _______________________________________________ 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 j9OGSlL17168 for <rbridge@postel.org>; Mon, 24 Oct 2005 09:28:47 -0700 (PDT) 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 j9OGSUp1021622 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:28:31 -0400 (EDT) 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 MAA28506 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:28:30 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX8L8T>; Mon, 24 Oct 2005 13:28:29 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FE8@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, 24 Oct 2005 13:28:26 -0300 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 j9OGSlL17168 Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl e 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, 24 Oct 2005 16:29:16 -0000 Status: RO Content-Length: 2604 Harald, I am not sure that multicast distribution trees is going to be sufficiently unambiguous. There will be both multicast and flooding to take into account and these are not the same. Also, I agree with the statement that RBridges will be creating a DAG, not a spanning tree. To people familar with STP, however, it is hard to get their head wrapped around the differences. And - once they start to - these differences seem like anathema to the L2-thinker because they "may" not be compatible with STP. This has been - I am sure - a big part of the confusion in terminology in previous discussion. In that same dicussion, I had tried to get people using SPST - Shortest Path Spanning Tree - as a way to help people realize that it is not quite the same thing. For an example of where this gets very complicated, look at the discussion of "how many trees?" If we're talking about real "spanning trees", then the answer has to be exactly one. Otherwise, we will get mired in discussions of virtual IS-IS routers because there will have to be a different link-state applied to links between RBridges - depending on which spanning tree is used to create any given link within, for instance, a VLAN context. On the other hand, if we're talking about the effective spanning trees that result from creating a DAG via IS-IS shortest path computations, then there may be any number of such spanning trees. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Harald Tveit Alvestrand --> Sent: Monday, October 24, 2005 8:00 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now --> available --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier, you wrote: --On 24. oktober 2005 12:48 +0200 Guillermo Ibáñez <gibanez@it.uc3m.es> wrote: > - Some name or acronym for the spanning trees between Rbridges would > help to reduce the confusion created by two types of spanning trees > coexisting : STP(RSTP) and between Rbridges. A possibility is to call > them *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees) why not name them for their function, and call them multicast distribution trees? It's after all an essential point of the design that the unicast packets do NOT have to follow the spanning trees; the unicast routing tables will form a directed acyclic graph (DAG), not a tree. Harald 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 j9OGC6L12078 for <rbridge@postel.org>; Mon, 24 Oct 2005 09:12:06 -0700 (PDT) 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 j9OGBvp1021305 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:11:57 -0400 (EDT) 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 MAA26405 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:11:57 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX8LLX>; Mon, 24 Oct 2005 13:11:56 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FE7@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, 24 Oct 2005 13:11:48 -0300 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 j9OGC6L12078 Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl e 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, 24 Oct 2005 16:12:18 -0000 Status: RO Content-Length: 3642 Guillermo, We should talk - possibly off-line - about word-smithing the text around STP/RSTP. I would prefer not to try to guess what people would like me to say about this (or other) issue(s). For one thing, it would be nice if you could provide detailed references (organization, authors - if listed - dates, etc.). Bearing in mind that this document is aimed at nailing down what the requirements are for routing protocol - extensions, compatibility, etc. - we should not spend to much time and energy on making sure that what this draft says on non-routing related reuirements. Instead, I think we should make sure that the set of drafts/RFCs that the WG develops are consistent. Admittedly, since the over-all requirements, framework and architecture IDs are not out yet, this is the current draft to address such issues with. However, the wording in this draft reflects the original words in the draft cited in the WG charter. As for "zero configuration", this is a goal. If we cannot achieve it, that is one thing - but I do not think we want to start by weasle-wording our goals. I don't think anyone believes we're going to get by with zero-configuration in every case, but then we're not saying that this goal MUST be achieved in every case. So, I think we should not complicate our goals by overly qualifying them too much. Down that way is a slippery slope... -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Monday, October 24, 2005 6:48 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now --> available --> --> --> Eric, --> Some comments on draft, --> - When mentioning Spanning Tree Protocol (STP), is convenient to --> distinguish and/or mention both spanning tree protocols : --> legacy STP and --> Rapid Spanning Tree Protocol RSTP (802.1D). In general, I --> recommend to --> use the term RSTP for clarity whenever possible and add a --> sentence like: --> "...The current IEEE standard specifies RSTP, although both --> STP and RSTP --> bridges will exist and must be supported.... --> - In the abstract, "zero configuration" is mentioned. If --> VLANs must be --> configured, I do not think real zero configuration can be --> claimed. May --> be it should say "zero IP addresses/subnets configuration" --> or something --> like that. --> - Some name or acronym for the spanning trees between --> Rbridges would --> help to reduce the confusion created by two types of spanning trees --> coexisting : STP(RSTP) and between Rbridges. A --> possibility is to call --> them *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees). --> --> Guillermo --> --> --> --> Gray, Eric wrote: --> --> >The draft "Routing Requirements in Support of R-Bridges" - --> submitted last --> >Friday - is now available at: --> > --> >http://www.ietf.org/internet-drafts/draft-gray-rbridge-rout ing-reqs-00.txt > >This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt >and is very preliminary. I am looking for input for the various sections >- particularly those that currently only contain "TBD" :-) > >This was one of the drafts that the working group felt would be required >at the last meeting. > >-- >Eric Gray >_______________________________________________ >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 brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9OG8QL11201 for <rbridge@postel.org>; Mon, 24 Oct 2005 09:08:26 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9OG8P3F028327 for <rbridge@postel.org>; Mon, 24 Oct 2005 10:08:25 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9OG7rqJ156303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Oct 2005 09:08:21 -0700 (PDT) Message-ID: <435CF876.2080708@sun.com> Date: Mon, 24 Oct 2005 08:06:30 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> <435815C0.4030502@Sun.COM> <43588B9D.5050306@it.uc3m.es> In-Reply-To: <43588B9D.5050306@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9OG8QL11201 Cc: Radia.Perlman@sun.com Subject: Re: [rbridge] RBridge/bridge interaction 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, 24 Oct 2005 16:09:42 -0000 Status: RO Content-Length: 1314 Guillermo Ib??ez wrote: > I see the standard root election mechanism of spanning tree islands as > the fastest and simpler mechanism for DR Rbridge designation. I see the > DR Rbridge as being necessarily the ROOT bridge of that sbridged cloud > (or "link"). The root bridge of a standard spanning tree is the > "natural" source and sink point for the spanning tree. To do so, the DR > must issue BPDUs to become the root bridge. This is part of what I > mentioned days ago as PARTICIPATE PER PORT, but may be we should call it > SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs > to contend to be the root bridge of the link). > The consequence of this DR election mechanism is that the priority > configured at Rbridges as bridge ID would determine their also their > election priority as DRs. I think this keep both domains coordinated > with a single mechanism. But I don't think it is possible in 802.1D to guarantee that the RBridges become the 802.1D root bridges as seen from the bridges. It could be that there is one or more bridges that are configured so that they are the most likely to be selected as 802.1D root bridges. Presumably we'd want RBridges to function even when applied to such a network (even though the paths might not be "optimal"). Erik 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 j9OFieL04097 for <rbridge@postel.org>; Mon, 24 Oct 2005 08:44:45 -0700 (PDT) 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 j9OFiWp1020675 for <rbridge@postel.org>; Mon, 24 Oct 2005 11:44:33 -0400 (EDT) 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 LAA22374 for <rbridge@postel.org>; Mon, 24 Oct 2005 11:44:32 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX8KKZ>; Mon, 24 Oct 2005 12:44:31 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FE5@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, 24 Oct 2005 12:44:27 -0300 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 j9OFieL04097 Subject: Re: [rbridge] RBridge/bridge interaction 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, 24 Oct 2005 15:45:17 -0000 Status: RO Content-Length: 5081 I think we should leave that sort of determination to the supposed wisdom of the successful implementer. But I won't object to text along these lines if someone else wants to write it... -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Radia Perlman --> Sent: Saturday, October 22, 2005 4:59 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> And another thought. Although I don't think we should --> include the notion of --> a combined bridge/RBridge in the spec for RBridges, --> just a suggestion for anyone that wants to build this beast... --> --> It would be nice to minimize configuration, so especially --> if the reason --> for making a --> bridge/RBridge is to --> make an RBridge have higher priority for being bridge spanning tree --> Root, have the priority for --> bridge Root be a function of the RBridge IS-IS DR priority, --> so you only --> have to set one --> of them. --> --> We don't have to debate this, since this if it's not in the RBridge --> spec, vendors can --> do whatever they want. But it's perhaps good to have --> suggestions posted --> publicly. --> --> Radia --> --> --> --> Peter Ashwood-Smith wrote: --> --> >Likewise. --> > --> > --> > --> >>-----Original Message----- --> >>From: rbridge-bounces@postel.org --> >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric --> >>Sent: Friday, October 21, 2005 6:16 PM --> >>To: 'Developing a hybrid router/bridge.' --> >>Subject: Re: [rbridge] RBridge/bridge interaction --> >> --> >> --> >>I also agree that this is a quite feasible approach. --> >> --> >>-- --> >>Eric --> >> --> >>--> -----Original Message----- --> >>--> From: rbridge-bounces@postel.org --> >>--> [mailto:rbridge-bounces@postel.org]On --> >>--> Behalf Of Guillermo Ib??ez --> >>--> Sent: Friday, October 21, 2005 6:01 PM --> >>--> To: Developing a hybrid router/bridge. --> >>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>--> --> >>--> --> >>--> Right. In this way both views are covered. I fully agree. --> >>Guillermo --> >>--> --> >>--> Radia Perlman wrote: --> >>--> --> >>--> >Actually, here's a suggestion that may make us all happy. --> >>--> > --> >>--> >Keep the design of RBridge independent of bridges. --> >>RBridges do not --> >>--> >participate --> >>--> >in spanning tree (other than throwing away BPDUs). --> >>--> > --> >>--> >However, to get the functionality that Guillermo --> >>--> wants....allow someone --> >>--> >to build a device that's logically the --> >>--> >same as a bridge glued onto an RBridge. To the rest of the --> >>--> world it --> >>--> >would look --> >>--> >like this: --> >>--> > --> >>--> >bridged island----B1----RB1 --> >>--> > --> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to --> >>--> RBRidge RB1, --> >>--> >and a link to the --> >>--> >bridged LAN. --> >>--> > --> >>--> >The "RB1" portion of this box does what the architecture --> >>--> of an RBridge --> >>--> >does...it neither --> >>--> >forwards, nor initiates spanning tree messages. --> >>--> > --> >>--> >However, the "B1" portion of the box acts like a vanilla --> >>--> bridge, and --> >>--> >does participate in --> >>--> >spanning tree. And it can be configured to have whatever --> >>--> priority people --> >>--> >want. --> >>--> > --> >>--> >If it's commercially important for RBridges to have the --> >>--> capability of --> >>--> >participating in --> >>--> >the bridge protocol, it can be done this way without --> >>--> defining it into --> >>--> >either the RBridge --> >>--> >or bridge functionality. --> >>--> > --> >>--> >Radia --> >>--> > --> >>--> > --> >>--> > --> >>--> >Guillermo Ib??ez wrote: --> >>--> > --> >>--> > --> >>--> > --> >>--> >>Root bridge planning is something required in campus --> >>--> networks, it just --> >>--> >>means configure the 16 bit priority of the preffered root --> >>--> bridge (and --> >>--> >>perhaps a root reserve) with a low enough value under the --> >>--> default value. --> >>--> >> --> >>--> >> --> >>--> >> --> >>--> > --> >>--> > --> >>--> >_______________________________________________ --> >>--> >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 --> > --> > --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9OC4cL29945 for <rbridge@postel.org>; Mon, 24 Oct 2005 05:04:39 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2214F258093 for <rbridge@postel.org>; Mon, 24 Oct 2005 14:04:00 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26355-05 for <rbridge@postel.org>; Mon, 24 Oct 2005 14:03:56 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7524D25817F for <rbridge@postel.org>; Mon, 24 Oct 2005 14:03:55 +0200 (CEST) Date: Mon, 24 Oct 2005 05:00:23 -0700 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <283701B7DB91301C8F6351AF@B50854F0A9192E8EC6CDA126> In-Reply-To: <435CBBEF.3060300@it.uc3m.es> References: <313680C9A886D511A06000204840E1CF0C885FCC@whq-msgusr-02.pit.comms .marconi.com> <435CBBEF.3060300@it.uc3m.es> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========6C037B9DCB4F4087D16B==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] R-Bridge Routing Requirements draft is 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, 24 Oct 2005 12:05:13 -0000 Status: RO Content-Length: 1211 --==========6C037B9DCB4F4087D16B========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 24. oktober 2005 12:48 +0200 Guillermo Ib=C3=A1=C3=B1ez = <gibanez@it.uc3m.es>=20 wrote: > - Some name or acronym for the spanning trees between Rbridges would > help to reduce the confusion created by two types of spanning trees > coexisting : STP(RSTP) and between Rbridges. A possibility is to call > them *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees) why not name them for their function, and call them multicast distribution=20 trees? It's after all an essential point of the design that the unicast packets do = NOT have to follow the spanning trees; the unicast routing tables will form = a directed acyclic graph (DAG), not a tree. Harald --==========6C037B9DCB4F4087D16B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDXMzXOMj+2+WY0F4RAnK0AJ44XAcL2PSba+7btFwjoS2jDfYhJQCg9rHH lYu3e5HdBFvfK/yCBJ4o8Jw= =L9jc -----END PGP SIGNATURE----- --==========6C037B9DCB4F4087D16B==========-- 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 j9OAmKL11597 for <rbridge@postel.org>; Mon, 24 Oct 2005 03:48:21 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 07C899D872 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:48:15 +0200 (CEST) Received: from [163.117.203.185] (unknown [163.117.203.185]) by smtp01.uc3m.es (Postfix) with ESMTP id F39009D891 for <rbridge@postel.org>; Mon, 24 Oct 2005 12:48:13 +0200 (CEST) Message-ID: <435CBBEF.3060300@it.uc3m.es> Date: Mon, 24 Oct 2005 12:48:15 +0200 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: <313680C9A886D511A06000204840E1CF0C885FCC@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FCC@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] R-Bridge Routing Requirements draft is 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, 24 Oct 2005 10:49:13 -0000 Status: RO Content-Length: 1628 Eric, Some comments on draft, - When mentioning Spanning Tree Protocol (STP), is convenient to distinguish and/or mention both spanning tree protocols : legacy STP and Rapid Spanning Tree Protocol RSTP (802.1D). In general, I recommend to use the term RSTP for clarity whenever possible and add a sentence like: "...The current IEEE standard specifies RSTP, although both STP and RSTP bridges will exist and must be supported.... - In the abstract, "zero configuration" is mentioned. If VLANs must be configured, I do not think real zero configuration can be claimed. May be it should say "zero IP addresses/subnets configuration" or something like that. - Some name or acronym for the spanning trees between Rbridges would help to reduce the confusion created by two types of spanning trees coexisting : STP(RSTP) and between Rbridges. A possibility is to call them *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees). Guillermo Gray, Eric wrote: >The draft "Routing Requirements in Support of R-Bridges" - submitted last >Friday - is now available at: > >http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.txt > >This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt >and is very preliminary. I am looking for input for the various sections >- particularly those that currently only contain "TBD" :-) > >This was one of the drafts that the working group felt would be required >at the last meeting. > >-- >Eric Gray >_______________________________________________ >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 j9MKxWL12952 for <rbridge@postel.org>; Sat, 22 Oct 2005 13:59:32 -0700 (PDT) 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 <0IOS0040M4Z09L00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 22 Oct 2005 13:59:24 -0700 (PDT) Received: from sun.com ([129.150.24.220]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOS003IQ4YXTF10@mail.sunlabs.com> for rbridge@postel.org; Sat, 22 Oct 2005 13:59:23 -0700 (PDT) Date: Sat, 22 Oct 2005 13:59:29 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B405213D5C@zcarhxm2.corp.nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435AA831.5080509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <713043CE8B8E1348AF3C546DBE02C1B405213D5C@zcarhxm2.corp.nortel.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] RBridge/bridge interaction 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, 22 Oct 2005 21:00:09 -0000 Status: RO Content-Length: 3847 And another thought. Although I don't think we should include the notion of a combined bridge/RBridge in the spec for RBridges, just a suggestion for anyone that wants to build this beast... It would be nice to minimize configuration, so especially if the reason for making a bridge/RBridge is to make an RBridge have higher priority for being bridge spanning tree Root, have the priority for bridge Root be a function of the RBridge IS-IS DR priority, so you only have to set one of them. We don't have to debate this, since this if it's not in the RBridge spec, vendors can do whatever they want. But it's perhaps good to have suggestions posted publicly. Radia Peter Ashwood-Smith wrote: >Likewise. > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >>[mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric >>Sent: Friday, October 21, 2005 6:16 PM >>To: 'Developing a hybrid router/bridge.' >>Subject: Re: [rbridge] RBridge/bridge interaction >> >> >>I also agree that this is a quite feasible approach. >> >>-- >>Eric >> >>--> -----Original Message----- >>--> From: rbridge-bounces@postel.org >>--> [mailto:rbridge-bounces@postel.org]On >>--> Behalf Of Guillermo Ib??ez >>--> Sent: Friday, October 21, 2005 6:01 PM >>--> To: Developing a hybrid router/bridge. >>--> Subject: Re: [rbridge] RBridge/bridge interaction >>--> >>--> >>--> Right. In this way both views are covered. I fully agree. >>Guillermo >>--> >>--> Radia Perlman wrote: >>--> >>--> >Actually, here's a suggestion that may make us all happy. >>--> > >>--> >Keep the design of RBridge independent of bridges. >>RBridges do not >>--> >participate >>--> >in spanning tree (other than throwing away BPDUs). >>--> > >>--> >However, to get the functionality that Guillermo >>--> wants....allow someone >>--> >to build a device that's logically the >>--> >same as a bridge glued onto an RBridge. To the rest of the >>--> world it >>--> >would look >>--> >like this: >>--> > >>--> >bridged island----B1----RB1 >>--> > >>--> >where B1 is a bridge with two ports...a pt-to-pt link to >>--> RBRidge RB1, >>--> >and a link to the >>--> >bridged LAN. >>--> > >>--> >The "RB1" portion of this box does what the architecture >>--> of an RBridge >>--> >does...it neither >>--> >forwards, nor initiates spanning tree messages. >>--> > >>--> >However, the "B1" portion of the box acts like a vanilla >>--> bridge, and >>--> >does participate in >>--> >spanning tree. And it can be configured to have whatever >>--> priority people >>--> >want. >>--> > >>--> >If it's commercially important for RBridges to have the >>--> capability of >>--> >participating in >>--> >the bridge protocol, it can be done this way without >>--> defining it into >>--> >either the RBridge >>--> >or bridge functionality. >>--> > >>--> >Radia >>--> > >>--> > >>--> > >>--> >Guillermo Ib??ez wrote: >>--> > >>--> > >>--> > >>--> >>Root bridge planning is something required in campus >>--> networks, it just >>--> >>means configure the 16 bit priority of the preffered root >>--> bridge (and >>--> >>perhaps a root reserve) with a low enough value under the >>--> default value. >>--> >> >>--> >> >>--> >> >>--> > >>--> > >>--> >_______________________________________________ >>--> >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 zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9MKNaL06028 for <rbridge@postel.org>; Sat, 22 Oct 2005 13:23:36 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9MKKlw01945 for <rbridge@postel.org>; Sat, 22 Oct 2005 16:20:47 -0400 (EDT) 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="iso-8859-1" Date: Sat, 22 Oct 2005 16:23:26 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D5C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge/bridge interaction Thread-Index: AcXWjZ83gwXjqcUyRh2mhVdL4cOl8gAuMxfA From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9MKNaL06028 Subject: Re: [rbridge] RBridge/bridge interaction 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, 22 Oct 2005 20:24:07 -0000 Status: RO Content-Length: 2981 Likewise. > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric > Sent: Friday, October 21, 2005 6:16 PM > To: 'Developing a hybrid router/bridge.' > Subject: Re: [rbridge] RBridge/bridge interaction > > > I also agree that this is a quite feasible approach. > > -- > Eric > > --> -----Original Message----- > --> From: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org]On > --> Behalf Of Guillermo Ib??ez > --> Sent: Friday, October 21, 2005 6:01 PM > --> To: Developing a hybrid router/bridge. > --> Subject: Re: [rbridge] RBridge/bridge interaction > --> > --> > --> Right. In this way both views are covered. I fully agree. > Guillermo > --> > --> Radia Perlman wrote: > --> > --> >Actually, here's a suggestion that may make us all happy. > --> > > --> >Keep the design of RBridge independent of bridges. > RBridges do not > --> >participate > --> >in spanning tree (other than throwing away BPDUs). > --> > > --> >However, to get the functionality that Guillermo > --> wants....allow someone > --> >to build a device that's logically the > --> >same as a bridge glued onto an RBridge. To the rest of the > --> world it > --> >would look > --> >like this: > --> > > --> >bridged island----B1----RB1 > --> > > --> >where B1 is a bridge with two ports...a pt-to-pt link to > --> RBRidge RB1, > --> >and a link to the > --> >bridged LAN. > --> > > --> >The "RB1" portion of this box does what the architecture > --> of an RBridge > --> >does...it neither > --> >forwards, nor initiates spanning tree messages. > --> > > --> >However, the "B1" portion of the box acts like a vanilla > --> bridge, and > --> >does participate in > --> >spanning tree. And it can be configured to have whatever > --> priority people > --> >want. > --> > > --> >If it's commercially important for RBridges to have the > --> capability of > --> >participating in > --> >the bridge protocol, it can be done this way without > --> defining it into > --> >either the RBridge > --> >or bridge functionality. > --> > > --> >Radia > --> > > --> > > --> > > --> >Guillermo Ib??ez wrote: > --> > > --> > > --> > > --> >>Root bridge planning is something required in campus > --> networks, it just > --> >>means configure the 16 bit priority of the preffered root > --> bridge (and > --> >>perhaps a root reserve) with a low enough value under the > --> default value. > --> >> > --> >> > --> >> > --> > > --> > > --> >_______________________________________________ > --> >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 j9LMGAL03605 for <rbridge@postel.org>; Fri, 21 Oct 2005 15:16:10 -0700 (PDT) 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 j9LMG4p1013641 for <rbridge@postel.org>; Fri, 21 Oct 2005 18:16:05 -0400 (EDT) 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 SAA13343 for <rbridge@postel.org>; Fri, 21 Oct 2005 18:16:04 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX6KZ3>; Fri, 21 Oct 2005 19:16:03 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FDE@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 19:16:02 -0300 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 j9LMGAL03605 Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 22:17:05 -0000 Status: RO Content-Length: 2408 I also agree that this is a quite feasible approach. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Friday, October 21, 2005 6:01 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> Right. In this way both views are covered. I fully agree. --> Guillermo --> --> Radia Perlman wrote: --> --> >Actually, here's a suggestion that may make us all happy. --> > --> >Keep the design of RBridge independent of bridges. RBridges do not --> >participate --> >in spanning tree (other than throwing away BPDUs). --> > --> >However, to get the functionality that Guillermo --> wants....allow someone --> >to build a device that's logically the --> >same as a bridge glued onto an RBridge. To the rest of the --> world it --> >would look --> >like this: --> > --> >bridged island----B1----RB1 --> > --> >where B1 is a bridge with two ports...a pt-to-pt link to --> RBRidge RB1, --> >and a link to the --> >bridged LAN. --> > --> >The "RB1" portion of this box does what the architecture --> of an RBridge --> >does...it neither --> >forwards, nor initiates spanning tree messages. --> > --> >However, the "B1" portion of the box acts like a vanilla --> bridge, and --> >does participate in --> >spanning tree. And it can be configured to have whatever --> priority people --> >want. --> > --> >If it's commercially important for RBridges to have the --> capability of --> >participating in --> >the bridge protocol, it can be done this way without --> defining it into --> >either the RBridge --> >or bridge functionality. --> > --> >Radia --> > --> > --> > --> >Guillermo Ib??ez wrote: --> > --> > --> > --> >>Root bridge planning is something required in campus --> networks, it just --> >>means configure the 16 bit priority of the preffered root --> bridge (and --> >>perhaps a root reserve) with a low enough value under the --> default value. --> >> --> >> --> >> --> > --> > --> >_______________________________________________ --> >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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9LM1CL28593 for <rbridge@postel.org>; Fri, 21 Oct 2005 15:01:12 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7D2F29D252 for <rbridge@postel.org>; Sat, 22 Oct 2005 00:01:06 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id A031D9D1D0 for <rbridge@postel.org>; Sat, 22 Oct 2005 00:01:05 +0200 (CEST) Message-ID: <4359651D.6090409@it.uc3m.es> Date: Sat, 22 Oct 2005 00:01:01 +0200 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: <313680C9A886D511A06000204840E1CF0C885FD6@whq-msgusr-02.pit.comms.marconi.com> <43595A91.5040902@it.uc3m.es> <43596227.1080105@sun.com> In-Reply-To: <43596227.1080105@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] RBridge/bridge interaction 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, 21 Oct 2005 22:02:07 -0000 Status: RO Content-Length: 1598 Right. In this way both views are covered. I fully agree. Guillermo Radia Perlman wrote: >Actually, here's a suggestion that may make us all happy. > >Keep the design of RBridge independent of bridges. RBridges do not >participate >in spanning tree (other than throwing away BPDUs). > >However, to get the functionality that Guillermo wants....allow someone >to build a device that's logically the >same as a bridge glued onto an RBridge. To the rest of the world it >would look >like this: > >bridged island----B1----RB1 > >where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, >and a link to the >bridged LAN. > >The "RB1" portion of this box does what the architecture of an RBridge >does...it neither >forwards, nor initiates spanning tree messages. > >However, the "B1" portion of the box acts like a vanilla bridge, and >does participate in >spanning tree. And it can be configured to have whatever priority people >want. > >If it's commercially important for RBridges to have the capability of >participating in >the bridge protocol, it can be done this way without defining it into >either the RBridge >or bridge functionality. > >Radia > > > >Guillermo Ib??ez wrote: > > > >>Root bridge planning is something required in campus networks, it just >>means configure the 16 bit priority of the preffered root bridge (and >>perhaps a root reserve) with a low enough value under the default value. >> >> >> > > >_______________________________________________ >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 j9LLwRL27650 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:58:28 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D33CB9D4E5 for <rbridge@postel.org>; Fri, 21 Oct 2005 23:58:21 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id DB0B59D4E4 for <rbridge@postel.org>; Fri, 21 Oct 2005 23:58:20 +0200 (CEST) Message-ID: <4359647D.8090809@it.uc3m.es> Date: Fri, 21 Oct 2005 23:58:21 +0200 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: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> <435815C0.4030502@Sun.COM> <43588B9D.5050306@it.uc3m.es> <435897F4.5030506@sun.com> <4358DB9B.2090600@it.uc3m.es> <43595F48.4040009@sun.com> In-Reply-To: <43595F48.4040009@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] RBridge/bridge interaction 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, 21 Oct 2005 21:59:10 -0000 Status: RO Content-Length: 2019 Root election would be, as now, planned according to expected traffic patterns. If routers have dominant traffic, they could be configured to act as roots. Besides performance, nobody mentions arguments regarding independent IS-IS DR election vs DR election linked to root bridge election, which I think is a more important advantage than performance and shortest path in the spanning tree. My impression is that convergence is slower for IS-IS for DR reconfiguration than for an RSTP driven DR election. But perhaps we have discussed enough this subject. Time will tell if something like this is desirable. Guillermo Radia Perlman wrote: >Guillermo Ib??ez wrote: > > > >>With the client server model, dominant traffic is to and from the core >>layer of campus network, so I think most of the traffic will flow >>from/into Rbridge, not withing the islands. >> >> >> >> >> >If we buy that argument, then the same argument would say that routers >should participate in >the spanning tree and attempt to become Root. And what if there are >multiple routers? >If it's so vital for performance that one router is Root, then they'd >all need to be Root within a bridged >network. > >We shouldn't be trying to optimize that particular tree calculated by >the bridged islands. Hopefully >those trees would become smaller and smaller. And even if we did care >about some type of optimality, >I don't think trying to make one of the RBridges Root will make any >difference. (Note "one of the >RBridges"...there can be several RBridges on the bridged island, so at >most one of them can >be Root). People have lived for a long time without worrying about >making one of the routers on >a bridged LAN be the Root in order to attempt more optimal delivery of >traffic on/off the bridged LAN. >I don't think we should worry about it either. > >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 j9LLmLL23406 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:48:21 -0700 (PDT) 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 <0IOQ0033FCKGFE00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 14:48:16 -0700 (PDT) Received: from sun.com ([129.150.24.220]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOQ003IUCKFTF00@mail.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 14:48:16 -0700 (PDT) Date: Fri, 21 Oct 2005 14:48:23 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <43595A91.5040902@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43596227.1080105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <313680C9A886D511A06000204840E1CF0C885FD6@whq-msgusr-02.pit.comms.marconi.com> <43595A91.5040902@it.uc3m.es> 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] RBridge/bridge interaction 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, 21 Oct 2005 21:49:29 -0000 Status: RO Content-Length: 1299 Actually, here's a suggestion that may make us all happy. Keep the design of RBridge independent of bridges. RBridges do not participate in spanning tree (other than throwing away BPDUs). However, to get the functionality that Guillermo wants....allow someone to build a device that's logically the same as a bridge glued onto an RBridge. To the rest of the world it would look like this: bridged island----B1----RB1 where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box does what the architecture of an RBridge does...it neither forwards, nor initiates spanning tree messages. However, the "B1" portion of the box acts like a vanilla bridge, and does participate in spanning tree. And it can be configured to have whatever priority people want. If it's commercially important for RBridges to have the capability of participating in the bridge protocol, it can be done this way without defining it into either the RBridge or bridge functionality. Radia Guillermo Ib??ez wrote: >Root bridge planning is something required in campus networks, it just >means configure the 16 bit priority of the preffered root bridge (and >perhaps a root reserve) with a low enough value under the default value. > 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 j9LLlWL22977 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:47:35 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7A8A59D388 for <rbridge@postel.org>; Fri, 21 Oct 2005 23:47:26 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id 821D09D436 for <rbridge@postel.org>; Fri, 21 Oct 2005 23:47:24 +0200 (CEST) Message-ID: <435961ED.1040603@it.uc3m.es> Date: Fri, 21 Oct 2005 23:47:25 +0200 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: <313680C9A886D511A06000204840E1CF0C885FDD@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FDD@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 21 Oct 2005 21:48:12 -0000 Status: RO Content-Length: 27213 Gray, Eric wrote: >Guillermo, > > Here's the problem: in order for an RBridge to be the >spanning tree root for bridges, it has to participate in bridge >STP. Nothing else will work. However, it would be better from >a simplicity perspective if the designated RBridge forwarder for >a link were selected on a basis of proximity to the root bridge, >rather than because it is the root bridge. Or it might just be >"good enough" to take whatever happens to fall out and document >some configuration steps that would make sense if there's a real >problem in a given deployment. > > I see a contradiction in your argument, the closeness to DR is important to choose the root bridge. What else can it be more than to be (the root) placed close to the forwarder? . You assume that the root has been elected by some special reasons. I admit it can be stated as an option that RBridge might participate as root bridge with only one Designated port as alternative to not participating in STP, with the requirement that BPDUs received must be RSTP, not STP (speed reasons). > But there may be something to your concern for optimizing >the root and designated forwarder equality as a critical aspect >of the approach. > > This looks like an excellent opportunity for someone to run >simulations using randomly generated bridge/RBridge topologies. > > The hypothesis is that having the designated forwarder for >an internal RBridge link be something other than the spanning tree >root will have significant impact on forwarding efficiency. It >would be nice if the same topologies were used in simulations that >assume: > >1) total random selection of both spanning tree root and designated >link forwarder - how likely are the best, average and worst cases? > >2) a heuristic selection scheme: giving weight to selection of a >designated forwarder likely to be adjacent to a spanning tree root >- what will be the expected (average) impact on forwarding? > > > In this case you transfer (and increase it) the complexity to the designated forwarder election >3) a deterministic approach that results in selecting a designated >link forwarder with the shortest path adjacency to the STP root. > > > It seems simpler to force the root to be forwarder. > The antithesis is that the expected (average) difference, and >a combination of likelihood of worst case and worst case difference, >are not significant - taken together to be worth added complexity >(assume a factor of 2 in cost/complexity). > > > Depends on the average spanning tree length > One of the important factors to include in the simulations is >that the effect on frame forwarding of having frames start at a leaf >(or on a branch) as opposed to at the root is simply that it takes a >slightly longer time for a broadcast frame to reach all the other >branches and leaves if it doesn't start at the root, than it does if >it does start at the root. So the problem is delay efficiency based >rather than throughput efficiency based. > > > Not exactly. There is more congestion at the root if the forwarder is not root. > The simulation must not - for example - assume that spanning >tree forwarding works the same way as designated RBridge forwarding >(it does not). > > For example, given the below quasi-random spanning tree (with >B1 as root) and designated RBridge forwarder (RB1*): > > B1 --+ > | | > B6 --+ B12 --+-- RB5 > | | | > RB3 -- B5 --+ B4 B8 --+-- B10 > | | | | | | > B11 B2 B9 B3 B7 RB1* > | | | | | > RB7 RB2 RB4 RB8 RB6 > >Question: what is the real difference between having this situation >(B1 root, RB1* designated forwarder) and either of the following: > >a) B1 root, RB5 designated forwarder - or >b) RB5 both root and designated forwarder. > >Given that the broadcast forwarding paths for the initial case are: > >o RB1 >o B10, B7, RB6 >o B8, RB5 >o B3, RB8 >o B12, B4, B9, RB4 >o B1, B6, B5, RB3 >o B2, RB2 >o B11, RB7 > >Case a): > >o RB5 >o B8, B3, RB8 >o B7, RB6 >o B10, RB1 >o B12, B4, B9, RB4 >o B1, B6, B5, RB3 >o B2, RB2 >o B11, RB7 > >For case b), it is necessary to make some assumptions about 1) how >many redundant paths there were, where the blocked ones were, and >which will now be un-blocked by the spanning tree with RB5 as root. > >The average path length must be considered, rather than the worst >case, because a broadcast frame might arrive at any RBridge (or any >bridge, for that matter) - be forwarded to the designated forwarder >along the spanning tree, and then forwarded along each of the paths >determined (as shown above). > >I am pretty sure that the difference in average length of the path >will not be that significant - especially looking at it as a delay >factor rather than a throughput factor. > >If the average length of the paths differs by - for example - one >bridge-to-bridge link, then it is probably reasonable to argue that >(on average) there will be one additional link that is traversed >twice (once raw and once encapsulated) for each broadcast frame. >It does seem likely that it will not always be the same bridge-to- >bridge link every time. > >But I suspect that it would be best if someone could take the time >to simulate all this... > > > I agree. But if no automatic tool is used for STP calculations in random topologies, it may be quite cumbersome. Does anybody know tools adequate for Eric proposal ? Random generated topology must be cut to a subset graph by the spanning tree (using node ID to select root or randomly) and path lengths calculated. Guillermo >-- >Eric > > > > > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Guillermo Ib??ez >--> Sent: Friday, October 21, 2005 1:50 PM >--> To: 'Developing a hybrid router/bridge.' >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> My doubt is whether the DR Designation procedure is fast >--> and reliable enough >--> for reconfigurations of the islands communicating the >--> Rbridges. Using the DR >--> Rbridge as root bridge and linking the DR Designated role >--> of Rbridge to the >--> role of root bridge of the link, the root bridge election >--> at the link >--> could be used also as a faster and reliable mechanism for >--> DR designation, as >--> in fact the function is rather similar (although new: never >--> a root bridge >--> had Root port to forward and receive packets). It may sound >--> complicated, I >--> think in the long term it may be more complicated for >--> Rbridges to be DRs of >--> a link that they do not control. >--> Guillermo >--> >--> -----Mensaje original----- >--> De: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org] En nombre >--> de Gray, Eric >--> Enviado el: viernes, 21 de octubre de 2005 19:07 >--> Para: 'Developing a hybrid router/bridge.' >--> Asunto: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> Guillermo, >--> >--> I had to think about what Radia was saying to realize >--> that she is not objecting to merging one RBridge campus >--> with another. If I >--> understand correctly, what she is referring >--> to is merging spanning trees between two islands (or pockets) of >--> 802/Ethernet bridges separated by a R-Bridge campus. >--> >--> There's nothing to resolve, if the RBridge campus does >--> not participate in STP, or transparently pass it through >--> the campus from one >--> island to another. >--> >--> So, I suspect that we are not looking for a way to solve >--> the problem, since there is a way to avoid it. >--> >--> -- >--> Eric Gray >--> >--> --> -----Original Message----- >--> --> From: rbridge-bounces@postel.org >--> --> [mailto:rbridge-bounces@postel.org]On >--> --> Behalf Of Guillermo Ib??ez >--> --> Sent: Friday, October 21, 2005 8:14 AM >--> --> To: Developing a hybrid router/bridge. >--> --> Subject: Re: [rbridge] RBridge/bridge interaction >--> --> >--> --> >--> --> >--> --> >--> --> Radia Perlman wrote: >--> --> >--> --> >I don't think there's any reason, even if most of the >--> --> traffic on the >--> --> >link comes from the DR, for the >--> --> >DR to be the root of the spanning tree. >--> --> >What would be bad is if an RBridge, participating in >--> two bridged >--> --> >islands, winds up merging >--> --> >the islands into a bigger island. >--> --> > >--> --> > >--> --> Good point, but I think it can be solved. >--> --> The merging of islands can be prevented if the RBridge >--> --> acting as root >--> --> limits to one port maximum in the Designated Port Role of >--> --> spanning tree >--> --> for sbridges. >--> --> >--> --> >The whole point is to make the bridged islands as small as >--> --> possible, so >--> --> >most forwarding is done >--> --> >protected by hop count, and with optimal routes. >--> --> > >--> --> > >--> --> > >--> --> I'll admit that having RBridges *initiate* BPDUs >--> --> >--> --> >to vie for being Root is not as harmful as having them >--> --> *forward* BPDUs >--> --> >between >--> --> >bridged islands (provided an RBridge is careful not to >--> --> merge two islands >--> --> >that would >--> --> >have been separate if the RBridge had just been >--> blocking BPDUs). >--> --> > >--> --> >We shouldn't make things more complex in an attempt to >--> --> come up with a >--> --> >"more optimal" >--> --> >spanning tree within the bridged islands. >--> --> > >--> --> > >--> --> >--> --> >With a bidirectional tree, as happens with bridges, >--> --> there's nothing >--> --> >special about the Root. >--> --> >Also, the traffic pattern might be such that most of the >--> --> traffic is >--> --> >between endnodes within >--> --> >the island. >--> --> > >--> --> With the client server model, dominant traffic is to and >--> --> from the core >--> --> layer of campus network, so I think most of the traffic >--> will flow >--> --> from/into Rbridge, not withing the islands. >--> --> >--> --> >So there's really no reason to believe that having the >--> --> >RBridge DR be the >--> --> >spanning tree Root will result in better performance. And >--> --> is certainly >--> --> >complicates things. >--> --> >And it also certainly is dangerous because of the >--> --> potential of merging >--> --> >islands. >--> --> > >--> --> > >--> --> > >--> --> I do not think is dangerous. The merging of islands is not >--> --> convenient, >--> --> but it can be prevented, limiting to one port the >--> --> Designated Role in the >--> --> root Rbridge. >--> --> Guillermo >--> --> >--> --> >Radia >--> --> > >--> --> > >--> --> > >--> --> >Guillermo Ib??ez wrote: >--> --> > >--> --> > >--> --> > >--> --> >>I see the standard root election mechanism of spanning >--> --> tree islands as >--> --> >>the fastest and simpler mechanism for DR Rbridge >--> --> designation. I see the >--> --> >>DR Rbridge as being necessarily the ROOT bridge of that >--> --> sbridged cloud >--> --> >>(or "link"). The root bridge of a standard spanning >--> tree is the >--> --> >>"natural" source and sink point for the spanning tree. >--> --> To do so, the DR >--> --> >>must issue BPDUs to become the root bridge. This is part >--> --> of what I >--> --> >>mentioned days ago as PARTICIPATE PER PORT, but may be we >--> --> should call it >--> --> >>SOURCE OR SINK (participate, do not forward BPDUs, only >--> --> send own BPDUs >--> --> >>to contend to be the root bridge of the link). >--> --> >>The consequence of this DR election mechanism is that the >--> --> priority >--> --> >>configured at Rbridges as bridge ID would determine their >--> --> also their >--> --> >>election priority as DRs. I think this keep both domains >--> --> coordinated >--> --> >>with a single mechanism. >--> --> >>Guillermo >--> --> >> >--> --> >>Radia Perlman wrote: >--> --> >> >--> --> >> >--> --> >> >--> --> >> >--> --> >> >--> --> >>>I don't believe there should be options here. >--> --> >>>It should be plug and play. >--> --> >>>RBridges should BLOCK bridge spanning tree messages, >--> --> >>>and isolate the bridged islands. >--> --> >>> >--> --> >>>I absolutely do not understand what people are >--> --> >>>worried about with BLOCK. >--> --> >>> >--> --> >>>I suggest someone that actually thinks there is >--> --> >>>some reason to do anything other than drop >--> --> >>>spanning tree messages start a thread with >--> --> >>>a subject line >--> --> >>>"why it is good for RBridges to forward BPDUs", >--> --> >>>and very very carefully explain from scratch >--> --> >>>what the reasoning is. Not with a long >--> --> >>>email quoting pieces of other emails, but >--> --> >>>with a carefully crafted, from scratch explanation >--> --> >>>of what you perceive as a problem with BLOCk, and >--> --> >>>what the perceived benefit of ever having >--> --> >>>RBridges forwarding BPDUs would >--> --> >>>be. >--> --> >>> >--> --> >>>Oh...and there was a much earlier thread of the >--> --> >>>thread about other devices that might forward >--> --> >>>or drop BPDUs. There have always been things we >--> --> >>>referred to as "simple bridges" that forwarded spanning tree >--> --> >>>messages. I was careful to ensure that the spanning >--> tree would >--> --> >>>work with such devices. Of course the spanning tree >--> would not >--> --> >>>prevent a loop of all simple bridges, but if there >--> was at least >--> --> >>>one spanning tree bridge in the middle of every >--> possible loop, >--> --> >>>then there would wind up being no loops. >--> --> >>> >--> --> >>>You can think of "simple bridges" (ones that >--> mindlessly forward >--> --> >>>BPDUs) as a layer below bridges. They are invisible >--> to bridges. >--> --> >>>Bridges see a bunch of segments connected by simple >--> bridges as a >--> --> >>>single segment. (Just like RBridges will see a bunch >--> of segments >--> --> >>>connected by bridges as a single segment). >--> --> >>> >--> --> >>>Devices that drop BDPUs work if they are really >--> --> >>>layered on top of bridges, i.e., they let the >--> --> >>>bridges do their own thing to create isolated >--> --> >>>broadcast domains, and then these other devices do >--> --> >>>their own thing to glue these islands together. >--> --> >>>Like routers do. And like RBridges will do. >--> --> >>> >--> --> >>>Radia >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,: >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>>>Eric, >--> --> >>>> >--> --> >>>> >--> --> >>>>Gray, Eric wrote: >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>>>Guillermo, >--> --> >>>>> >--> --> >>>>> During the discussion, the terms TRANSPARENT, >--> --> PARTICIPATE >--> --> >>>>>and BLOCK were used (often in upper-case, exactly as I >--> --> have used >--> --> >>>>>them here) as if these would ultimately be options >--> --> that might be >--> --> >>>>>supported - either as a complete set, or as some subset. >--> --> >>>>> >--> --> >>>>> For example, one argument was that TRANSPARENT >--> --> or PARTICIPATE >--> --> >>>>>might be used, but BLOCK should not. >--> --> >>>>> >--> --> >>>>> Also, at certain points in the discussion, >--> --> there was some >--> --> >>>>>thought that these might be modes that applied at >--> --> different states >--> --> >>>>>during transitions in a network. >--> --> >>>>> >--> --> >>>>> From a practical stand-point - however - it >--> --> would be best if >--> --> >>>>>we did not have to support all of these, either as >--> --> options, or as >--> --> >>>>>modes. The mere fact that they were brought up does >--> --> not mean we >--> --> >>>>>are committed to including them. >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>Agreed >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>>> In particular, if we start talking about - for >--> --> instance - >--> --> >>>>>having a per-interface option for all of these choices >--> --> (and maybe >--> --> >>>>>others as well), then we either need to analyze >--> proposals for >--> --> >>>>>architecture and design to ensure that the "right >--> things" will >--> --> >>>>>happen when an arbitrary combination of all of these >--> --> options is in >--> --> >>>>>effect, or we need to define caveats for network >--> --> operators to avoid >--> --> >>>>>specific combinations of options. For example, we may >--> --> need to say >--> --> >>>>>that the same option must be set throughout the >--> --> network or this and >--> --> >>>>>that will (or may) happen. That kind of design begs >--> --> configuration >--> --> >>>>>errors to occur. >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>If you refer as configuration options per interface to >--> --> the PARTICIPATE >--> --> >>>>PER PORT mode as an option per port, it is not the >--> --> case. If you refer >--> --> >>>>to being the DR the root bridge of the sbridge domain, >--> --> I think it must >--> --> >>>>be analyzed as a real alternative, even if it is not >--> --> the default >--> --> >>>>configuration. >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>>> In this case, the fact that we want to make the >--> --> solution plug >--> --> >>>>>and play means that we can reduce the potential for >--> --> disaster if we >--> --> >>>>>choose (and require) a specific default set of option >--> --> choices. If >--> --> >>>>>we can get away with it, however, we should simply >--> --> avoid options. >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>Agreed, but not for the root bridge problem because is >--> --> a real, practical >--> --> >>>>issue. >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>>> While having these same values as modes that >--> --> apply during >--> --> >>>>>certain transitional states is cleaner, it would >--> --> require a well- >--> --> >>>>>defined finite state-machine (not a particular >--> problem) and a >--> --> >>>>>genuine need for these behaviors under certain >--> --> circumstances. It >--> --> >>>>>may well be the case that this turns out to be true. >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>> >--> --> >>>>RSTP port state machines are there, may be they should >--> --> be taken into >--> --> >>>>consideration to make a consistent and integrated, but >--> --> not interwoven, >--> --> >>>>design for Rbridges that work with RSTP trees. Guillermo. >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>> >--> --> >>>>>-- >--> --> >>>>>Eric >--> --> >>>>> >--> --> >>>>>--> -----Original Message----- >--> --> >>>>>--> From: rbridge-bounces@postel.org >--> --> >>>>>--> [mailto:rbridge-bounces@postel.org]On >--> --> >>>>>--> Behalf Of Guillermo Ib??ez >--> --> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM >--> --> >>>>>--> To: Developing a hybrid router/bridge. >--> --> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> --> >>>>>--> >--> --> >>>>>--> >--> --> >>>>>--> I volunteer for some work on the capture, although my >--> --> >>>>>--> english might be >--> --> >>>>>--> not too understandable. From what date should >--> the capture >--> --> >>>>>--> to be done? >--> --> >>>>>--> >--> --> >>>>>--> Regarding PARTICIPATE PER PORT: >--> --> >>>>>--> Although I do not have a clear position, and it >--> --> requires detailed >--> --> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is >--> --> >>>>>--> better integrated >--> --> >>>>>--> with spanning tree, while maintaining the >--> basic decoupling >--> --> >>>>>--> that BLOCK >--> --> >>>>>--> provides. >--> --> >>>>>--> With PARTICIPATE PER PORT it would be possible to >--> --> force the elected >--> --> >>>>>--> Rbridge to become the sbridge root of the bridged >--> --> domain by >--> --> >>>>>--> modifying >--> --> >>>>>--> its bridge priority when it gets elected as >--> Designated by >--> --> >>>>>--> IS-IS (this >--> --> >>>>>--> could be an optimization). In this way the >--> path length is >--> --> >>>>>--> minimum from >--> --> >>>>>--> all bridges of bridged domain to the DR. >--> --> >>>>>--> >--> --> >>>>>--> >--> --> >>>>>--> Erik Nordmark wrote: >--> --> >>>>>--> >--> --> >>>>>--> >We've had some useful discussion on this mailing list. >--> --> >>>>>--> >It would be good if somebody can capture the results >--> --> >>>>>--> (perhaps as a long >--> --> >>>>>--> >email) that we can fold into the draft(s) later. >--> --> Any volunteers? >--> --> >>>>>--> > >--> --> >>>>>--> >I don't know if we will have additional >--> issues in this >--> --> >>>>>--> space or that it >--> --> >>>>>--> >otherwise makes sense devoting agenda time to it >--> --> in Vancouver. >--> --> >>>>>--> > >--> --> >>>>>--> >For instance, while I'm convinced that BLOCK works, I >--> --> >>>>>--> wonder if there is >--> --> >>>>>--> >something in PARTICIPATE PER PORT that can make the >--> --> >>>>>--> interaction work better. >--> --> >>>>>--> > >--> --> >>>>>--> >Two cases to consider: >--> --> >>>>>--> >1. The elected forwarder dies and a new one >--> gets elected. >--> --> >>>>>--> How quickly >--> --> >>>>>--> >can packets sent by stations in the bridged >--> cloud fail >--> --> >>>>>--> over to go to the >--> --> >>>>>--> >new elected forwarder? >--> --> >>>>>--> > >--> --> >>>>>--> > >--> --> >>>>>--> > >--> --> >>>>>--> My understanding is that if the forwarded dies, >--> --> the sbridge domain >--> --> >>>>>--> should handle it as a topology change >--> --> notification, tables of >--> --> >>>>>--> sbridges should be flushed according to the >--> spanning tree >--> --> >>>>>--> rules, so the >--> --> >>>>>--> sbridge domain must know the DR will not >--> forward frames as >--> --> >>>>>--> it used to. >--> --> >>>>>--> It seems Rbridge shall issue a Topology Change >--> --> Notification >--> --> >>>>>--> via sbridge >--> --> >>>>>--> domain to flush MAC tables. Is a fast >--> analysis, probably I >--> --> >>>>>--> miss details. >--> --> >>>>>--> >--> --> >>>>>--> >--> --> >>>>>--> >2. We have two separate bridged domains, each >--> --> with their elected >--> --> >>>>>--> >forwarder. Somebody connects the two bridged domains >--> --> >>>>>--> together with a >--> --> >>>>>--> >wire. This can cause a temporary loop until a single >--> --> >>>>>--> elected forwarder >--> --> >>>>>--> >is picked by the RBridges. >--> --> >>>>>--> > >--> --> >>>>>--> > >--> --> >>>>>--> > >--> --> >>>>>--> In this case the PARTICIPATE PER PORT seems >--> superior, as >--> --> >>>>>--> the two merged >--> --> >>>>>--> bridged domains will merge their spanning >--> trees into one >--> --> >>>>>--> and both DRs >--> --> >>>>>--> will compete to be the root of the merged tree, >--> --> this mechanism will >--> --> >>>>>--> likely be faster (via RSTP fast transit to >--> --> forwarding state >--> --> >>>>>--> over the >--> --> >>>>>--> bridged domain) than Designation to select the >--> --> unique DR. >--> --> >>>>>--> In other >--> --> >>>>>--> words , the mechanism of root election in >--> sbridge could be >--> --> >>>>>--> used to help >--> --> >>>>>--> in DR designation and/or viceversa. >--> --> >>>>>--> So I see in PARTICIPATE PER PORT, some >--> coupling between DR >--> --> >>>>>--> status and >--> --> >>>>>--> root status of sbridge domain that can be used >--> --> >>>>>--> to speed up convergence and coherence of both >--> domains. It >--> --> >>>>>--> seems that >--> --> >>>>>--> sbridge domains should be under the control of >--> --> Rbridges, but the >--> --> >>>>>--> sbridge mechanims should be used by Rbridges to >--> --> keep the network >--> --> >>>>>--> consistency and reconfiguration capabilities of RSTP. >--> --> >>>>>--> Guillermo >--> --> >>>>>--> >--> --> >>>>>--> >--> --> >>>>>--> _______________________________________________ >--> --> >>>>>--> 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 >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>> >--> --> >>_______________________________________________ >--> --> >>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 >--> >--> _______________________________________________ >--> 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 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 j9LLaAL17836 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:36:10 -0700 (PDT) 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 <0IOQ00334C02FF00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 14:36:02 -0700 (PDT) Received: from sun.com ([129.150.24.220]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOQ003HWC01TF00@mail.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 14:36:02 -0700 (PDT) Date: Fri, 21 Oct 2005 14:36:08 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4358DB9B.2090600@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43595F48.4040009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> <435815C0.4030502@Sun.COM> <43588B9D.5050306@it.uc3m.es> <435897F4.5030506@sun.com> <4358DB9B.2090600@it.uc3m.es> 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] RBridge/bridge interaction 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, 21 Oct 2005 21:37:03 -0000 Status: RO Content-Length: 1175 Guillermo Ib??ez wrote: > >With the client server model, dominant traffic is to and from the core >layer of campus network, so I think most of the traffic will flow >from/into Rbridge, not withing the islands. > > > If we buy that argument, then the same argument would say that routers should participate in the spanning tree and attempt to become Root. And what if there are multiple routers? If it's so vital for performance that one router is Root, then they'd all need to be Root within a bridged network. We shouldn't be trying to optimize that particular tree calculated by the bridged islands. Hopefully those trees would become smaller and smaller. And even if we did care about some type of optimality, I don't think trying to make one of the RBridges Root will make any difference. (Note "one of the RBridges"...there can be several RBridges on the bridged island, so at most one of them can be Root). People have lived for a long time without worrying about making one of the routers on a bridged LAN be the Root in order to attempt more optimal delivery of traffic on/off the bridged LAN. I don't think we should worry about it either. Radia 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 j9LLPTL14265 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:25:29 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1740B9D324 for <rbridge@postel.org>; Fri, 21 Oct 2005 23:25:23 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id E7A6C9D294 for <rbridge@postel.org>; Fri, 21 Oct 2005 23:25:21 +0200 (CEST) Message-ID: <43595CC3.2050606@it.uc3m.es> Date: Fri, 21 Oct 2005 23:25:23 +0200 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: <313680C9A886D511A06000204840E1CF0C885FD7@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FD7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 21:26:04 -0000 Status: RO Content-Length: 4648 Interesting. More scenarios like this are worth to analyze. With more internal bridges between RBridges. Guillermo Gray, Eric wrote: >RBridge Folks, > > A way to look at the concept of a layer two device that >handles looping possibilities/concerns in some way other than >by participating in STP - and is therefore not visible to STP >participants - is that it likely looks (to STP participants >- i.e. - 802/Ethernet bridges) like a single (possibly large) >bridged LAN segment. It is simply a link with a lot of MAC >addresses on it. This is generally true for any device that >lives in the Layer two world and is not an 802/Ethernet bridge, >a host, or a router. > > In the RBridge case, there are two bridging scenarios to >consider: bridges between RBridges (or two, or more, interfaces >of the same RBridge) and bridges attached to at most one RBridge >interface. We have loosely been referring to the former case as >"internal" bridges and the latter as "external" bridges, because >of the assumption that RBridges merge into a single campus and >- therefore - having more than one RBridge interface on a single >bridged LAN segment puts that segment "inside" the campus. > > Consequently, we can assume that there are no stable back >connections between "external" bridged LAN segments because any >such back connection will necessarily make affected "external" >LAN segments "internal". > > For example, in the following simple network: > > H1 H2 H3 > \ | / > RB1 > H4 --.__ / \ __.-- H5 > H6 ----->-- B1 -- B2 -- RB2 -- RB3 -- B3 --<----- H7 > H8 ----^ | \ / ___|________ > B4 \ / | | | | > _____|___ B5 L1 H9 H10 H11 > | | | |\ > H12 H13 L2 | \ > H14 H15 > >As shown, the LAN segment consisting of bridges B1, B2 and B4, hosts >H4, H6, H8, H12 and H13, and currently unused link L2 are an external >bridged LAN segment. The LAN segment consisting of bridge B3 and the >hosts H5, H7, H9, H10 and H11, and currently unused link L1 are also >an external bridged LAN segment. The LAN segment consisting of bridge >B5 and hosts H14 and H15 is an internal bridged LAN segment, while >hosts H1, H2 and H3 are on separate external LAN segments. > >Connecting bridges B3 and B4, by connecting currently unused links L1 >and L2 will make bridges B1-B4 and hosts H4-H13 all part of the same >_internal_ LAN segment. > >Other things to note about this network, as is, if RBridges ignore STP: > >o to the RBridges, the network looks like this - > > H1 H2 H3 > H4 -+ |__|__| +- H5 > | | | > H6 -+ RB1 +- H7 > | / \ | > H8 -+---- RB2 --- RB3 ------+- H9 > | \___/ | > H12 -+ | +- H10 > | __|__ | > H13 -+ | | +- H11 > H14 H15 > >o to bridges B1, B2 and B4, the network looks like this - > > +------ H1 > +- H2 > +------ H3 > H4 -+ +- H5 > | +------ H7 > H6 -+--- B1 -- B2 -----+- H9 > | | +------ H10 > H8 -+ B4 +- H11 > ___|_ +------ H14 > | | +- H15 > H12 H13 > >o to bridge B3, the network looks like this - > > H1 ------+ > H2 -+ > H3 ------+ +- H5 > H4 -+ | > H6 ------+---- B3 --------+- H7 > H8 -+ ___|_____ > H12 ------+ | | | > H13 -+ H9 H10 H11 > H14 ------+ > H15 -+ > >o because B5 is on an internal LAN segment, its view of host >and RBridge MAC addresses will be - at least in part - determined >by shortest path (spanning tree) computation; it might, for example >see the network like this (B5 rotated 45 degrees CCW) - > > H1 ------+ +---------+------ H2 > H4 -+ | +- H3 > H6 ------+----- B5 --+ +------ H5 > H8 -+ | | +- H7 > H12 ------+ | | +------ H9 > H13 -+ H14 H15 +- H10 > +------ H11 > >-- >Eric Gray > >_______________________________________________ >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 j9LLHBL11970 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:17:12 -0700 (PDT) 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 j9LLH6p1012160 for <rbridge@postel.org>; Fri, 21 Oct 2005 17:17:06 -0400 (EDT) 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 RAA05137 for <rbridge@postel.org>; Fri, 21 Oct 2005 17:17:05 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX62LA>; Fri, 21 Oct 2005 18:17:04 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FDD@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 18:17:03 -0300 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] RBridge/bridge interaction 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, 21 Oct 2005 21:18:09 -0000 Status: RO Content-Length: 25174 Guillermo, Here's the problem: in order for an RBridge to be the spanning tree root for bridges, it has to participate in bridge STP. Nothing else will work. However, it would be better from a simplicity perspective if the designated RBridge forwarder for a link were selected on a basis of proximity to the root bridge, rather than because it is the root bridge. Or it might just be "good enough" to take whatever happens to fall out and document some configuration steps that would make sense if there's a real problem in a given deployment. But there may be something to your concern for optimizing the root and designated forwarder equality as a critical aspect of the approach. This looks like an excellent opportunity for someone to run simulations using randomly generated bridge/RBridge topologies. The hypothesis is that having the designated forwarder for an internal RBridge link be something other than the spanning tree root will have significant impact on forwarding efficiency. It would be nice if the same topologies were used in simulations that assume: 1) total random selection of both spanning tree root and designated link forwarder - how likely are the best, average and worst cases? 2) a heuristic selection scheme: giving weight to selection of a designated forwarder likely to be adjacent to a spanning tree root - what will be the expected (average) impact on forwarding? 3) a deterministic approach that results in selecting a designated link forwarder with the shortest path adjacency to the STP root. The antithesis is that the expected (average) difference, and a combination of likelihood of worst case and worst case difference, are not significant - taken together to be worth added complexity (assume a factor of 2 in cost/complexity). One of the important factors to include in the simulations is that the effect on frame forwarding of having frames start at a leaf (or on a branch) as opposed to at the root is simply that it takes a slightly longer time for a broadcast frame to reach all the other branches and leaves if it doesn't start at the root, than it does if it does start at the root. So the problem is delay efficiency based rather than throughput efficiency based. The simulation must not - for example - assume that spanning tree forwarding works the same way as designated RBridge forwarding (it does not). For example, given the below quasi-random spanning tree (with B1 as root) and designated RBridge forwarder (RB1*): B1 --+ | | B6 --+ B12 --+-- RB5 | | | RB3 -- B5 --+ B4 B8 --+-- B10 | | | | | | B11 B2 B9 B3 B7 RB1* | | | | | RB7 RB2 RB4 RB8 RB6 Question: what is the real difference between having this situation (B1 root, RB1* designated forwarder) and either of the following: a) B1 root, RB5 designated forwarder - or b) RB5 both root and designated forwarder. Given that the broadcast forwarding paths for the initial case are: o RB1 o B10, B7, RB6 o B8, RB5 o B3, RB8 o B12, B4, B9, RB4 o B1, B6, B5, RB3 o B2, RB2 o B11, RB7 Case a): o RB5 o B8, B3, RB8 o B7, RB6 o B10, RB1 o B12, B4, B9, RB4 o B1, B6, B5, RB3 o B2, RB2 o B11, RB7 For case b), it is necessary to make some assumptions about 1) how many redundant paths there were, where the blocked ones were, and which will now be un-blocked by the spanning tree with RB5 as root. The average path length must be considered, rather than the worst case, because a broadcast frame might arrive at any RBridge (or any bridge, for that matter) - be forwarded to the designated forwarder along the spanning tree, and then forwarded along each of the paths determined (as shown above). I am pretty sure that the difference in average length of the path will not be that significant - especially looking at it as a delay factor rather than a throughput factor. If the average length of the paths differs by - for example - one bridge-to-bridge link, then it is probably reasonable to argue that (on average) there will be one additional link that is traversed twice (once raw and once encapsulated) for each broadcast frame. It does seem likely that it will not always be the same bridge-to- bridge link every time. But I suspect that it would be best if someone could take the time to simulate all this... -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Friday, October 21, 2005 1:50 PM --> To: 'Developing a hybrid router/bridge.' --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> My doubt is whether the DR Designation procedure is fast --> and reliable enough --> for reconfigurations of the islands communicating the --> Rbridges. Using the DR --> Rbridge as root bridge and linking the DR Designated role --> of Rbridge to the --> role of root bridge of the link, the root bridge election --> at the link --> could be used also as a faster and reliable mechanism for --> DR designation, as --> in fact the function is rather similar (although new: never --> a root bridge --> had Root port to forward and receive packets). It may sound --> complicated, I --> think in the long term it may be more complicated for --> Rbridges to be DRs of --> a link that they do not control. --> Guillermo --> --> -----Mensaje original----- --> De: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] En nombre --> de Gray, Eric --> Enviado el: viernes, 21 de octubre de 2005 19:07 --> Para: 'Developing a hybrid router/bridge.' --> Asunto: Re: [rbridge] RBridge/bridge interaction --> --> --> Guillermo, --> --> I had to think about what Radia was saying to realize --> that she is not objecting to merging one RBridge campus --> with another. If I --> understand correctly, what she is referring --> to is merging spanning trees between two islands (or pockets) of --> 802/Ethernet bridges separated by a R-Bridge campus. --> --> There's nothing to resolve, if the RBridge campus does --> not participate in STP, or transparently pass it through --> the campus from one --> island to another. --> --> So, I suspect that we are not looking for a way to solve --> the problem, since there is a way to avoid it. --> --> -- --> Eric Gray --> --> --> -----Original Message----- --> --> From: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org]On --> --> Behalf Of Guillermo Ib??ez --> --> Sent: Friday, October 21, 2005 8:14 AM --> --> To: Developing a hybrid router/bridge. --> --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> --> --> --> --> --> --> --> Radia Perlman wrote: --> --> --> --> >I don't think there's any reason, even if most of the --> --> traffic on the --> --> >link comes from the DR, for the --> --> >DR to be the root of the spanning tree. --> --> >What would be bad is if an RBridge, participating in --> two bridged --> --> >islands, winds up merging --> --> >the islands into a bigger island. --> --> > --> --> > --> --> Good point, but I think it can be solved. --> --> The merging of islands can be prevented if the RBridge --> --> acting as root --> --> limits to one port maximum in the Designated Port Role of --> --> spanning tree --> --> for sbridges. --> --> --> --> >The whole point is to make the bridged islands as small as --> --> possible, so --> --> >most forwarding is done --> --> >protected by hop count, and with optimal routes. --> --> > --> --> > --> --> > --> --> I'll admit that having RBridges *initiate* BPDUs --> --> --> --> >to vie for being Root is not as harmful as having them --> --> *forward* BPDUs --> --> >between --> --> >bridged islands (provided an RBridge is careful not to --> --> merge two islands --> --> >that would --> --> >have been separate if the RBridge had just been --> blocking BPDUs). --> --> > --> --> >We shouldn't make things more complex in an attempt to --> --> come up with a --> --> >"more optimal" --> --> >spanning tree within the bridged islands. --> --> > --> --> > --> --> --> --> >With a bidirectional tree, as happens with bridges, --> --> there's nothing --> --> >special about the Root. --> --> >Also, the traffic pattern might be such that most of the --> --> traffic is --> --> >between endnodes within --> --> >the island. --> --> > --> --> With the client server model, dominant traffic is to and --> --> from the core --> --> layer of campus network, so I think most of the traffic --> will flow --> --> from/into Rbridge, not withing the islands. --> --> --> --> >So there's really no reason to believe that having the --> --> >RBridge DR be the --> --> >spanning tree Root will result in better performance. And --> --> is certainly --> --> >complicates things. --> --> >And it also certainly is dangerous because of the --> --> potential of merging --> --> >islands. --> --> > --> --> > --> --> > --> --> I do not think is dangerous. The merging of islands is not --> --> convenient, --> --> but it can be prevented, limiting to one port the --> --> Designated Role in the --> --> root Rbridge. --> --> Guillermo --> --> --> --> >Radia --> --> > --> --> > --> --> > --> --> >Guillermo Ib??ez wrote: --> --> > --> --> > --> --> > --> --> >>I see the standard root election mechanism of spanning --> --> tree islands as --> --> >>the fastest and simpler mechanism for DR Rbridge --> --> designation. I see the --> --> >>DR Rbridge as being necessarily the ROOT bridge of that --> --> sbridged cloud --> --> >>(or "link"). The root bridge of a standard spanning --> tree is the --> --> >>"natural" source and sink point for the spanning tree. --> --> To do so, the DR --> --> >>must issue BPDUs to become the root bridge. This is part --> --> of what I --> --> >>mentioned days ago as PARTICIPATE PER PORT, but may be we --> --> should call it --> --> >>SOURCE OR SINK (participate, do not forward BPDUs, only --> --> send own BPDUs --> --> >>to contend to be the root bridge of the link). --> --> >>The consequence of this DR election mechanism is that the --> --> priority --> --> >>configured at Rbridges as bridge ID would determine their --> --> also their --> --> >>election priority as DRs. I think this keep both domains --> --> coordinated --> --> >>with a single mechanism. --> --> >>Guillermo --> --> >> --> --> >>Radia Perlman wrote: --> --> >> --> --> >> --> --> >> --> --> >> --> --> >> --> --> >>>I don't believe there should be options here. --> --> >>>It should be plug and play. --> --> >>>RBridges should BLOCK bridge spanning tree messages, --> --> >>>and isolate the bridged islands. --> --> >>> --> --> >>>I absolutely do not understand what people are --> --> >>>worried about with BLOCK. --> --> >>> --> --> >>>I suggest someone that actually thinks there is --> --> >>>some reason to do anything other than drop --> --> >>>spanning tree messages start a thread with --> --> >>>a subject line --> --> >>>"why it is good for RBridges to forward BPDUs", --> --> >>>and very very carefully explain from scratch --> --> >>>what the reasoning is. Not with a long --> --> >>>email quoting pieces of other emails, but --> --> >>>with a carefully crafted, from scratch explanation --> --> >>>of what you perceive as a problem with BLOCk, and --> --> >>>what the perceived benefit of ever having --> --> >>>RBridges forwarding BPDUs would --> --> >>>be. --> --> >>> --> --> >>>Oh...and there was a much earlier thread of the --> --> >>>thread about other devices that might forward --> --> >>>or drop BPDUs. There have always been things we --> --> >>>referred to as "simple bridges" that forwarded spanning tree --> --> >>>messages. I was careful to ensure that the spanning --> tree would --> --> >>>work with such devices. Of course the spanning tree --> would not --> --> >>>prevent a loop of all simple bridges, but if there --> was at least --> --> >>>one spanning tree bridge in the middle of every --> possible loop, --> --> >>>then there would wind up being no loops. --> --> >>> --> --> >>>You can think of "simple bridges" (ones that --> mindlessly forward --> --> >>>BPDUs) as a layer below bridges. They are invisible --> to bridges. --> --> >>>Bridges see a bunch of segments connected by simple --> bridges as a --> --> >>>single segment. (Just like RBridges will see a bunch --> of segments --> --> >>>connected by bridges as a single segment). --> --> >>> --> --> >>>Devices that drop BDPUs work if they are really --> --> >>>layered on top of bridges, i.e., they let the --> --> >>>bridges do their own thing to create isolated --> --> >>>broadcast domains, and then these other devices do --> --> >>>their own thing to glue these islands together. --> --> >>>Like routers do. And like RBridges will do. --> --> >>> --> --> >>>Radia --> --> >>> --> --> >>> --> --> >>> --> --> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,: --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>>>Eric, --> --> >>>> --> --> >>>> --> --> >>>>Gray, Eric wrote: --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>>>Guillermo, --> --> >>>>> --> --> >>>>> During the discussion, the terms TRANSPARENT, --> --> PARTICIPATE --> --> >>>>>and BLOCK were used (often in upper-case, exactly as I --> --> have used --> --> >>>>>them here) as if these would ultimately be options --> --> that might be --> --> >>>>>supported - either as a complete set, or as some subset. --> --> >>>>> --> --> >>>>> For example, one argument was that TRANSPARENT --> --> or PARTICIPATE --> --> >>>>>might be used, but BLOCK should not. --> --> >>>>> --> --> >>>>> Also, at certain points in the discussion, --> --> there was some --> --> >>>>>thought that these might be modes that applied at --> --> different states --> --> >>>>>during transitions in a network. --> --> >>>>> --> --> >>>>> From a practical stand-point - however - it --> --> would be best if --> --> >>>>>we did not have to support all of these, either as --> --> options, or as --> --> >>>>>modes. The mere fact that they were brought up does --> --> not mean we --> --> >>>>>are committed to including them. --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>Agreed --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>>> In particular, if we start talking about - for --> --> instance - --> --> >>>>>having a per-interface option for all of these choices --> --> (and maybe --> --> >>>>>others as well), then we either need to analyze --> proposals for --> --> >>>>>architecture and design to ensure that the "right --> things" will --> --> >>>>>happen when an arbitrary combination of all of these --> --> options is in --> --> >>>>>effect, or we need to define caveats for network --> --> operators to avoid --> --> >>>>>specific combinations of options. For example, we may --> --> need to say --> --> >>>>>that the same option must be set throughout the --> --> network or this and --> --> >>>>>that will (or may) happen. That kind of design begs --> --> configuration --> --> >>>>>errors to occur. --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>If you refer as configuration options per interface to --> --> the PARTICIPATE --> --> >>>>PER PORT mode as an option per port, it is not the --> --> case. If you refer --> --> >>>>to being the DR the root bridge of the sbridge domain, --> --> I think it must --> --> >>>>be analyzed as a real alternative, even if it is not --> --> the default --> --> >>>>configuration. --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>>> In this case, the fact that we want to make the --> --> solution plug --> --> >>>>>and play means that we can reduce the potential for --> --> disaster if we --> --> >>>>>choose (and require) a specific default set of option --> --> choices. If --> --> >>>>>we can get away with it, however, we should simply --> --> avoid options. --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>Agreed, but not for the root bridge problem because is --> --> a real, practical --> --> >>>>issue. --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>>> While having these same values as modes that --> --> apply during --> --> >>>>>certain transitional states is cleaner, it would --> --> require a well- --> --> >>>>>defined finite state-machine (not a particular --> problem) and a --> --> >>>>>genuine need for these behaviors under certain --> --> circumstances. It --> --> >>>>>may well be the case that this turns out to be true. --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>> --> --> >>>>RSTP port state machines are there, may be they should --> --> be taken into --> --> >>>>consideration to make a consistent and integrated, but --> --> not interwoven, --> --> >>>>design for Rbridges that work with RSTP trees. Guillermo. --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>> --> --> >>>>>-- --> --> >>>>>Eric --> --> >>>>> --> --> >>>>>--> -----Original Message----- --> --> >>>>>--> From: rbridge-bounces@postel.org --> --> >>>>>--> [mailto:rbridge-bounces@postel.org]On --> --> >>>>>--> Behalf Of Guillermo Ib??ez --> --> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM --> --> >>>>>--> To: Developing a hybrid router/bridge. --> --> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> --> >>>>>--> --> --> >>>>>--> --> --> >>>>>--> I volunteer for some work on the capture, although my --> --> >>>>>--> english might be --> --> >>>>>--> not too understandable. From what date should --> the capture --> --> >>>>>--> to be done? --> --> >>>>>--> --> --> >>>>>--> Regarding PARTICIPATE PER PORT: --> --> >>>>>--> Although I do not have a clear position, and it --> --> requires detailed --> --> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is --> --> >>>>>--> better integrated --> --> >>>>>--> with spanning tree, while maintaining the --> basic decoupling --> --> >>>>>--> that BLOCK --> --> >>>>>--> provides. --> --> >>>>>--> With PARTICIPATE PER PORT it would be possible to --> --> force the elected --> --> >>>>>--> Rbridge to become the sbridge root of the bridged --> --> domain by --> --> >>>>>--> modifying --> --> >>>>>--> its bridge priority when it gets elected as --> Designated by --> --> >>>>>--> IS-IS (this --> --> >>>>>--> could be an optimization). In this way the --> path length is --> --> >>>>>--> minimum from --> --> >>>>>--> all bridges of bridged domain to the DR. --> --> >>>>>--> --> --> >>>>>--> --> --> >>>>>--> Erik Nordmark wrote: --> --> >>>>>--> --> --> >>>>>--> >We've had some useful discussion on this mailing list. --> --> >>>>>--> >It would be good if somebody can capture the results --> --> >>>>>--> (perhaps as a long --> --> >>>>>--> >email) that we can fold into the draft(s) later. --> --> Any volunteers? --> --> >>>>>--> > --> --> >>>>>--> >I don't know if we will have additional --> issues in this --> --> >>>>>--> space or that it --> --> >>>>>--> >otherwise makes sense devoting agenda time to it --> --> in Vancouver. --> --> >>>>>--> > --> --> >>>>>--> >For instance, while I'm convinced that BLOCK works, I --> --> >>>>>--> wonder if there is --> --> >>>>>--> >something in PARTICIPATE PER PORT that can make the --> --> >>>>>--> interaction work better. --> --> >>>>>--> > --> --> >>>>>--> >Two cases to consider: --> --> >>>>>--> >1. The elected forwarder dies and a new one --> gets elected. --> --> >>>>>--> How quickly --> --> >>>>>--> >can packets sent by stations in the bridged --> cloud fail --> --> >>>>>--> over to go to the --> --> >>>>>--> >new elected forwarder? --> --> >>>>>--> > --> --> >>>>>--> > --> --> >>>>>--> > --> --> >>>>>--> My understanding is that if the forwarded dies, --> --> the sbridge domain --> --> >>>>>--> should handle it as a topology change --> --> notification, tables of --> --> >>>>>--> sbridges should be flushed according to the --> spanning tree --> --> >>>>>--> rules, so the --> --> >>>>>--> sbridge domain must know the DR will not --> forward frames as --> --> >>>>>--> it used to. --> --> >>>>>--> It seems Rbridge shall issue a Topology Change --> --> Notification --> --> >>>>>--> via sbridge --> --> >>>>>--> domain to flush MAC tables. Is a fast --> analysis, probably I --> --> >>>>>--> miss details. --> --> >>>>>--> --> --> >>>>>--> --> --> >>>>>--> >2. We have two separate bridged domains, each --> --> with their elected --> --> >>>>>--> >forwarder. Somebody connects the two bridged domains --> --> >>>>>--> together with a --> --> >>>>>--> >wire. This can cause a temporary loop until a single --> --> >>>>>--> elected forwarder --> --> >>>>>--> >is picked by the RBridges. --> --> >>>>>--> > --> --> >>>>>--> > --> --> >>>>>--> > --> --> >>>>>--> In this case the PARTICIPATE PER PORT seems --> superior, as --> --> >>>>>--> the two merged --> --> >>>>>--> bridged domains will merge their spanning --> trees into one --> --> >>>>>--> and both DRs --> --> >>>>>--> will compete to be the root of the merged tree, --> --> this mechanism will --> --> >>>>>--> likely be faster (via RSTP fast transit to --> --> forwarding state --> --> >>>>>--> over the --> --> >>>>>--> bridged domain) than Designation to select the --> --> unique DR. --> --> >>>>>--> In other --> --> >>>>>--> words , the mechanism of root election in --> sbridge could be --> --> >>>>>--> used to help --> --> >>>>>--> in DR designation and/or viceversa. --> --> >>>>>--> So I see in PARTICIPATE PER PORT, some --> coupling between DR --> --> >>>>>--> status and --> --> >>>>>--> root status of sbridge domain that can be used --> --> >>>>>--> to speed up convergence and coherence of both --> domains. It --> --> >>>>>--> seems that --> --> >>>>>--> sbridge domains should be under the control of --> --> Rbridges, but the --> --> >>>>>--> sbridge mechanims should be used by Rbridges to --> --> keep the network --> --> >>>>>--> consistency and reconfiguration capabilities of RSTP. --> --> >>>>>--> Guillermo --> --> >>>>>--> --> --> >>>>>--> --> --> >>>>>--> _______________________________________________ --> --> >>>>>--> 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 --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>_______________________________________________ --> --> >>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 --> --> _______________________________________________ --> 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 j9LLGAL11419 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:16:11 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AE0D69D2FD for <rbridge@postel.org>; Fri, 21 Oct 2005 23:16:04 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id 1804A9D2DD for <rbridge@postel.org>; Fri, 21 Oct 2005 23:16:03 +0200 (CEST) Message-ID: <43595A91.5040902@it.uc3m.es> Date: Fri, 21 Oct 2005 23:16:01 +0200 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: <313680C9A886D511A06000204840E1CF0C885FD6@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FD6@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 21 Oct 2005 21:17:03 -0000 Status: RO Content-Length: 18697 Root bridge planning is something required in campus networks, it just means configure the 16 bit priority of the preffered root bridge (and perhaps a root reserve) with a low enough value under the default value. This effort is peanuts if you compare with VLAN configuration, and it has been accepted without any opposition. The second point is how fast is the DR election process is actually. The third point is that "being aware of bridges" just means that RBridges participate in the root election process, where only the RBridges will apply to be root. Not a real issue. It is much more complex to handle per VLAN spanning trees. So it is only an apparent complexity. My feeling is that the "uncontrolled sbridge islands" will sooner or later require control. I understand that now is not wellcome to include the bridges in the design. Although we might like to make the RBridges fully independent of bridges, the whole is a system and must be slightly coordinated or we risk more unpredictable behaviour of specific situations that will at the end require more tight control of the spanning trees. I now realiza that the difference in view probably derives from the fact that Radia perhaps tend to think on STP, that provides timer-based convergence (slow), and I tend to think in RSTP (faster than IS-IS I presume). I might agree that both situations are different and STP is not an alternative due to slow convergence, but the current IEEE standard is RSTP, so it will be dominant in the near term in networks, decisions should be based on RSTP performance. Guillermo Gray, Eric wrote: >Guillermo, > > I think the point is that .coordination between bridges >and RBridges means at least RBridges have to be aware of the >bridges. I say this because having bridges be aware of the >RBridges - at least as RBridges - is not an option. > > Having even the RBridges being necessarily aware of all >bridges is unnecessary and would therefore add complexity to >RBridges. If you would like to make the point that the root >election process is not complicated, first I would disagree >(because - minimally - it adds complexity to a configuration >process, which is something we're trying to avoid) and second >I would point out that any complexity that is unecessary is a >complication that should be avoided. > > The processes of IS-IS and multicast DR election are, of >course, completely independent of the existence of bridges. > >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Guillermo Ib??ez >--> Sent: Friday, October 21, 2005 8:26 AM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> I agree suboptimality is not the key issue, but >--> coordination between STP >--> and RBridges regarding DR election (faster DR election >--> IMMO, although I >--> know nothing about IS-IS DR election) . Path optimization is a plus. >--> Guillermo >--> >--> Gray, Eric wrote: >--> >--> >Guillermo, >--> > >--> > Actually, the thing about a spanning tree is that >--> frames entering >--> >the tree will reach every node. Hence the result of >--> having an RBridge >--> >be something other than the root of the local spanning >--> tree would be >--> >that frame delivery might be sub-optimal. In fact, it is not even >--> >necessary for the R-Bridge to be directly connected to the >--> root of a >--> >local spanning tree. >--> > >--> > That's part of the reason why an RBridge does not need to be a >--> >part of the local STP. >--> > >--> > Given the way that spanning tree works in general, sub-optimal >--> >delivery of frames would not be something new. Having th >--> > >--> >-- >--> >Eric >--> > >--> >--> -----Original Message----- >--> >--> From: rbridge-bounces@postel.org >--> >--> [mailto:rbridge-bounces@postel.org]On >--> >--> Behalf Of Guillermo Ib??ez >--> >--> Sent: Friday, October 21, 2005 2:33 AM >--> >--> To: Radia.Perlman@Sun.COM; Developing a hybrid router/bridge. >--> >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> >--> >--> >--> >--> >--> I see the standard root election mechanism of spanning tree >--> >--> islands as >--> >--> the fastest and simpler mechanism for DR Rbridge >--> >--> designation. I see the >--> >--> DR Rbridge as being necessarily the ROOT bridge of that >--> >--> sbridged cloud >--> >--> (or "link"). The root bridge of a standard spanning >--> tree is the >--> >--> "natural" source and sink point for the spanning tree. To >--> >--> do so, the DR >--> >--> must issue BPDUs to become the root bridge. This is >--> part of what I >--> >--> mentioned days ago as PARTICIPATE PER PORT, but may be we >--> >--> should call it >--> >--> SOURCE OR SINK (participate, do not forward BPDUs, only >--> >--> send own BPDUs >--> >--> to contend to be the root bridge of the link). >--> >--> The consequence of this DR election mechanism is that >--> the priority >--> >--> configured at Rbridges as bridge ID would determine their >--> >--> also their >--> >--> election priority as DRs. I think this keep both domains >--> >--> coordinated >--> >--> with a single mechanism. >--> >--> Guillermo >--> >--> >--> >--> Radia Perlman wrote: >--> >--> >--> >--> >I don't believe there should be options here. >--> >--> >It should be plug and play. >--> >--> >RBridges should BLOCK bridge spanning tree messages, >--> >--> >and isolate the bridged islands. >--> >--> > >--> >--> >I absolutely do not understand what people are >--> >--> >worried about with BLOCK. >--> >--> > >--> >--> >I suggest someone that actually thinks there is >--> >--> >some reason to do anything other than drop >--> >--> >spanning tree messages start a thread with >--> >--> >a subject line >--> >--> >"why it is good for RBridges to forward BPDUs", >--> >--> >and very very carefully explain from scratch >--> >--> >what the reasoning is. Not with a long >--> >--> >email quoting pieces of other emails, but >--> >--> >with a carefully crafted, from scratch explanation >--> >--> >of what you perceive as a problem with BLOCk, and >--> >--> >what the perceived benefit of ever having >--> >--> >RBridges forwarding BPDUs would >--> >--> >be. >--> >--> > >--> >--> >Oh...and there was a much earlier thread of the >--> >--> >thread about other devices that might forward >--> >--> >or drop BPDUs. There have always been things we >--> >--> >referred to as "simple bridges" that forwarded spanning >--> >--> >tree messages. I was careful to ensure that the >--> >--> >spanning tree would work with such devices. Of course >--> >--> >the spanning tree would not prevent a loop of all >--> >--> >simple bridges, but if there was at least one spanning >--> >--> >tree bridge in the middle of every possible loop, then >--> >--> >there would wind up being no loops. >--> >--> > >--> >--> >You can think of "simple bridges" (ones that mindlessly >--> >--> >forward BPDUs) as a layer below bridges. They are >--> >--> >invisible to bridges. Bridges see a bunch of >--> >--> >segments connected by simple bridges as a single segment. >--> >--> >(Just like RBridges will see a bunch of segments connected >--> >--> >by bridges as a single segment). >--> >--> > >--> >--> >Devices that drop BDPUs work if they are really >--> >--> >layered on top of bridges, i.e., they let the >--> >--> >bridges do their own thing to create isolated >--> >--> >broadcast domains, and then these other devices do >--> >--> >their own thing to glue these islands together. >--> >--> >Like routers do. And like RBridges will do. >--> >--> > >--> >--> >Radia >--> >--> > >--> >--> > >--> >--> > >--> >--> >Guillermo Ib??ez wrote On 10/20/05 14:35,: >--> >--> > >--> >--> > >--> >--> >>Eric, >--> >--> >> >--> >--> >> >--> >--> >>Gray, Eric wrote: >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >>>Guillermo, >--> >--> >>> >--> >--> >>> During the discussion, the terms TRANSPARENT, >--> PARTICIPATE >--> >--> >>>and BLOCK were used (often in upper-case, exactly >--> as I have used >--> >--> >>>them here) as if these would ultimately be options >--> that might be >--> >--> >>>supported - either as a complete set, or as some subset. >--> >--> >>> >--> >--> >>> For example, one argument was that TRANSPARENT >--> or PARTICIPATE >--> >--> >>>might be used, but BLOCK should not. >--> >--> >>> >--> >--> >>> Also, at certain points in the discussion, >--> there was some >--> >--> >>>thought that these might be modes that applied at >--> >--> different states >--> >--> >>>during transitions in a network. >--> >--> >>> >--> >--> >>> From a practical stand-point - however - it >--> would be best if >--> >--> >>>we did not have to support all of these, either as >--> options, or as >--> >--> >>>modes. The mere fact that they were brought up >--> does not mean we >--> >--> >>>are committed to including them. >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>Agreed >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >>> In particular, if we start talking about - for >--> instance - >--> >--> >>>having a per-interface option for all of these >--> choices (and maybe >--> >--> >>>others as well), then we either need to analyze >--> proposals for >--> >--> >>>architecture and design to ensure that the "right >--> things" will >--> >--> >>>happen when an arbitrary combination of all of these >--> >--> options is in >--> >--> >>>effect, or we need to define caveats for network >--> >--> operators to avoid >--> >--> >>>specific combinations of options. For example, we may >--> >--> need to say >--> >--> >>>that the same option must be set throughout the network >--> >--> or this and >--> >--> >>>that will (or may) happen. That kind of design begs >--> >--> configuration >--> >--> >>>errors to occur. >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>If you refer as configuration options per interface to >--> >--> the PARTICIPATE >--> >--> >>PER PORT mode as an option per port, it is not the case. >--> >--> If you refer >--> >--> >>to being the DR the root bridge of the sbridge domain, I >--> >--> think it must >--> >--> >>be analyzed as a real alternative, even if it is not >--> the default >--> >--> >>configuration. >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >>> In this case, the fact that we want to make the >--> solution plug >--> >--> >>>and play means that we can reduce the potential for >--> >--> disaster if we >--> >--> >>>choose (and require) a specific default set of option >--> >--> choices. If >--> >--> >>>we can get away with it, however, we should simply >--> avoid options. >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>Agreed, but not for the root bridge problem because is a >--> >--> real, practical >--> >--> >>issue. >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >>> While having these same values as modes that >--> apply during >--> >--> >>>certain transitional states is cleaner, it would >--> require a well- >--> >--> >>>defined finite state-machine (not a particular >--> problem) and a >--> >--> >>>genuine need for these behaviors under certain >--> circumstances. It >--> >--> >>>may well be the case that this turns out to be true. >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>> >--> >--> >>RSTP port state machines are there, may be they should be >--> >--> taken into >--> >--> >>consideration to make a consistent and integrated, but >--> >--> not interwoven, >--> >--> >>design for Rbridges that work with RSTP trees. >--> >--> >>Guillermo. >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >> >--> >--> >>>-- >--> >--> >>>Eric >--> >--> >>> >--> >--> >>>--> -----Original Message----- >--> >--> >>>--> From: rbridge-bounces@postel.org >--> >--> >>>--> [mailto:rbridge-bounces@postel.org]On >--> >--> >>>--> Behalf Of Guillermo Ib??ez >--> >--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM >--> >--> >>>--> To: Developing a hybrid router/bridge. >--> >--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >>>--> >--> >--> >>>--> >--> >--> >>>--> I volunteer for some work on the capture, although my >--> >--> >>>--> english might be >--> >--> >>>--> not too understandable. From what date should >--> the capture >--> >--> >>>--> to be done? >--> >--> >>>--> >--> >--> >>>--> Regarding PARTICIPATE PER PORT: >--> >--> >>>--> Although I do not have a clear position, and it >--> >--> requires detailed >--> >--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is >--> >--> >>>--> better integrated >--> >--> >>>--> with spanning tree, while maintaining the basic >--> decoupling >--> >--> >>>--> that BLOCK >--> >--> >>>--> provides. >--> >--> >>>--> With PARTICIPATE PER PORT it would be possible to >--> >--> force the elected >--> >--> >>>--> Rbridge to become the sbridge root of the >--> bridged domain by >--> >--> >>>--> modifying >--> >--> >>>--> its bridge priority when it gets elected as >--> Designated by >--> >--> >>>--> IS-IS (this >--> >--> >>>--> could be an optimization). In this way the path >--> length is >--> >--> >>>--> minimum from >--> >--> >>>--> all bridges of bridged domain to the DR. >--> >--> >>>--> >--> >--> >>>--> >--> >--> >>>--> Erik Nordmark wrote: >--> >--> >>>--> >--> >--> >>>--> >We've had some useful discussion on this mailing list. >--> >--> >>>--> >It would be good if somebody can capture the results >--> >--> >>>--> (perhaps as a long >--> >--> >>>--> >email) that we can fold into the draft(s) later. >--> >--> Any volunteers? >--> >--> >>>--> > >--> >--> >>>--> >I don't know if we will have additional issues in this >--> >--> >>>--> space or that it >--> >--> >>>--> >otherwise makes sense devoting agenda time to it in >--> >--> Vancouver. >--> >--> >>>--> > >--> >--> >>>--> >For instance, while I'm convinced that BLOCK works, I >--> >--> >>>--> wonder if there is >--> >--> >>>--> >something in PARTICIPATE PER PORT that can make the >--> >--> >>>--> interaction work better. >--> >--> >>>--> > >--> >--> >>>--> >Two cases to consider: >--> >--> >>>--> >1. The elected forwarder dies and a new one >--> gets elected. >--> >--> >>>--> How quickly >--> >--> >>>--> >can packets sent by stations in the bridged cloud fail >--> >--> >>>--> over to go to the >--> >--> >>>--> >new elected forwarder? >--> >--> >>>--> > >--> >--> >>>--> > >--> >--> >>>--> > >--> >--> >>>--> My understanding is that if the forwarded dies, the >--> >--> sbridge domain >--> >--> >>>--> should handle it as a topology change >--> >--> notification, tables of >--> >--> >>>--> sbridges should be flushed according to the >--> spanning tree >--> >--> >>>--> rules, so the >--> >--> >>>--> sbridge domain must know the DR will not >--> forward frames as >--> >--> >>>--> it used to. >--> >--> >>>--> It seems Rbridge shall issue a Topology Change >--> Notification >--> >--> >>>--> via sbridge >--> >--> >>>--> domain to flush MAC tables. Is a fast analysis, >--> probably I >--> >--> >>>--> miss details. >--> >--> >>>--> >--> >--> >>>--> >--> >--> >>>--> >2. We have two separate bridged domains, each with >--> >--> their elected >--> >--> >>>--> >forwarder. Somebody connects the two bridged domains >--> >--> >>>--> together with a >--> >--> >>>--> >wire. This can cause a temporary loop until a single >--> >--> >>>--> elected forwarder >--> >--> >>>--> >is picked by the RBridges. >--> >--> >>>--> > >--> >--> >>>--> > >--> >--> >>>--> > >--> >--> >>>--> In this case the PARTICIPATE PER PORT seems >--> superior, as >--> >--> >>>--> the two merged >--> >--> >>>--> bridged domains will merge their spanning trees >--> into one >--> >--> >>>--> and both DRs >--> >--> >>>--> will compete to be the root of the merged tree, this >--> >--> mechanism will >--> >--> >>>--> likely be faster (via RSTP fast transit to >--> forwarding state >--> >--> >>>--> over the >--> >--> >>>--> bridged domain) than Designation to select >--> the unique DR. >--> >--> >>>--> In other >--> >--> >>>--> words , the mechanism of root election in >--> sbridge could be >--> >--> >>>--> used to help >--> >--> >>>--> in DR designation and/or viceversa. >--> >--> >>>--> So I see in PARTICIPATE PER PORT, some coupling >--> between DR >--> >--> >>>--> status and >--> >--> >>>--> root status of sbridge domain that can be used >--> >--> >>>--> to speed up convergence and coherence of both >--> domains. It >--> >--> >>>--> seems that >--> >--> >>>--> sbridge domains should be under the control of >--> >--> Rbridges, but the >--> >--> >>>--> sbridge mechanims should be used by Rbridges to keep >--> >--> the network >--> >--> >>>--> consistency and reconfiguration capabilities of RSTP. >--> >--> >>>--> Guillermo >--> >--> >>>--> >--> >--> >>>--> >--> >--> >>>--> _______________________________________________ >--> >--> >>>--> 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 >--> >--> > >--> >--> > >--> >--> > >--> >--> _______________________________________________ >--> >--> 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 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 j9LJ9lL00960 for <rbridge@postel.org>; Fri, 21 Oct 2005 12:09:47 -0700 (PDT) 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 j9LJ9cp1009630 for <rbridge@postel.org>; Fri, 21 Oct 2005 15:09:38 -0400 (EDT) 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 PAA18626 for <rbridge@postel.org>; Fri, 21 Oct 2005 15:09:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX61FK>; Fri, 21 Oct 2005 16:09:25 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD9@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 16:09:24 -0300 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] R-Bridge Routing Requirements draft is now availabl e 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, 21 Oct 2005 19:10:01 -0000 Status: RO Content-Length: 1934 Peter, I can certainly add this as a separate subsection under section 3. In my own mind (wherever I misplaced it), I do not think there is a clear distinction between per-ingress and the combination of per-ingress and per-VLAN, but not everybody is going to think of VLAN IDs as part of a logical interface ID. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Peter Ashwood-Smith --> Sent: Friday, October 21, 2005 10:47 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now --> available --> --> --> --> For completeness in section "3. Issues", there is of course the --> possibility of --> Per-ingress/Per VLAN spanning trees. --> --> Peter --> --> > -----Original Message----- --> > From: rbridge-bounces@postel.org --> > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric --> > Sent: Thursday, October 20, 2005 5:56 PM --> > To: 'Developing a hybrid router/bridge.' --> > Subject: [rbridge] R-Bridge Routing Requirements draft is now --> > available --> > --> > --> > The draft "Routing Requirements in Support of R-Bridges" - --> > submitted last --> > Friday - is now available at: --> > --> http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.txt This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt and is very preliminary. I am looking for input for the various sections - particularly those that currently only contain "TBD" :-) This was one of the drafts that the working group felt would be required at the last meeting. -- Eric Gray _______________________________________________ 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 j9LJ2pL28788 for <rbridge@postel.org>; Fri, 21 Oct 2005 12:02:51 -0700 (PDT) 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 j9LJ2jp1009500 for <rbridge@postel.org>; Fri, 21 Oct 2005 15:02:46 -0400 (EDT) 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 PAA17559 for <rbridge@postel.org>; Fri, 21 Oct 2005 15:02:44 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX6D9G>; Fri, 21 Oct 2005 16:02:44 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD8@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 16:02:43 -0300 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] R-Bridge Routing Requirements draft is now availabl e 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, 21 Oct 2005 19:03:03 -0000 Status: RO Content-Length: 2124 Peter, Thanks for the comment(s). We can probably "argue" off-line about what it means to be "easy to define" in the IETF. Also, are we definitely talking about IS-IS as run directly over L2? -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Peter Ashwood-Smith --> Sent: Friday, October 21, 2005 10:29 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now --> available --> --> --> --> First comment: --> --> "IS-IS is a more appropriate choice than OSPF in this case --> because it is --> --> easy in IS-IS to define new TLVs for carrying new information" --> --> I don't think its the new TLVs that are much of a problem, --> after all its --> really a new protocol so we could tweak and extend without backward --> compatibility worries. However the fact IS-IS runs directly over L2 --> is to me the big plus. --> --> Peter --> --> > -----Original Message----- --> > From: rbridge-bounces@postel.org --> > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric --> > Sent: Thursday, October 20, 2005 5:56 PM --> > To: 'Developing a hybrid router/bridge.' --> > Subject: [rbridge] R-Bridge Routing Requirements draft is now --> > available --> > --> > --> > The draft "Routing Requirements in Support of R-Bridges" - --> > submitted last --> > Friday - is now available at: --> > --> http://www.ietf.org/internet-drafts/draft-gray-rbridge-routi ng-reqs-00.t xt This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt and is very preliminary. I am looking for input for the various sections - particularly those that currently only contain "TBD" :-) This was one of the drafts that the working group felt would be required at the last meeting. -- Eric Gray _______________________________________________ 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 j9LIwdL27523 for <rbridge@postel.org>; Fri, 21 Oct 2005 11:58:40 -0700 (PDT) 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 j9LIwYp1009402 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:58:34 -0400 (EDT) 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 OAA16859 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:58:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX6DYQ>; Fri, 21 Oct 2005 15:58:32 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD7@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 15:58:31 -0300 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] RBridge/bridge interaction 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, 21 Oct 2005 18:59:03 -0000 Status: RO Content-Length: 4254 RBridge Folks, A way to look at the concept of a layer two device that handles looping possibilities/concerns in some way other than by participating in STP - and is therefore not visible to STP participants - is that it likely looks (to STP participants - i.e. - 802/Ethernet bridges) like a single (possibly large) bridged LAN segment. It is simply a link with a lot of MAC addresses on it. This is generally true for any device that lives in the Layer two world and is not an 802/Ethernet bridge, a host, or a router. In the RBridge case, there are two bridging scenarios to consider: bridges between RBridges (or two, or more, interfaces of the same RBridge) and bridges attached to at most one RBridge interface. We have loosely been referring to the former case as "internal" bridges and the latter as "external" bridges, because of the assumption that RBridges merge into a single campus and - therefore - having more than one RBridge interface on a single bridged LAN segment puts that segment "inside" the campus. Consequently, we can assume that there are no stable back connections between "external" bridged LAN segments because any such back connection will necessarily make affected "external" LAN segments "internal". For example, in the following simple network: H1 H2 H3 \ | / RB1 H4 --.__ / \ __.-- H5 H6 ----->-- B1 -- B2 -- RB2 -- RB3 -- B3 --<----- H7 H8 ----^ | \ / ___|________ B4 \ / | | | | _____|___ B5 L1 H9 H10 H11 | | | |\ H12 H13 L2 | \ H14 H15 As shown, the LAN segment consisting of bridges B1, B2 and B4, hosts H4, H6, H8, H12 and H13, and currently unused link L2 are an external bridged LAN segment. The LAN segment consisting of bridge B3 and the hosts H5, H7, H9, H10 and H11, and currently unused link L1 are also an external bridged LAN segment. The LAN segment consisting of bridge B5 and hosts H14 and H15 is an internal bridged LAN segment, while hosts H1, H2 and H3 are on separate external LAN segments. Connecting bridges B3 and B4, by connecting currently unused links L1 and L2 will make bridges B1-B4 and hosts H4-H13 all part of the same _internal_ LAN segment. Other things to note about this network, as is, if RBridges ignore STP: o to the RBridges, the network looks like this - H1 H2 H3 H4 -+ |__|__| +- H5 | | | H6 -+ RB1 +- H7 | / \ | H8 -+---- RB2 --- RB3 ------+- H9 | \___/ | H12 -+ | +- H10 | __|__ | H13 -+ | | +- H11 H14 H15 o to bridges B1, B2 and B4, the network looks like this - +------ H1 +- H2 +------ H3 H4 -+ +- H5 | +------ H7 H6 -+--- B1 -- B2 -----+- H9 | | +------ H10 H8 -+ B4 +- H11 ___|_ +------ H14 | | +- H15 H12 H13 o to bridge B3, the network looks like this - H1 ------+ H2 -+ H3 ------+ +- H5 H4 -+ | H6 ------+---- B3 --------+- H7 H8 -+ ___|_____ H12 ------+ | | | H13 -+ H9 H10 H11 H14 ------+ H15 -+ o because B5 is on an internal LAN segment, its view of host and RBridge MAC addresses will be - at least in part - determined by shortest path (spanning tree) computation; it might, for example see the network like this (B5 rotated 45 degrees CCW) - H1 ------+ +---------+------ H2 H4 -+ | +- H3 H6 ------+----- B5 --+ +------ H5 H8 -+ | | +- H7 H12 ------+ | | +------ H9 H13 -+ H14 H15 +- H10 +------ H11 -- Eric Gray 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 j9LHnoL05394 for <rbridge@postel.org>; Fri, 21 Oct 2005 10:49:51 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 568579D291 for <rbridge@postel.org>; Fri, 21 Oct 2005 19:49:44 +0200 (CEST) Received: from 11B111 (unknown [163.117.54.184]) by smtp01.uc3m.es (Postfix) with ESMTP id 89ADC9D2DA for <rbridge@postel.org>; Fri, 21 Oct 2005 19:49:43 +0200 (CEST) From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <gibanez@it.uc3m.es> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 19:49:43 +0200 Message-ID: <008c01c5d667$d1f001f0$b83675a3@ad.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FD5@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9LHnoL05394 Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 17:50:10 -0000 Status: RO Content-Length: 17647 My doubt is whether the DR Designation procedure is fast and reliable enough for reconfigurations of the islands communicating the Rbridges. Using the DR Rbridge as root bridge and linking the DR Designated role of Rbridge to the role of root bridge of the link, the root bridge election at the link could be used also as a faster and reliable mechanism for DR designation, as in fact the function is rather similar (although new: never a root bridge had Root port to forward and receive packets). It may sound complicated, I think in the long term it may be more complicated for Rbridges to be DRs of a link that they do not control. Guillermo -----Mensaje original----- De: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] En nombre de Gray, Eric Enviado el: viernes, 21 de octubre de 2005 19:07 Para: 'Developing a hybrid router/bridge.' Asunto: Re: [rbridge] RBridge/bridge interaction Guillermo, I had to think about what Radia was saying to realize that she is not objecting to merging one RBridge campus with another. If I understand correctly, what she is referring to is merging spanning trees between two islands (or pockets) of 802/Ethernet bridges separated by a R-Bridge campus. There's nothing to resolve, if the RBridge campus does not participate in STP, or transparently pass it through the campus from one island to another. So, I suspect that we are not looking for a way to solve the problem, since there is a way to avoid it. -- Eric Gray --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Friday, October 21, 2005 8:14 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> --> --> Radia Perlman wrote: --> --> >I don't think there's any reason, even if most of the --> traffic on the --> >link comes from the DR, for the --> >DR to be the root of the spanning tree. --> >What would be bad is if an RBridge, participating in two bridged --> >islands, winds up merging --> >the islands into a bigger island. --> > --> > --> Good point, but I think it can be solved. --> The merging of islands can be prevented if the RBridge --> acting as root --> limits to one port maximum in the Designated Port Role of --> spanning tree --> for sbridges. --> --> >The whole point is to make the bridged islands as small as --> possible, so --> >most forwarding is done --> >protected by hop count, and with optimal routes. --> > --> > --> > --> I'll admit that having RBridges *initiate* BPDUs --> --> >to vie for being Root is not as harmful as having them --> *forward* BPDUs --> >between --> >bridged islands (provided an RBridge is careful not to --> merge two islands --> >that would --> >have been separate if the RBridge had just been blocking BPDUs). --> > --> >We shouldn't make things more complex in an attempt to --> come up with a --> >"more optimal" --> >spanning tree within the bridged islands. --> > --> > --> --> >With a bidirectional tree, as happens with bridges, --> there's nothing --> >special about the Root. --> >Also, the traffic pattern might be such that most of the --> traffic is --> >between endnodes within --> >the island. --> > --> With the client server model, dominant traffic is to and --> from the core --> layer of campus network, so I think most of the traffic will flow --> from/into Rbridge, not withing the islands. --> --> >So there's really no reason to believe that having the --> >RBridge DR be the --> >spanning tree Root will result in better performance. And --> is certainly --> >complicates things. --> >And it also certainly is dangerous because of the --> potential of merging --> >islands. --> > --> > --> > --> I do not think is dangerous. The merging of islands is not --> convenient, --> but it can be prevented, limiting to one port the --> Designated Role in the --> root Rbridge. --> Guillermo --> --> >Radia --> > --> > --> > --> >Guillermo Ib??ez wrote: --> > --> > --> > --> >>I see the standard root election mechanism of spanning --> tree islands as --> >>the fastest and simpler mechanism for DR Rbridge --> designation. I see the --> >>DR Rbridge as being necessarily the ROOT bridge of that --> sbridged cloud --> >>(or "link"). The root bridge of a standard spanning tree is the --> >>"natural" source and sink point for the spanning tree. --> To do so, the DR --> >>must issue BPDUs to become the root bridge. This is part --> of what I --> >>mentioned days ago as PARTICIPATE PER PORT, but may be we --> should call it --> >>SOURCE OR SINK (participate, do not forward BPDUs, only --> send own BPDUs --> >>to contend to be the root bridge of the link). --> >>The consequence of this DR election mechanism is that the --> priority --> >>configured at Rbridges as bridge ID would determine their --> also their --> >>election priority as DRs. I think this keep both domains --> coordinated --> >>with a single mechanism. --> >>Guillermo --> >> --> >>Radia Perlman wrote: --> >> --> >> --> >> --> >> --> >> --> >>>I don't believe there should be options here. --> >>>It should be plug and play. --> >>>RBridges should BLOCK bridge spanning tree messages, --> >>>and isolate the bridged islands. --> >>> --> >>>I absolutely do not understand what people are --> >>>worried about with BLOCK. --> >>> --> >>>I suggest someone that actually thinks there is --> >>>some reason to do anything other than drop --> >>>spanning tree messages start a thread with --> >>>a subject line --> >>>"why it is good for RBridges to forward BPDUs", --> >>>and very very carefully explain from scratch --> >>>what the reasoning is. Not with a long --> >>>email quoting pieces of other emails, but --> >>>with a carefully crafted, from scratch explanation --> >>>of what you perceive as a problem with BLOCk, and --> >>>what the perceived benefit of ever having --> >>>RBridges forwarding BPDUs would --> >>>be. --> >>> --> >>>Oh...and there was a much earlier thread of the --> >>>thread about other devices that might forward --> >>>or drop BPDUs. There have always been things we --> >>>referred to as "simple bridges" that forwarded spanning tree --> >>>messages. I was careful to ensure that the spanning tree would --> >>>work with such devices. Of course the spanning tree would not --> >>>prevent a loop of all simple bridges, but if there was at least --> >>>one spanning tree bridge in the middle of every possible loop, --> >>>then there would wind up being no loops. --> >>> --> >>>You can think of "simple bridges" (ones that mindlessly forward --> >>>BPDUs) as a layer below bridges. They are invisible to bridges. --> >>>Bridges see a bunch of segments connected by simple bridges as a --> >>>single segment. (Just like RBridges will see a bunch of segments --> >>>connected by bridges as a single segment). --> >>> --> >>>Devices that drop BDPUs work if they are really --> >>>layered on top of bridges, i.e., they let the --> >>>bridges do their own thing to create isolated --> >>>broadcast domains, and then these other devices do --> >>>their own thing to glue these islands together. --> >>>Like routers do. And like RBridges will do. --> >>> --> >>>Radia --> >>> --> >>> --> >>> --> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,: --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>>>Eric, --> >>>> --> >>>> --> >>>>Gray, Eric wrote: --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>>Guillermo, --> >>>>> --> >>>>> During the discussion, the terms TRANSPARENT, --> PARTICIPATE --> >>>>>and BLOCK were used (often in upper-case, exactly as I --> have used --> >>>>>them here) as if these would ultimately be options --> that might be --> >>>>>supported - either as a complete set, or as some subset. --> >>>>> --> >>>>> For example, one argument was that TRANSPARENT --> or PARTICIPATE --> >>>>>might be used, but BLOCK should not. --> >>>>> --> >>>>> Also, at certain points in the discussion, --> there was some --> >>>>>thought that these might be modes that applied at --> different states --> >>>>>during transitions in a network. --> >>>>> --> >>>>> From a practical stand-point - however - it --> would be best if --> >>>>>we did not have to support all of these, either as --> options, or as --> >>>>>modes. The mere fact that they were brought up does --> not mean we --> >>>>>are committed to including them. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>Agreed --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>> In particular, if we start talking about - for --> instance - --> >>>>>having a per-interface option for all of these choices --> (and maybe --> >>>>>others as well), then we either need to analyze proposals for --> >>>>>architecture and design to ensure that the "right things" will --> >>>>>happen when an arbitrary combination of all of these --> options is in --> >>>>>effect, or we need to define caveats for network --> operators to avoid --> >>>>>specific combinations of options. For example, we may --> need to say --> >>>>>that the same option must be set throughout the --> network or this and --> >>>>>that will (or may) happen. That kind of design begs --> configuration --> >>>>>errors to occur. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>If you refer as configuration options per interface to --> the PARTICIPATE --> >>>>PER PORT mode as an option per port, it is not the --> case. If you refer --> >>>>to being the DR the root bridge of the sbridge domain, --> I think it must --> >>>>be analyzed as a real alternative, even if it is not --> the default --> >>>>configuration. --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>> In this case, the fact that we want to make the --> solution plug --> >>>>>and play means that we can reduce the potential for --> disaster if we --> >>>>>choose (and require) a specific default set of option --> choices. If --> >>>>>we can get away with it, however, we should simply --> avoid options. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>Agreed, but not for the root bridge problem because is --> a real, practical --> >>>>issue. --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>> While having these same values as modes that --> apply during --> >>>>>certain transitional states is cleaner, it would --> require a well- --> >>>>>defined finite state-machine (not a particular problem) and a --> >>>>>genuine need for these behaviors under certain --> circumstances. It --> >>>>>may well be the case that this turns out to be true. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>RSTP port state machines are there, may be they should --> be taken into --> >>>>consideration to make a consistent and integrated, but --> not interwoven, --> >>>>design for Rbridges that work with RSTP trees. Guillermo. --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>>-- --> >>>>>Eric --> >>>>> --> >>>>>--> -----Original Message----- --> >>>>>--> From: rbridge-bounces@postel.org --> >>>>>--> [mailto:rbridge-bounces@postel.org]On --> >>>>>--> Behalf Of Guillermo Ib??ez --> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM --> >>>>>--> To: Developing a hybrid router/bridge. --> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>>>>--> --> >>>>>--> --> >>>>>--> I volunteer for some work on the capture, although my --> >>>>>--> english might be --> >>>>>--> not too understandable. From what date should the capture --> >>>>>--> to be done? --> >>>>>--> --> >>>>>--> Regarding PARTICIPATE PER PORT: --> >>>>>--> Although I do not have a clear position, and it --> requires detailed --> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is --> >>>>>--> better integrated --> >>>>>--> with spanning tree, while maintaining the basic decoupling --> >>>>>--> that BLOCK --> >>>>>--> provides. --> >>>>>--> With PARTICIPATE PER PORT it would be possible to --> force the elected --> >>>>>--> Rbridge to become the sbridge root of the bridged --> domain by --> >>>>>--> modifying --> >>>>>--> its bridge priority when it gets elected as Designated by --> >>>>>--> IS-IS (this --> >>>>>--> could be an optimization). In this way the path length is --> >>>>>--> minimum from --> >>>>>--> all bridges of bridged domain to the DR. --> >>>>>--> --> >>>>>--> --> >>>>>--> Erik Nordmark wrote: --> >>>>>--> --> >>>>>--> >We've had some useful discussion on this mailing list. --> >>>>>--> >It would be good if somebody can capture the results --> >>>>>--> (perhaps as a long --> >>>>>--> >email) that we can fold into the draft(s) later. --> Any volunteers? --> >>>>>--> > --> >>>>>--> >I don't know if we will have additional issues in this --> >>>>>--> space or that it --> >>>>>--> >otherwise makes sense devoting agenda time to it --> in Vancouver. --> >>>>>--> > --> >>>>>--> >For instance, while I'm convinced that BLOCK works, I --> >>>>>--> wonder if there is --> >>>>>--> >something in PARTICIPATE PER PORT that can make the --> >>>>>--> interaction work better. --> >>>>>--> > --> >>>>>--> >Two cases to consider: --> >>>>>--> >1. The elected forwarder dies and a new one gets elected. --> >>>>>--> How quickly --> >>>>>--> >can packets sent by stations in the bridged cloud fail --> >>>>>--> over to go to the --> >>>>>--> >new elected forwarder? --> >>>>>--> > --> >>>>>--> > --> >>>>>--> > --> >>>>>--> My understanding is that if the forwarded dies, --> the sbridge domain --> >>>>>--> should handle it as a topology change --> notification, tables of --> >>>>>--> sbridges should be flushed according to the spanning tree --> >>>>>--> rules, so the --> >>>>>--> sbridge domain must know the DR will not forward frames as --> >>>>>--> it used to. --> >>>>>--> It seems Rbridge shall issue a Topology Change --> Notification --> >>>>>--> via sbridge --> >>>>>--> domain to flush MAC tables. Is a fast analysis, probably I --> >>>>>--> miss details. --> >>>>>--> --> >>>>>--> --> >>>>>--> >2. We have two separate bridged domains, each --> with their elected --> >>>>>--> >forwarder. Somebody connects the two bridged domains --> >>>>>--> together with a --> >>>>>--> >wire. This can cause a temporary loop until a single --> >>>>>--> elected forwarder --> >>>>>--> >is picked by the RBridges. --> >>>>>--> > --> >>>>>--> > --> >>>>>--> > --> >>>>>--> In this case the PARTICIPATE PER PORT seems superior, as --> >>>>>--> the two merged --> >>>>>--> bridged domains will merge their spanning trees into one --> >>>>>--> and both DRs --> >>>>>--> will compete to be the root of the merged tree, --> this mechanism will --> >>>>>--> likely be faster (via RSTP fast transit to --> forwarding state --> >>>>>--> over the --> >>>>>--> bridged domain) than Designation to select the --> unique DR. --> >>>>>--> In other --> >>>>>--> words , the mechanism of root election in sbridge could be --> >>>>>--> used to help --> >>>>>--> in DR designation and/or viceversa. --> >>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR --> >>>>>--> status and --> >>>>>--> root status of sbridge domain that can be used --> >>>>>--> to speed up convergence and coherence of both domains. It --> >>>>>--> seems that --> >>>>>--> sbridge domains should be under the control of --> Rbridges, but the --> >>>>>--> sbridge mechanims should be used by Rbridges to --> keep the network --> >>>>>--> consistency and reconfiguration capabilities of RSTP. --> >>>>>--> Guillermo --> >>>>>--> --> >>>>>--> --> >>>>>--> _______________________________________________ --> >>>>>--> 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 --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>_______________________________________________ --> >>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 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 j9LHJ9L25267 for <rbridge@postel.org>; Fri, 21 Oct 2005 10:19:10 -0700 (PDT) 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 j9LHJ3p1006776 for <rbridge@postel.org>; Fri, 21 Oct 2005 13:19:04 -0400 (EDT) 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 NAA02885 for <rbridge@postel.org>; Fri, 21 Oct 2005 13:19:03 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX6AB2>; Fri, 21 Oct 2005 14:19:02 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD6@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 14:19:00 -0300 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 j9LHJ9L25267 Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 17:20:29 -0000 Status: RO Content-Length: 16472 Guillermo, I think the point is that coordination between bridges and RBridges means at least RBridges have to be aware of the bridges. I say this because having bridges be aware of the RBridges - at least as RBridges - is not an option. Having even the RBridges being necessarily aware of all bridges is unnecessary and would therefore add complexity to RBridges. If you would like to make the point that the root election process is not complicated, first I would disagree (because - minimally - it adds complexity to a configuration process, which is something we're trying to avoid) and second I would point out that any complexity that is unecessary is a complication that should be avoided. The processes of IS-IS and multicast DR election are, of course, completely independent of the existence of bridges. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Friday, October 21, 2005 8:26 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> I agree suboptimality is not the key issue, but --> coordination between STP --> and RBridges regarding DR election (faster DR election --> IMMO, although I --> know nothing about IS-IS DR election) . Path optimization is a plus. --> Guillermo --> --> Gray, Eric wrote: --> --> >Guillermo, --> > --> > Actually, the thing about a spanning tree is that --> frames entering --> >the tree will reach every node. Hence the result of --> having an RBridge --> >be something other than the root of the local spanning --> tree would be --> >that frame delivery might be sub-optimal. In fact, it is not even --> >necessary for the R-Bridge to be directly connected to the --> root of a --> >local spanning tree. --> > --> > That's part of the reason why an RBridge does not need to be a --> >part of the local STP. --> > --> > Given the way that spanning tree works in general, sub-optimal --> >delivery of frames would not be something new. Having th --> > --> >-- --> >Eric --> > --> >--> -----Original Message----- --> >--> From: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org]On --> >--> Behalf Of Guillermo Ib??ez --> >--> Sent: Friday, October 21, 2005 2:33 AM --> >--> To: Radia.Perlman@Sun.COM; Developing a hybrid router/bridge. --> >--> Subject: Re: [rbridge] RBridge/bridge interaction --> >--> --> >--> --> >--> --> >--> I see the standard root election mechanism of spanning tree --> >--> islands as --> >--> the fastest and simpler mechanism for DR Rbridge --> >--> designation. I see the --> >--> DR Rbridge as being necessarily the ROOT bridge of that --> >--> sbridged cloud --> >--> (or "link"). The root bridge of a standard spanning --> tree is the --> >--> "natural" source and sink point for the spanning tree. To --> >--> do so, the DR --> >--> must issue BPDUs to become the root bridge. This is --> part of what I --> >--> mentioned days ago as PARTICIPATE PER PORT, but may be we --> >--> should call it --> >--> SOURCE OR SINK (participate, do not forward BPDUs, only --> >--> send own BPDUs --> >--> to contend to be the root bridge of the link). --> >--> The consequence of this DR election mechanism is that --> the priority --> >--> configured at Rbridges as bridge ID would determine their --> >--> also their --> >--> election priority as DRs. I think this keep both domains --> >--> coordinated --> >--> with a single mechanism. --> >--> Guillermo --> >--> --> >--> Radia Perlman wrote: --> >--> --> >--> >I don't believe there should be options here. --> >--> >It should be plug and play. --> >--> >RBridges should BLOCK bridge spanning tree messages, --> >--> >and isolate the bridged islands. --> >--> > --> >--> >I absolutely do not understand what people are --> >--> >worried about with BLOCK. --> >--> > --> >--> >I suggest someone that actually thinks there is --> >--> >some reason to do anything other than drop --> >--> >spanning tree messages start a thread with --> >--> >a subject line --> >--> >"why it is good for RBridges to forward BPDUs", --> >--> >and very very carefully explain from scratch --> >--> >what the reasoning is. Not with a long --> >--> >email quoting pieces of other emails, but --> >--> >with a carefully crafted, from scratch explanation --> >--> >of what you perceive as a problem with BLOCk, and --> >--> >what the perceived benefit of ever having --> >--> >RBridges forwarding BPDUs would --> >--> >be. --> >--> > --> >--> >Oh...and there was a much earlier thread of the --> >--> >thread about other devices that might forward --> >--> >or drop BPDUs. There have always been things we --> >--> >referred to as "simple bridges" that forwarded spanning --> >--> >tree messages. I was careful to ensure that the --> >--> >spanning tree would work with such devices. Of course --> >--> >the spanning tree would not prevent a loop of all --> >--> >simple bridges, but if there was at least one spanning --> >--> >tree bridge in the middle of every possible loop, then --> >--> >there would wind up being no loops. --> >--> > --> >--> >You can think of "simple bridges" (ones that mindlessly --> >--> >forward BPDUs) as a layer below bridges. They are --> >--> >invisible to bridges. Bridges see a bunch of --> >--> >segments connected by simple bridges as a single segment. --> >--> >(Just like RBridges will see a bunch of segments connected --> >--> >by bridges as a single segment). --> >--> > --> >--> >Devices that drop BDPUs work if they are really --> >--> >layered on top of bridges, i.e., they let the --> >--> >bridges do their own thing to create isolated --> >--> >broadcast domains, and then these other devices do --> >--> >their own thing to glue these islands together. --> >--> >Like routers do. And like RBridges will do. --> >--> > --> >--> >Radia --> >--> > --> >--> > --> >--> > --> >--> >Guillermo Ib??ez wrote On 10/20/05 14:35,: --> >--> > --> >--> > --> >--> >>Eric, --> >--> >> --> >--> >> --> >--> >>Gray, Eric wrote: --> >--> >> --> >--> >> --> >--> >> --> >--> >> --> >--> >>>Guillermo, --> >--> >>> --> >--> >>> During the discussion, the terms TRANSPARENT, --> PARTICIPATE --> >--> >>>and BLOCK were used (often in upper-case, exactly --> as I have used --> >--> >>>them here) as if these would ultimately be options --> that might be --> >--> >>>supported - either as a complete set, or as some subset. --> >--> >>> --> >--> >>> For example, one argument was that TRANSPARENT --> or PARTICIPATE --> >--> >>>might be used, but BLOCK should not. --> >--> >>> --> >--> >>> Also, at certain points in the discussion, --> there was some --> >--> >>>thought that these might be modes that applied at --> >--> different states --> >--> >>>during transitions in a network. --> >--> >>> --> >--> >>> From a practical stand-point - however - it --> would be best if --> >--> >>>we did not have to support all of these, either as --> options, or as --> >--> >>>modes. The mere fact that they were brought up --> does not mean we --> >--> >>>are committed to including them. --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>Agreed --> >--> >> --> >--> >> --> >--> >> --> >--> >> --> >--> >>> In particular, if we start talking about - for --> instance - --> >--> >>>having a per-interface option for all of these --> choices (and maybe --> >--> >>>others as well), then we either need to analyze --> proposals for --> >--> >>>architecture and design to ensure that the "right --> things" will --> >--> >>>happen when an arbitrary combination of all of these --> >--> options is in --> >--> >>>effect, or we need to define caveats for network --> >--> operators to avoid --> >--> >>>specific combinations of options. For example, we may --> >--> need to say --> >--> >>>that the same option must be set throughout the network --> >--> or this and --> >--> >>>that will (or may) happen. That kind of design begs --> >--> configuration --> >--> >>>errors to occur. --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>If you refer as configuration options per interface to --> >--> the PARTICIPATE --> >--> >>PER PORT mode as an option per port, it is not the case. --> >--> If you refer --> >--> >>to being the DR the root bridge of the sbridge domain, I --> >--> think it must --> >--> >>be analyzed as a real alternative, even if it is not --> the default --> >--> >>configuration. --> >--> >> --> >--> >> --> >--> >> --> >--> >> --> >--> >>> In this case, the fact that we want to make the --> solution plug --> >--> >>>and play means that we can reduce the potential for --> >--> disaster if we --> >--> >>>choose (and require) a specific default set of option --> >--> choices. If --> >--> >>>we can get away with it, however, we should simply --> avoid options. --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>Agreed, but not for the root bridge problem because is a --> >--> real, practical --> >--> >>issue. --> >--> >> --> >--> >> --> >--> >> --> >--> >> --> >--> >>> While having these same values as modes that --> apply during --> >--> >>>certain transitional states is cleaner, it would --> require a well- --> >--> >>>defined finite state-machine (not a particular --> problem) and a --> >--> >>>genuine need for these behaviors under certain --> circumstances. It --> >--> >>>may well be the case that this turns out to be true. --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>RSTP port state machines are there, may be they should be --> >--> taken into --> >--> >>consideration to make a consistent and integrated, but --> >--> not interwoven, --> >--> >>design for Rbridges that work with RSTP trees. --> >--> >>Guillermo. --> >--> >> --> >--> >> --> >--> >> --> >--> >> --> >--> >>>-- --> >--> >>>Eric --> >--> >>> --> >--> >>>--> -----Original Message----- --> >--> >>>--> From: rbridge-bounces@postel.org --> >--> >>>--> [mailto:rbridge-bounces@postel.org]On --> >--> >>>--> Behalf Of Guillermo Ib??ez --> >--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM --> >--> >>>--> To: Developing a hybrid router/bridge. --> >--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >--> >>>--> --> >--> >>>--> --> >--> >>>--> I volunteer for some work on the capture, although my --> >--> >>>--> english might be --> >--> >>>--> not too understandable. From what date should --> the capture --> >--> >>>--> to be done? --> >--> >>>--> --> >--> >>>--> Regarding PARTICIPATE PER PORT: --> >--> >>>--> Although I do not have a clear position, and it --> >--> requires detailed --> >--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is --> >--> >>>--> better integrated --> >--> >>>--> with spanning tree, while maintaining the basic --> decoupling --> >--> >>>--> that BLOCK --> >--> >>>--> provides. --> >--> >>>--> With PARTICIPATE PER PORT it would be possible to --> >--> force the elected --> >--> >>>--> Rbridge to become the sbridge root of the --> bridged domain by --> >--> >>>--> modifying --> >--> >>>--> its bridge priority when it gets elected as --> Designated by --> >--> >>>--> IS-IS (this --> >--> >>>--> could be an optimization). In this way the path --> length is --> >--> >>>--> minimum from --> >--> >>>--> all bridges of bridged domain to the DR. --> >--> >>>--> --> >--> >>>--> --> >--> >>>--> Erik Nordmark wrote: --> >--> >>>--> --> >--> >>>--> >We've had some useful discussion on this mailing list. --> >--> >>>--> >It would be good if somebody can capture the results --> >--> >>>--> (perhaps as a long --> >--> >>>--> >email) that we can fold into the draft(s) later. --> >--> Any volunteers? --> >--> >>>--> > --> >--> >>>--> >I don't know if we will have additional issues in this --> >--> >>>--> space or that it --> >--> >>>--> >otherwise makes sense devoting agenda time to it in --> >--> Vancouver. --> >--> >>>--> > --> >--> >>>--> >For instance, while I'm convinced that BLOCK works, I --> >--> >>>--> wonder if there is --> >--> >>>--> >something in PARTICIPATE PER PORT that can make the --> >--> >>>--> interaction work better. --> >--> >>>--> > --> >--> >>>--> >Two cases to consider: --> >--> >>>--> >1. The elected forwarder dies and a new one --> gets elected. --> >--> >>>--> How quickly --> >--> >>>--> >can packets sent by stations in the bridged cloud fail --> >--> >>>--> over to go to the --> >--> >>>--> >new elected forwarder? --> >--> >>>--> > --> >--> >>>--> > --> >--> >>>--> > --> >--> >>>--> My understanding is that if the forwarded dies, the --> >--> sbridge domain --> >--> >>>--> should handle it as a topology change --> >--> notification, tables of --> >--> >>>--> sbridges should be flushed according to the --> spanning tree --> >--> >>>--> rules, so the --> >--> >>>--> sbridge domain must know the DR will not --> forward frames as --> >--> >>>--> it used to. --> >--> >>>--> It seems Rbridge shall issue a Topology Change --> Notification --> >--> >>>--> via sbridge --> >--> >>>--> domain to flush MAC tables. Is a fast analysis, --> probably I --> >--> >>>--> miss details. --> >--> >>>--> --> >--> >>>--> --> >--> >>>--> >2. We have two separate bridged domains, each with --> >--> their elected --> >--> >>>--> >forwarder. Somebody connects the two bridged domains --> >--> >>>--> together with a --> >--> >>>--> >wire. This can cause a temporary loop until a single --> >--> >>>--> elected forwarder --> >--> >>>--> >is picked by the RBridges. --> >--> >>>--> > --> >--> >>>--> > --> >--> >>>--> > --> >--> >>>--> In this case the PARTICIPATE PER PORT seems --> superior, as --> >--> >>>--> the two merged --> >--> >>>--> bridged domains will merge their spanning trees --> into one --> >--> >>>--> and both DRs --> >--> >>>--> will compete to be the root of the merged tree, this --> >--> mechanism will --> >--> >>>--> likely be faster (via RSTP fast transit to --> forwarding state --> >--> >>>--> over the --> >--> >>>--> bridged domain) than Designation to select --> the unique DR. --> >--> >>>--> In other --> >--> >>>--> words , the mechanism of root election in --> sbridge could be --> >--> >>>--> used to help --> >--> >>>--> in DR designation and/or viceversa. --> >--> >>>--> So I see in PARTICIPATE PER PORT, some coupling --> between DR --> >--> >>>--> status and --> >--> >>>--> root status of sbridge domain that can be used --> >--> >>>--> to speed up convergence and coherence of both --> domains. It --> >--> >>>--> seems that --> >--> >>>--> sbridge domains should be under the control of --> >--> Rbridges, but the --> >--> >>>--> sbridge mechanims should be used by Rbridges to keep --> >--> the network --> >--> >>>--> consistency and reconfiguration capabilities of RSTP. --> >--> >>>--> Guillermo --> >--> >>>--> --> >--> >>>--> --> >--> >>>--> _______________________________________________ --> >--> >>>--> 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 --> >--> > --> >--> > --> >--> > --> >--> _______________________________________________ --> >--> 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 j9LH72L21157 for <rbridge@postel.org>; Fri, 21 Oct 2005 10:07:03 -0700 (PDT) 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 j9LH6up1006404 for <rbridge@postel.org>; Fri, 21 Oct 2005 13:06:57 -0400 (EDT) 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 NAA01334 for <rbridge@postel.org>; Fri, 21 Oct 2005 13:06:51 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX50S9>; Fri, 21 Oct 2005 14:06:50 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD5@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 14:06:49 -0300 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 j9LH72L21157 Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 17:08:07 -0000 Status: RO Content-Length: 16703 Guillermo, I had to think about what Radia was saying to realize that she is not objecting to merging one RBridge campus with another. If I understand correctly, what she is referring to is merging spanning trees between two islands (or pockets) of 802/Ethernet bridges separated by a R-Bridge campus. There's nothing to resolve, if the RBridge campus does not participate in STP, or transparently pass it through the campus from one island to another. So, I suspect that we are not looking for a way to solve the problem, since there is a way to avoid it. -- Eric Gray --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Friday, October 21, 2005 8:14 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> --> --> Radia Perlman wrote: --> --> >I don't think there's any reason, even if most of the --> traffic on the --> >link comes from the DR, for the --> >DR to be the root of the spanning tree. --> >What would be bad is if an RBridge, participating in two bridged --> >islands, winds up merging --> >the islands into a bigger island. --> > --> > --> Good point, but I think it can be solved. --> The merging of islands can be prevented if the RBridge --> acting as root --> limits to one port maximum in the Designated Port Role of --> spanning tree --> for sbridges. --> --> >The whole point is to make the bridged islands as small as --> possible, so --> >most forwarding is done --> >protected by hop count, and with optimal routes. --> > --> > --> > --> I'll admit that having RBridges *initiate* BPDUs --> --> >to vie for being Root is not as harmful as having them --> *forward* BPDUs --> >between --> >bridged islands (provided an RBridge is careful not to --> merge two islands --> >that would --> >have been separate if the RBridge had just been blocking BPDUs). --> > --> >We shouldn't make things more complex in an attempt to --> come up with a --> >"more optimal" --> >spanning tree within the bridged islands. --> > --> > --> --> >With a bidirectional tree, as happens with bridges, --> there's nothing --> >special about the Root. --> >Also, the traffic pattern might be such that most of the --> traffic is --> >between endnodes within --> >the island. --> > --> With the client server model, dominant traffic is to and --> from the core --> layer of campus network, so I think most of the traffic will flow --> from/into Rbridge, not withing the islands. --> --> >So there's really no reason to believe that having the --> >RBridge DR be the --> >spanning tree Root will result in better performance. And --> is certainly --> >complicates things. --> >And it also certainly is dangerous because of the --> potential of merging --> >islands. --> > --> > --> > --> I do not think is dangerous. The merging of islands is not --> convenient, --> but it can be prevented, limiting to one port the --> Designated Role in the --> root Rbridge. --> Guillermo --> --> >Radia --> > --> > --> > --> >Guillermo Ib??ez wrote: --> > --> > --> > --> >>I see the standard root election mechanism of spanning --> tree islands as --> >>the fastest and simpler mechanism for DR Rbridge --> designation. I see the --> >>DR Rbridge as being necessarily the ROOT bridge of that --> sbridged cloud --> >>(or "link"). The root bridge of a standard spanning tree is the --> >>"natural" source and sink point for the spanning tree. --> To do so, the DR --> >>must issue BPDUs to become the root bridge. This is part --> of what I --> >>mentioned days ago as PARTICIPATE PER PORT, but may be we --> should call it --> >>SOURCE OR SINK (participate, do not forward BPDUs, only --> send own BPDUs --> >>to contend to be the root bridge of the link). --> >>The consequence of this DR election mechanism is that the --> priority --> >>configured at Rbridges as bridge ID would determine their --> also their --> >>election priority as DRs. I think this keep both domains --> coordinated --> >>with a single mechanism. --> >>Guillermo --> >> --> >>Radia Perlman wrote: --> >> --> >> --> >> --> >> --> >> --> >>>I don't believe there should be options here. --> >>>It should be plug and play. --> >>>RBridges should BLOCK bridge spanning tree messages, --> >>>and isolate the bridged islands. --> >>> --> >>>I absolutely do not understand what people are --> >>>worried about with BLOCK. --> >>> --> >>>I suggest someone that actually thinks there is --> >>>some reason to do anything other than drop --> >>>spanning tree messages start a thread with --> >>>a subject line --> >>>"why it is good for RBridges to forward BPDUs", --> >>>and very very carefully explain from scratch --> >>>what the reasoning is. Not with a long --> >>>email quoting pieces of other emails, but --> >>>with a carefully crafted, from scratch explanation --> >>>of what you perceive as a problem with BLOCk, and --> >>>what the perceived benefit of ever having --> >>>RBridges forwarding BPDUs would --> >>>be. --> >>> --> >>>Oh...and there was a much earlier thread of the --> >>>thread about other devices that might forward --> >>>or drop BPDUs. There have always been things we --> >>>referred to as "simple bridges" that forwarded spanning --> >>>tree messages. I was careful to ensure that the --> >>>spanning tree would work with such devices. Of course --> >>>the spanning tree would not prevent a loop of all --> >>>simple bridges, but if there was at least one spanning --> >>>tree bridge in the middle of every possible loop, then --> >>>there would wind up being no loops. --> >>> --> >>>You can think of "simple bridges" (ones that mindlessly --> >>>forward BPDUs) as a layer below bridges. They are --> >>>invisible to bridges. Bridges see a bunch of --> >>>segments connected by simple bridges as a single segment. --> >>>(Just like RBridges will see a bunch of segments connected --> >>>by bridges as a single segment). --> >>> --> >>>Devices that drop BDPUs work if they are really --> >>>layered on top of bridges, i.e., they let the --> >>>bridges do their own thing to create isolated --> >>>broadcast domains, and then these other devices do --> >>>their own thing to glue these islands together. --> >>>Like routers do. And like RBridges will do. --> >>> --> >>>Radia --> >>> --> >>> --> >>> --> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,: --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>>>Eric, --> >>>> --> >>>> --> >>>>Gray, Eric wrote: --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>>Guillermo, --> >>>>> --> >>>>> During the discussion, the terms TRANSPARENT, --> PARTICIPATE --> >>>>>and BLOCK were used (often in upper-case, exactly as I --> have used --> >>>>>them here) as if these would ultimately be options --> that might be --> >>>>>supported - either as a complete set, or as some subset. --> >>>>> --> >>>>> For example, one argument was that TRANSPARENT --> or PARTICIPATE --> >>>>>might be used, but BLOCK should not. --> >>>>> --> >>>>> Also, at certain points in the discussion, --> there was some --> >>>>>thought that these might be modes that applied at --> different states --> >>>>>during transitions in a network. --> >>>>> --> >>>>> From a practical stand-point - however - it --> would be best if --> >>>>>we did not have to support all of these, either as --> options, or as --> >>>>>modes. The mere fact that they were brought up does --> not mean we --> >>>>>are committed to including them. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>Agreed --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>> In particular, if we start talking about - for --> instance - --> >>>>>having a per-interface option for all of these choices --> (and maybe --> >>>>>others as well), then we either need to analyze proposals for --> >>>>>architecture and design to ensure that the "right things" will --> >>>>>happen when an arbitrary combination of all of these --> options is in --> >>>>>effect, or we need to define caveats for network --> operators to avoid --> >>>>>specific combinations of options. For example, we may --> need to say --> >>>>>that the same option must be set throughout the --> network or this and --> >>>>>that will (or may) happen. That kind of design begs --> configuration --> >>>>>errors to occur. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>If you refer as configuration options per interface to --> the PARTICIPATE --> >>>>PER PORT mode as an option per port, it is not the --> case. If you refer --> >>>>to being the DR the root bridge of the sbridge domain, --> I think it must --> >>>>be analyzed as a real alternative, even if it is not --> the default --> >>>>configuration. --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>> In this case, the fact that we want to make the --> solution plug --> >>>>>and play means that we can reduce the potential for --> disaster if we --> >>>>>choose (and require) a specific default set of option --> choices. If --> >>>>>we can get away with it, however, we should simply --> avoid options. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>Agreed, but not for the root bridge problem because is --> a real, practical --> >>>>issue. --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>> While having these same values as modes that --> apply during --> >>>>>certain transitional states is cleaner, it would --> require a well- --> >>>>>defined finite state-machine (not a particular problem) and a --> >>>>>genuine need for these behaviors under certain --> circumstances. It --> >>>>>may well be the case that this turns out to be true. --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>> --> >>>>RSTP port state machines are there, may be they should --> be taken into --> >>>>consideration to make a consistent and integrated, but --> not interwoven, --> >>>>design for Rbridges that work with RSTP trees. --> >>>>Guillermo. --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>> --> >>>>>-- --> >>>>>Eric --> >>>>> --> >>>>>--> -----Original Message----- --> >>>>>--> From: rbridge-bounces@postel.org --> >>>>>--> [mailto:rbridge-bounces@postel.org]On --> >>>>>--> Behalf Of Guillermo Ib??ez --> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM --> >>>>>--> To: Developing a hybrid router/bridge. --> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>>>>--> --> >>>>>--> --> >>>>>--> I volunteer for some work on the capture, although my --> >>>>>--> english might be --> >>>>>--> not too understandable. From what date should the capture --> >>>>>--> to be done? --> >>>>>--> --> >>>>>--> Regarding PARTICIPATE PER PORT: --> >>>>>--> Although I do not have a clear position, and it --> requires detailed --> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is --> >>>>>--> better integrated --> >>>>>--> with spanning tree, while maintaining the basic decoupling --> >>>>>--> that BLOCK --> >>>>>--> provides. --> >>>>>--> With PARTICIPATE PER PORT it would be possible to --> force the elected --> >>>>>--> Rbridge to become the sbridge root of the bridged --> domain by --> >>>>>--> modifying --> >>>>>--> its bridge priority when it gets elected as Designated by --> >>>>>--> IS-IS (this --> >>>>>--> could be an optimization). In this way the path length is --> >>>>>--> minimum from --> >>>>>--> all bridges of bridged domain to the DR. --> >>>>>--> --> >>>>>--> --> >>>>>--> Erik Nordmark wrote: --> >>>>>--> --> >>>>>--> >We've had some useful discussion on this mailing list. --> >>>>>--> >It would be good if somebody can capture the results --> >>>>>--> (perhaps as a long --> >>>>>--> >email) that we can fold into the draft(s) later. --> Any volunteers? --> >>>>>--> > --> >>>>>--> >I don't know if we will have additional issues in this --> >>>>>--> space or that it --> >>>>>--> >otherwise makes sense devoting agenda time to it --> in Vancouver. --> >>>>>--> > --> >>>>>--> >For instance, while I'm convinced that BLOCK works, I --> >>>>>--> wonder if there is --> >>>>>--> >something in PARTICIPATE PER PORT that can make the --> >>>>>--> interaction work better. --> >>>>>--> > --> >>>>>--> >Two cases to consider: --> >>>>>--> >1. The elected forwarder dies and a new one gets elected. --> >>>>>--> How quickly --> >>>>>--> >can packets sent by stations in the bridged cloud fail --> >>>>>--> over to go to the --> >>>>>--> >new elected forwarder? --> >>>>>--> > --> >>>>>--> > --> >>>>>--> > --> >>>>>--> My understanding is that if the forwarded dies, --> the sbridge domain --> >>>>>--> should handle it as a topology change --> notification, tables of --> >>>>>--> sbridges should be flushed according to the spanning tree --> >>>>>--> rules, so the --> >>>>>--> sbridge domain must know the DR will not forward frames as --> >>>>>--> it used to. --> >>>>>--> It seems Rbridge shall issue a Topology Change --> Notification --> >>>>>--> via sbridge --> >>>>>--> domain to flush MAC tables. Is a fast analysis, probably I --> >>>>>--> miss details. --> >>>>>--> --> >>>>>--> --> >>>>>--> >2. We have two separate bridged domains, each --> with their elected --> >>>>>--> >forwarder. Somebody connects the two bridged domains --> >>>>>--> together with a --> >>>>>--> >wire. This can cause a temporary loop until a single --> >>>>>--> elected forwarder --> >>>>>--> >is picked by the RBridges. --> >>>>>--> > --> >>>>>--> > --> >>>>>--> > --> >>>>>--> In this case the PARTICIPATE PER PORT seems superior, as --> >>>>>--> the two merged --> >>>>>--> bridged domains will merge their spanning trees into one --> >>>>>--> and both DRs --> >>>>>--> will compete to be the root of the merged tree, --> this mechanism will --> >>>>>--> likely be faster (via RSTP fast transit to --> forwarding state --> >>>>>--> over the --> >>>>>--> bridged domain) than Designation to select the --> unique DR. --> >>>>>--> In other --> >>>>>--> words , the mechanism of root election in sbridge could be --> >>>>>--> used to help --> >>>>>--> in DR designation and/or viceversa. --> >>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR --> >>>>>--> status and --> >>>>>--> root status of sbridge domain that can be used --> >>>>>--> to speed up convergence and coherence of both domains. It --> >>>>>--> seems that --> >>>>>--> sbridge domains should be under the control of --> Rbridges, but the --> >>>>>--> sbridge mechanims should be used by Rbridges to --> keep the network --> >>>>>--> consistency and reconfiguration capabilities of RSTP. --> >>>>>--> Guillermo --> >>>>>--> --> >>>>>--> --> >>>>>--> _______________________________________________ --> >>>>>--> 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 --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>> --> >>_______________________________________________ --> >>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 sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9LFYHL22498 for <rbridge@postel.org>; Fri, 21 Oct 2005 08:34:17 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2005 08:34:12 -0700 X-IronPort-AV: i="3.97,239,1125903600"; d="scan'208"; a="668233926:sNHT24633420" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9LFXpJx021085 for <rbridge@postel.org>; Fri, 21 Oct 2005 08:34:10 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 08:34:03 -0700 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, 21 Oct 2005 08:34:02 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8E2E9C3@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXWEnhTcYc0N19JTne58EmrkCG4GAAQL2iQ From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 21 Oct 2005 15:34:03.0793 (UTC) FILETIME=[DDDF6810:01C5D654] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9LFYHL22498 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 21 Oct 2005 15:35:27 -0000 Status: RO Content-Length: 924 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > And I can't resist pointing out interesting technical > tidbits...with the bridge spanning tree, the packets go on > all the links, even if no other bridges will be picking up > the packet. Whereas with RBridges, if the link-state-computed > tree indicates no downstream receivers, then the packet is > not sent onto that port. Interesting, are you referring only to the encapsulated packets ? I would think that every link in the link-state-computed spanning tree would still need to see the unencapsulated packet. We may know that there are no rbridge receivers but we don't necessarily know about non-rbridge receivers. For any links that have peer rbridges downstream from the view of the spanning tree, there would end up being 2 packets transmitted. Michael > > Radia > Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9LElGL08084 for <rbridge@postel.org>; Fri, 21 Oct 2005 07:47:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9LEiSl21646 for <rbridge@postel.org>; Fri, 21 Oct 2005 10:44:28 -0400 (EDT) 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, 21 Oct 2005 10:47:06 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D59@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] R-Bridge Routing Requirements draft is now available Thread-Index: AcXVwajLocL/x33fQaOgYo4cHf4IKwAjDKLg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9LElGL08084 Subject: Re: [rbridge] R-Bridge Routing Requirements draft is 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: Fri, 21 Oct 2005 14:48:01 -0000 Status: RO Content-Length: 1064 For completeness in section "3. Issues", there is of course the possibility of Per-ingress/Per VLAN spanning trees. Peter > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric > Sent: Thursday, October 20, 2005 5:56 PM > To: 'Developing a hybrid router/bridge.' > Subject: [rbridge] R-Bridge Routing Requirements draft is now > available > > > The draft "Routing Requirements in Support of R-Bridges" - > submitted last > Friday - is now available at: > http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.t xt This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt and is very preliminary. I am looking for input for the various sections - particularly those that currently only contain "TBD" :-) This was one of the drafts that the working group felt would be required at the last meeting. -- Eric Gray _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9LETVL03440 for <rbridge@postel.org>; Fri, 21 Oct 2005 07:29:31 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9LESjF05570 for <rbridge@postel.org>; Fri, 21 Oct 2005 10:28:45 -0400 (EDT) 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, 21 Oct 2005 10:28:45 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D57@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] R-Bridge Routing Requirements draft is now available Thread-Index: AcXVwajLocL/x33fQaOgYo4cHf4IKwAiT57g From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9LETVL03440 Subject: Re: [rbridge] R-Bridge Routing Requirements draft is 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: Fri, 21 Oct 2005 14:30:00 -0000 Status: RO Content-Length: 1334 First comment: "IS-IS is a more appropriate choice than OSPF in this case because it is easy in IS-IS to define new TLVs for carrying new information" I don't think its the new TLVs that are much of a problem, after all its really a new protocol so we could tweak and extend without backward compatibility worries. However the fact IS-IS runs directly over L2 is to me the big plus. Peter > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric > Sent: Thursday, October 20, 2005 5:56 PM > To: 'Developing a hybrid router/bridge.' > Subject: [rbridge] R-Bridge Routing Requirements draft is now > available > > > The draft "Routing Requirements in Support of R-Bridges" - > submitted last > Friday - is now available at: > http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.t xt This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt and is very preliminary. I am looking for input for the various sections - particularly those that currently only contain "TBD" :-) This was one of the drafts that the working group felt would be required at the last meeting. -- Eric Gray _______________________________________________ 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 j9LCQ4L01838 for <rbridge@postel.org>; Fri, 21 Oct 2005 05:26:04 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 036B58360F for <rbridge@postel.org>; Fri, 21 Oct 2005 14:25:58 +0200 (CEST) Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 2E84E83630 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:25:57 +0200 (CEST) Message-ID: <4358DE56.1020006@it.uc3m.es> Date: Fri, 21 Oct 2005 14:25:58 +0200 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: <313680C9A886D511A06000204840E1CF0C885FD0@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FD0@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 21 Oct 2005 12:27:28 -0000 Status: RO Content-Length: 13469 I agree suboptimality is not the key issue, but coordination between STP and RBridges regarding DR election (faster DR election IMMO, although I know nothing about IS-IS DR election) . Path optimization is a plus. Guillermo Gray, Eric wrote: >Guillermo, > > Actually, the thing about a spanning tree is that frames entering >the tree will reach every node. Hence the result of having an RBridge >be something other than the root of the local spanning tree would be >that frame delivery might be sub-optimal. In fact, it is not even >necessary for the R-Bridge to be directly connected to the root of a >local spanning tree. > > That's part of the reason why an RBridge does not need to be a >part of the local STP. > > Given the way that spanning tree works in general, sub-optimal >delivery of frames would not be something new. Having th > >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Guillermo Ib??ez >--> Sent: Friday, October 21, 2005 2:33 AM >--> To: Radia.Perlman@Sun.COM; Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> >--> I see the standard root election mechanism of spanning tree >--> islands as >--> the fastest and simpler mechanism for DR Rbridge >--> designation. I see the >--> DR Rbridge as being necessarily the ROOT bridge of that >--> sbridged cloud >--> (or "link"). The root bridge of a standard spanning tree is the >--> "natural" source and sink point for the spanning tree. To >--> do so, the DR >--> must issue BPDUs to become the root bridge. This is part of what I >--> mentioned days ago as PARTICIPATE PER PORT, but may be we >--> should call it >--> SOURCE OR SINK (participate, do not forward BPDUs, only >--> send own BPDUs >--> to contend to be the root bridge of the link). >--> The consequence of this DR election mechanism is that the priority >--> configured at Rbridges as bridge ID would determine their >--> also their >--> election priority as DRs. I think this keep both domains >--> coordinated >--> with a single mechanism. >--> Guillermo >--> >--> Radia Perlman wrote: >--> >--> >I don't believe there should be options here. >--> >It should be plug and play. >--> >RBridges should BLOCK bridge spanning tree messages, >--> >and isolate the bridged islands. >--> > >--> >I absolutely do not understand what people are >--> >worried about with BLOCK. >--> > >--> >I suggest someone that actually thinks there is >--> >some reason to do anything other than drop >--> >spanning tree messages start a thread with >--> >a subject line >--> >"why it is good for RBridges to forward BPDUs", >--> >and very very carefully explain from scratch >--> >what the reasoning is. Not with a long >--> >email quoting pieces of other emails, but >--> >with a carefully crafted, from scratch explanation >--> >of what you perceive as a problem with BLOCk, and >--> >what the perceived benefit of ever having >--> >RBridges forwarding BPDUs would >--> >be. >--> > >--> >Oh...and there was a much earlier thread of the >--> >thread about other devices that might forward >--> >or drop BPDUs. There have always been things we >--> >referred to as "simple bridges" that forwarded spanning >--> >tree messages. I was careful to ensure that the >--> >spanning tree would work with such devices. Of course >--> >the spanning tree would not prevent a loop of all >--> >simple bridges, but if there was at least one spanning >--> >tree bridge in the middle of every possible loop, then >--> >there would wind up being no loops. >--> > >--> >You can think of "simple bridges" (ones that mindlessly >--> >forward BPDUs) as a layer below bridges. They are >--> >invisible to bridges. Bridges see a bunch of >--> >segments connected by simple bridges as a single segment. >--> >(Just like RBridges will see a bunch of segments connected >--> >by bridges as a single segment). >--> > >--> >Devices that drop BDPUs work if they are really >--> >layered on top of bridges, i.e., they let the >--> >bridges do their own thing to create isolated >--> >broadcast domains, and then these other devices do >--> >their own thing to glue these islands together. >--> >Like routers do. And like RBridges will do. >--> > >--> >Radia >--> > >--> > >--> > >--> >Guillermo Ib??ez wrote On 10/20/05 14:35,: >--> > >--> > >--> >>Eric, >--> >> >--> >> >--> >>Gray, Eric wrote: >--> >> >--> >> >--> >> >--> >> >--> >>>Guillermo, >--> >>> >--> >>> During the discussion, the terms TRANSPARENT, PARTICIPATE >--> >>>and BLOCK were used (often in upper-case, exactly as I have used >--> >>>them here) as if these would ultimately be options that might be >--> >>>supported - either as a complete set, or as some subset. >--> >>> >--> >>> For example, one argument was that TRANSPARENT or PARTICIPATE >--> >>>might be used, but BLOCK should not. >--> >>> >--> >>> Also, at certain points in the discussion, there was some >--> >>>thought that these might be modes that applied at >--> different states >--> >>>during transitions in a network. >--> >>> >--> >>> From a practical stand-point - however - it would be best if >--> >>>we did not have to support all of these, either as options, or as >--> >>>modes. The mere fact that they were brought up does not mean we >--> >>>are committed to including them. >--> >>> >--> >>> >--> >>> >--> >>> >--> >>> >--> >>Agreed >--> >> >--> >> >--> >> >--> >> >--> >>> In particular, if we start talking about - for instance - >--> >>>having a per-interface option for all of these choices (and maybe >--> >>>others as well), then we either need to analyze proposals for >--> >>>architecture and design to ensure that the "right things" will >--> >>>happen when an arbitrary combination of all of these >--> options is in >--> >>>effect, or we need to define caveats for network >--> operators to avoid >--> >>>specific combinations of options. For example, we may >--> need to say >--> >>>that the same option must be set throughout the network >--> or this and >--> >>>that will (or may) happen. That kind of design begs >--> configuration >--> >>>errors to occur. >--> >>> >--> >>> >--> >>> >--> >>> >--> >>> >--> >>If you refer as configuration options per interface to >--> the PARTICIPATE >--> >>PER PORT mode as an option per port, it is not the case. >--> If you refer >--> >>to being the DR the root bridge of the sbridge domain, I >--> think it must >--> >>be analyzed as a real alternative, even if it is not the default >--> >>configuration. >--> >> >--> >> >--> >> >--> >> >--> >>> In this case, the fact that we want to make the solution plug >--> >>>and play means that we can reduce the potential for >--> disaster if we >--> >>>choose (and require) a specific default set of option >--> choices. If >--> >>>we can get away with it, however, we should simply avoid options. >--> >>> >--> >>> >--> >>> >--> >>> >--> >>> >--> >>Agreed, but not for the root bridge problem because is a >--> real, practical >--> >>issue. >--> >> >--> >> >--> >> >--> >> >--> >>> While having these same values as modes that apply during >--> >>>certain transitional states is cleaner, it would require a well- >--> >>>defined finite state-machine (not a particular problem) and a >--> >>>genuine need for these behaviors under certain circumstances. It >--> >>>may well be the case that this turns out to be true. >--> >>> >--> >>> >--> >>> >--> >>> >--> >>> >--> >>RSTP port state machines are there, may be they should be >--> taken into >--> >>consideration to make a consistent and integrated, but >--> not interwoven, >--> >>design for Rbridges that work with RSTP trees. >--> >>Guillermo. >--> >> >--> >> >--> >> >--> >> >--> >>>-- >--> >>>Eric >--> >>> >--> >>>--> -----Original Message----- >--> >>>--> From: rbridge-bounces@postel.org >--> >>>--> [mailto:rbridge-bounces@postel.org]On >--> >>>--> Behalf Of Guillermo Ib??ez >--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM >--> >>>--> To: Developing a hybrid router/bridge. >--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >>>--> >--> >>>--> >--> >>>--> I volunteer for some work on the capture, although my >--> >>>--> english might be >--> >>>--> not too understandable. From what date should the capture >--> >>>--> to be done? >--> >>>--> >--> >>>--> Regarding PARTICIPATE PER PORT: >--> >>>--> Although I do not have a clear position, and it >--> requires detailed >--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is >--> >>>--> better integrated >--> >>>--> with spanning tree, while maintaining the basic decoupling >--> >>>--> that BLOCK >--> >>>--> provides. >--> >>>--> With PARTICIPATE PER PORT it would be possible to >--> force the elected >--> >>>--> Rbridge to become the sbridge root of the bridged domain by >--> >>>--> modifying >--> >>>--> its bridge priority when it gets elected as Designated by >--> >>>--> IS-IS (this >--> >>>--> could be an optimization). In this way the path length is >--> >>>--> minimum from >--> >>>--> all bridges of bridged domain to the DR. >--> >>>--> >--> >>>--> >--> >>>--> Erik Nordmark wrote: >--> >>>--> >--> >>>--> >We've had some useful discussion on this mailing list. >--> >>>--> >It would be good if somebody can capture the results >--> >>>--> (perhaps as a long >--> >>>--> >email) that we can fold into the draft(s) later. >--> Any volunteers? >--> >>>--> > >--> >>>--> >I don't know if we will have additional issues in this >--> >>>--> space or that it >--> >>>--> >otherwise makes sense devoting agenda time to it in >--> Vancouver. >--> >>>--> > >--> >>>--> >For instance, while I'm convinced that BLOCK works, I >--> >>>--> wonder if there is >--> >>>--> >something in PARTICIPATE PER PORT that can make the >--> >>>--> interaction work better. >--> >>>--> > >--> >>>--> >Two cases to consider: >--> >>>--> >1. The elected forwarder dies and a new one gets elected. >--> >>>--> How quickly >--> >>>--> >can packets sent by stations in the bridged cloud fail >--> >>>--> over to go to the >--> >>>--> >new elected forwarder? >--> >>>--> > >--> >>>--> > >--> >>>--> > >--> >>>--> My understanding is that if the forwarded dies, the >--> sbridge domain >--> >>>--> should handle it as a topology change >--> notification, tables of >--> >>>--> sbridges should be flushed according to the spanning tree >--> >>>--> rules, so the >--> >>>--> sbridge domain must know the DR will not forward frames as >--> >>>--> it used to. >--> >>>--> It seems Rbridge shall issue a Topology Change Notification >--> >>>--> via sbridge >--> >>>--> domain to flush MAC tables. Is a fast analysis, probably I >--> >>>--> miss details. >--> >>>--> >--> >>>--> >--> >>>--> >2. We have two separate bridged domains, each with >--> their elected >--> >>>--> >forwarder. Somebody connects the two bridged domains >--> >>>--> together with a >--> >>>--> >wire. This can cause a temporary loop until a single >--> >>>--> elected forwarder >--> >>>--> >is picked by the RBridges. >--> >>>--> > >--> >>>--> > >--> >>>--> > >--> >>>--> In this case the PARTICIPATE PER PORT seems superior, as >--> >>>--> the two merged >--> >>>--> bridged domains will merge their spanning trees into one >--> >>>--> and both DRs >--> >>>--> will compete to be the root of the merged tree, this >--> mechanism will >--> >>>--> likely be faster (via RSTP fast transit to forwarding state >--> >>>--> over the >--> >>>--> bridged domain) than Designation to select the unique DR. >--> >>>--> In other >--> >>>--> words , the mechanism of root election in sbridge could be >--> >>>--> used to help >--> >>>--> in DR designation and/or viceversa. >--> >>>--> So I see in PARTICIPATE PER PORT, some coupling between DR >--> >>>--> status and >--> >>>--> root status of sbridge domain that can be used >--> >>>--> to speed up convergence and coherence of both domains. It >--> >>>--> seems that >--> >>>--> sbridge domains should be under the control of >--> Rbridges, but the >--> >>>--> sbridge mechanims should be used by Rbridges to keep >--> the network >--> >>>--> consistency and reconfiguration capabilities of RSTP. >--> >>>--> Guillermo >--> >>>--> >--> >>>--> >--> >>>--> _______________________________________________ >--> >>>--> 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 >--> > >--> > >--> > >--> _______________________________________________ >--> 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 j9LCEOL28767 for <rbridge@postel.org>; Fri, 21 Oct 2005 05:14:25 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DA38C832F7 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:14:18 +0200 (CEST) Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id C5D8A835C8 for <rbridge@postel.org>; Fri, 21 Oct 2005 14:14:17 +0200 (CEST) Message-ID: <4358DB9B.2090600@it.uc3m.es> Date: Fri, 21 Oct 2005 14:14:19 +0200 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: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> <435815C0.4030502@Sun.COM> <43588B9D.5050306@it.uc3m.es> <435897F4.5030506@sun.com> In-Reply-To: <435897F4.5030506@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] RBridge/bridge interaction 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, 21 Oct 2005 12:15:30 -0000 Status: RO Content-Length: 13594 Radia Perlman wrote: >I don't think there's any reason, even if most of the traffic on the >link comes from the DR, for the >DR to be the root of the spanning tree. >What would be bad is if an RBridge, participating in two bridged >islands, winds up merging >the islands into a bigger island. > > Good point, but I think it can be solved. The merging of islands can be prevented if the RBridge acting as root limits to one port maximum in the Designated Port Role of spanning tree for sbridges. >The whole point is to make the bridged islands as small as possible, so >most forwarding is done >protected by hop count, and with optimal routes. > > > I'll admit that having RBridges *initiate* BPDUs >to vie for being Root is not as harmful as having them *forward* BPDUs >between >bridged islands (provided an RBridge is careful not to merge two islands >that would >have been separate if the RBridge had just been blocking BPDUs). > >We shouldn't make things more complex in an attempt to come up with a >"more optimal" >spanning tree within the bridged islands. > > >With a bidirectional tree, as happens with bridges, there's nothing >special about the Root. >Also, the traffic pattern might be such that most of the traffic is >between endnodes within >the island. > With the client server model, dominant traffic is to and from the core layer of campus network, so I think most of the traffic will flow from/into Rbridge, not withing the islands. >So there's really no reason to believe that having the >RBridge DR be the >spanning tree Root will result in better performance. And is certainly >complicates things. >And it also certainly is dangerous because of the potential of merging >islands. > > > I do not think is dangerous. The merging of islands is not convenient, but it can be prevented, limiting to one port the Designated Role in the root Rbridge. Guillermo >Radia > > > >Guillermo Ib??ez wrote: > > > >>I see the standard root election mechanism of spanning tree islands as >>the fastest and simpler mechanism for DR Rbridge designation. I see the >>DR Rbridge as being necessarily the ROOT bridge of that sbridged cloud >>(or "link"). The root bridge of a standard spanning tree is the >>"natural" source and sink point for the spanning tree. To do so, the DR >>must issue BPDUs to become the root bridge. This is part of what I >>mentioned days ago as PARTICIPATE PER PORT, but may be we should call it >>SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs >>to contend to be the root bridge of the link). >>The consequence of this DR election mechanism is that the priority >>configured at Rbridges as bridge ID would determine their also their >>election priority as DRs. I think this keep both domains coordinated >>with a single mechanism. >>Guillermo >> >>Radia Perlman wrote: >> >> >> >> >> >>>I don't believe there should be options here. >>>It should be plug and play. >>>RBridges should BLOCK bridge spanning tree messages, >>>and isolate the bridged islands. >>> >>>I absolutely do not understand what people are >>>worried about with BLOCK. >>> >>>I suggest someone that actually thinks there is >>>some reason to do anything other than drop >>>spanning tree messages start a thread with >>>a subject line >>>"why it is good for RBridges to forward BPDUs", >>>and very very carefully explain from scratch >>>what the reasoning is. Not with a long >>>email quoting pieces of other emails, but >>>with a carefully crafted, from scratch explanation >>>of what you perceive as a problem with BLOCk, and >>>what the perceived benefit of ever having >>>RBridges forwarding BPDUs would >>>be. >>> >>>Oh...and there was a much earlier thread of the >>>thread about other devices that might forward >>>or drop BPDUs. There have always been things we >>>referred to as "simple bridges" that forwarded spanning >>>tree messages. I was careful to ensure that the >>>spanning tree would work with such devices. Of course >>>the spanning tree would not prevent a loop of all >>>simple bridges, but if there was at least one spanning >>>tree bridge in the middle of every possible loop, then >>>there would wind up being no loops. >>> >>>You can think of "simple bridges" (ones that mindlessly >>>forward BPDUs) as a layer below bridges. They are >>>invisible to bridges. Bridges see a bunch of >>>segments connected by simple bridges as a single segment. >>>(Just like RBridges will see a bunch of segments connected >>>by bridges as a single segment). >>> >>>Devices that drop BDPUs work if they are really >>>layered on top of bridges, i.e., they let the >>>bridges do their own thing to create isolated >>>broadcast domains, and then these other devices do >>>their own thing to glue these islands together. >>>Like routers do. And like RBridges will do. >>> >>>Radia >>> >>> >>> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,: >>> >>> >>> >>> >>> >>> >>>>Eric, >>>> >>>> >>>>Gray, Eric wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Guillermo, >>>>> >>>>> During the discussion, the terms TRANSPARENT, PARTICIPATE >>>>>and BLOCK were used (often in upper-case, exactly as I have used >>>>>them here) as if these would ultimately be options that might be >>>>>supported - either as a complete set, or as some subset. >>>>> >>>>> For example, one argument was that TRANSPARENT or PARTICIPATE >>>>>might be used, but BLOCK should not. >>>>> >>>>> Also, at certain points in the discussion, there was some >>>>>thought that these might be modes that applied at different states >>>>>during transitions in a network. >>>>> >>>>> From a practical stand-point - however - it would be best if >>>>>we did not have to support all of these, either as options, or as >>>>>modes. The mere fact that they were brought up does not mean we >>>>>are committed to including them. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Agreed >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> In particular, if we start talking about - for instance - >>>>>having a per-interface option for all of these choices (and maybe >>>>>others as well), then we either need to analyze proposals for >>>>>architecture and design to ensure that the "right things" will >>>>>happen when an arbitrary combination of all of these options is in >>>>>effect, or we need to define caveats for network operators to avoid >>>>>specific combinations of options. For example, we may need to say >>>>>that the same option must be set throughout the network or this and >>>>>that will (or may) happen. That kind of design begs configuration >>>>>errors to occur. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>If you refer as configuration options per interface to the PARTICIPATE >>>>PER PORT mode as an option per port, it is not the case. If you refer >>>>to being the DR the root bridge of the sbridge domain, I think it must >>>>be analyzed as a real alternative, even if it is not the default >>>>configuration. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> In this case, the fact that we want to make the solution plug >>>>>and play means that we can reduce the potential for disaster if we >>>>>choose (and require) a specific default set of option choices. If >>>>>we can get away with it, however, we should simply avoid options. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Agreed, but not for the root bridge problem because is a real, practical >>>>issue. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> While having these same values as modes that apply during >>>>>certain transitional states is cleaner, it would require a well- >>>>>defined finite state-machine (not a particular problem) and a >>>>>genuine need for these behaviors under certain circumstances. It >>>>>may well be the case that this turns out to be true. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>RSTP port state machines are there, may be they should be taken into >>>>consideration to make a consistent and integrated, but not interwoven, >>>>design for Rbridges that work with RSTP trees. >>>>Guillermo. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-- >>>>>Eric >>>>> >>>>>--> -----Original Message----- >>>>>--> From: rbridge-bounces@postel.org >>>>>--> [mailto:rbridge-bounces@postel.org]On >>>>>--> Behalf Of Guillermo Ib??ez >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM >>>>>--> To: Developing a hybrid router/bridge. >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction >>>>>--> >>>>>--> >>>>>--> I volunteer for some work on the capture, although my >>>>>--> english might be >>>>>--> not too understandable. From what date should the capture >>>>>--> to be done? >>>>>--> >>>>>--> Regarding PARTICIPATE PER PORT: >>>>>--> Although I do not have a clear position, and it requires detailed >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is >>>>>--> better integrated >>>>>--> with spanning tree, while maintaining the basic decoupling >>>>>--> that BLOCK >>>>>--> provides. >>>>>--> With PARTICIPATE PER PORT it would be possible to force the elected >>>>>--> Rbridge to become the sbridge root of the bridged domain by >>>>>--> modifying >>>>>--> its bridge priority when it gets elected as Designated by >>>>>--> IS-IS (this >>>>>--> could be an optimization). In this way the path length is >>>>>--> minimum from >>>>>--> all bridges of bridged domain to the DR. >>>>>--> >>>>>--> >>>>>--> Erik Nordmark wrote: >>>>>--> >>>>>--> >We've had some useful discussion on this mailing list. >>>>>--> >It would be good if somebody can capture the results >>>>>--> (perhaps as a long >>>>>--> >email) that we can fold into the draft(s) later. Any volunteers? >>>>>--> > >>>>>--> >I don't know if we will have additional issues in this >>>>>--> space or that it >>>>>--> >otherwise makes sense devoting agenda time to it in Vancouver. >>>>>--> > >>>>>--> >For instance, while I'm convinced that BLOCK works, I >>>>>--> wonder if there is >>>>>--> >something in PARTICIPATE PER PORT that can make the >>>>>--> interaction work better. >>>>>--> > >>>>>--> >Two cases to consider: >>>>>--> >1. The elected forwarder dies and a new one gets elected. >>>>>--> How quickly >>>>>--> >can packets sent by stations in the bridged cloud fail >>>>>--> over to go to the >>>>>--> >new elected forwarder? >>>>>--> > >>>>>--> > >>>>>--> > >>>>>--> My understanding is that if the forwarded dies, the sbridge domain >>>>>--> should handle it as a topology change notification, tables of >>>>>--> sbridges should be flushed according to the spanning tree >>>>>--> rules, so the >>>>>--> sbridge domain must know the DR will not forward frames as >>>>>--> it used to. >>>>>--> It seems Rbridge shall issue a Topology Change Notification >>>>>--> via sbridge >>>>>--> domain to flush MAC tables. Is a fast analysis, probably I >>>>>--> miss details. >>>>>--> >>>>>--> >>>>>--> >2. We have two separate bridged domains, each with their elected >>>>>--> >forwarder. Somebody connects the two bridged domains >>>>>--> together with a >>>>>--> >wire. This can cause a temporary loop until a single >>>>>--> elected forwarder >>>>>--> >is picked by the RBridges. >>>>>--> > >>>>>--> > >>>>>--> > >>>>>--> In this case the PARTICIPATE PER PORT seems superior, as >>>>>--> the two merged >>>>>--> bridged domains will merge their spanning trees into one >>>>>--> and both DRs >>>>>--> will compete to be the root of the merged tree, this mechanism will >>>>>--> likely be faster (via RSTP fast transit to forwarding state >>>>>--> over the >>>>>--> bridged domain) than Designation to select the unique DR. >>>>>--> In other >>>>>--> words , the mechanism of root election in sbridge could be >>>>>--> used to help >>>>>--> in DR designation and/or viceversa. >>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR >>>>>--> status and >>>>>--> root status of sbridge domain that can be used >>>>>--> to speed up convergence and coherence of both domains. It >>>>>--> seems that >>>>>--> sbridge domains should be under the control of Rbridges, but the >>>>>--> sbridge mechanims should be used by Rbridges to keep the network >>>>>--> consistency and reconfiguration capabilities of RSTP. >>>>>--> Guillermo >>>>>--> >>>>>--> >>>>>--> _______________________________________________ >>>>>--> 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 >>> >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>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 j9LBQwL16903 for <rbridge@postel.org>; Fri, 21 Oct 2005 04:26:58 -0700 (PDT) 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 j9LBQrp1028173; Fri, 21 Oct 2005 07:26:53 -0400 (EDT) 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 HAA19063; Fri, 21 Oct 2005 07:26:52 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX54A6>; Fri, 21 Oct 2005 08:26:52 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD3@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 21 Oct 2005 08:26:50 -0300 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 j9LBQwL16903 Cc: "'Radia.Perlman@Sun.COM'" <Radia.Perlman@Sun.COM> Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 11:28:01 -0000 Status: RO Content-Length: 14765 Guillermo, Sorry, part way through my last sentence, Outlook decided to go ahead and send it. Please just ignore the "Having th" at the end. It wasn't very important anyway... :-) -- Eric --> -----Original Message----- --> From: Gray, Eric --> Sent: Friday, October 21, 2005 6:39 AM --> To: 'Developing a hybrid router/bridge.'; Radia.Perlman@Sun.COM --> Subject: RE: [rbridge] RBridge/bridge interaction --> --> --> Guillermo, --> --> Actually, the thing about a spanning tree is that frames entering --> the tree will reach every node. Hence the result of having an RBridge --> be something other than the root of the local spanning tree would be --> that frame delivery might be sub-optimal. In fact, it is not even --> necessary for the R-Bridge to be directly connected to the root of a --> local spanning tree. --> --> That's part of the reason why an RBridge does not need to be a --> part of the local STP. --> --> Given the way that spanning tree works in general, sub-optimal --> delivery of frames would not be something new. Having th --> --> -- --> Eric --> --> --> -----Original Message----- --> --> From: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org]On --> --> Behalf Of Guillermo Ib??ez --> --> Sent: Friday, October 21, 2005 2:33 AM --> --> To: Radia.Perlman@Sun.COM; Developing a hybrid router/bridge. --> --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> --> --> --> --> --> I see the standard root election mechanism of spanning tree --> --> islands as --> --> the fastest and simpler mechanism for DR Rbridge --> --> designation. I see the --> --> DR Rbridge as being necessarily the ROOT bridge of that --> --> sbridged cloud --> --> (or "link"). The root bridge of a standard spanning tree is the --> --> "natural" source and sink point for the spanning tree. To --> --> do so, the DR --> --> must issue BPDUs to become the root bridge. This is --> part of what I --> --> mentioned days ago as PARTICIPATE PER PORT, but may be we --> --> should call it --> --> SOURCE OR SINK (participate, do not forward BPDUs, only --> --> send own BPDUs --> --> to contend to be the root bridge of the link). --> --> The consequence of this DR election mechanism is that --> the priority --> --> configured at Rbridges as bridge ID would determine their --> --> also their --> --> election priority as DRs. I think this keep both domains --> --> coordinated --> --> with a single mechanism. --> --> Guillermo --> --> --> --> Radia Perlman wrote: --> --> --> --> >I don't believe there should be options here. --> --> >It should be plug and play. --> --> >RBridges should BLOCK bridge spanning tree messages, --> --> >and isolate the bridged islands. --> --> > --> --> >I absolutely do not understand what people are --> --> >worried about with BLOCK. --> --> > --> --> >I suggest someone that actually thinks there is --> --> >some reason to do anything other than drop --> --> >spanning tree messages start a thread with --> --> >a subject line --> --> >"why it is good for RBridges to forward BPDUs", --> --> >and very very carefully explain from scratch --> --> >what the reasoning is. Not with a long --> --> >email quoting pieces of other emails, but --> --> >with a carefully crafted, from scratch explanation --> --> >of what you perceive as a problem with BLOCk, and --> --> >what the perceived benefit of ever having --> --> >RBridges forwarding BPDUs would --> --> >be. --> --> > --> --> >Oh...and there was a much earlier thread of the --> --> >thread about other devices that might forward --> --> >or drop BPDUs. There have always been things we --> --> >referred to as "simple bridges" that forwarded spanning --> --> >tree messages. I was careful to ensure that the --> --> >spanning tree would work with such devices. Of course --> --> >the spanning tree would not prevent a loop of all --> --> >simple bridges, but if there was at least one spanning --> --> >tree bridge in the middle of every possible loop, then --> --> >there would wind up being no loops. --> --> > --> --> >You can think of "simple bridges" (ones that mindlessly --> --> >forward BPDUs) as a layer below bridges. They are --> --> >invisible to bridges. Bridges see a bunch of --> --> >segments connected by simple bridges as a single segment. --> --> >(Just like RBridges will see a bunch of segments connected --> --> >by bridges as a single segment). --> --> > --> --> >Devices that drop BDPUs work if they are really --> --> >layered on top of bridges, i.e., they let the --> --> >bridges do their own thing to create isolated --> --> >broadcast domains, and then these other devices do --> --> >their own thing to glue these islands together. --> --> >Like routers do. And like RBridges will do. --> --> > --> --> >Radia --> --> > --> --> > --> --> > --> --> >Guillermo Ib??ez wrote On 10/20/05 14:35,: --> --> > --> --> > --> --> >>Eric, --> --> >> --> --> >> --> --> >>Gray, Eric wrote: --> --> >> --> --> >> --> --> >> --> --> >> --> --> >>>Guillermo, --> --> >>> --> --> >>> During the discussion, the terms TRANSPARENT, --> PARTICIPATE --> --> >>>and BLOCK were used (often in upper-case, exactly as --> I have used --> --> >>>them here) as if these would ultimately be options --> that might be --> --> >>>supported - either as a complete set, or as some subset. --> --> >>> --> --> >>> For example, one argument was that TRANSPARENT --> or PARTICIPATE --> --> >>>might be used, but BLOCK should not. --> --> >>> --> --> >>> Also, at certain points in the discussion, --> there was some --> --> >>>thought that these might be modes that applied at --> --> different states --> --> >>>during transitions in a network. --> --> >>> --> --> >>> From a practical stand-point - however - it --> would be best if --> --> >>>we did not have to support all of these, either as --> options, or as --> --> >>>modes. The mere fact that they were brought up does --> not mean we --> --> >>>are committed to including them. --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>Agreed --> --> >> --> --> >> --> --> >> --> --> >> --> --> >>> In particular, if we start talking about - for --> instance - --> --> >>>having a per-interface option for all of these --> choices (and maybe --> --> >>>others as well), then we either need to analyze --> proposals for --> --> >>>architecture and design to ensure that the "right --> things" will --> --> >>>happen when an arbitrary combination of all of these --> --> options is in --> --> >>>effect, or we need to define caveats for network --> --> operators to avoid --> --> >>>specific combinations of options. For example, we may --> --> need to say --> --> >>>that the same option must be set throughout the network --> --> or this and --> --> >>>that will (or may) happen. That kind of design begs --> --> configuration --> --> >>>errors to occur. --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>If you refer as configuration options per interface to --> --> the PARTICIPATE --> --> >>PER PORT mode as an option per port, it is not the case. --> --> If you refer --> --> >>to being the DR the root bridge of the sbridge domain, I --> --> think it must --> --> >>be analyzed as a real alternative, even if it is not --> the default --> --> >>configuration. --> --> >> --> --> >> --> --> >> --> --> >> --> --> >>> In this case, the fact that we want to make the --> solution plug --> --> >>>and play means that we can reduce the potential for --> --> disaster if we --> --> >>>choose (and require) a specific default set of option --> --> choices. If --> --> >>>we can get away with it, however, we should simply --> avoid options. --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>Agreed, but not for the root bridge problem because is a --> --> real, practical --> --> >>issue. --> --> >> --> --> >> --> --> >> --> --> >> --> --> >>> While having these same values as modes that --> apply during --> --> >>>certain transitional states is cleaner, it would --> require a well- --> --> >>>defined finite state-machine (not a particular --> problem) and a --> --> >>>genuine need for these behaviors under certain --> circumstances. It --> --> >>>may well be the case that this turns out to be true. --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>> --> --> >>RSTP port state machines are there, may be they should be --> --> taken into --> --> >>consideration to make a consistent and integrated, but --> --> not interwoven, --> --> >>design for Rbridges that work with RSTP trees. --> --> >>Guillermo. --> --> >> --> --> >> --> --> >> --> --> >> --> --> >>>-- --> --> >>>Eric --> --> >>> --> --> >>>--> -----Original Message----- --> --> >>>--> From: rbridge-bounces@postel.org --> --> >>>--> [mailto:rbridge-bounces@postel.org]On --> --> >>>--> Behalf Of Guillermo Ib??ez --> --> >>>--> Sent: Thursday, October 20, 2005 4:19 PM --> --> >>>--> To: Developing a hybrid router/bridge. --> --> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> --> >>>--> --> --> >>>--> --> --> >>>--> I volunteer for some work on the capture, although my --> --> >>>--> english might be --> --> >>>--> not too understandable. From what date should --> the capture --> --> >>>--> to be done? --> --> >>>--> --> --> >>>--> Regarding PARTICIPATE PER PORT: --> --> >>>--> Although I do not have a clear position, and it --> --> requires detailed --> --> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is --> --> >>>--> better integrated --> --> >>>--> with spanning tree, while maintaining the basic --> decoupling --> --> >>>--> that BLOCK --> --> >>>--> provides. --> --> >>>--> With PARTICIPATE PER PORT it would be possible to --> --> force the elected --> --> >>>--> Rbridge to become the sbridge root of the --> bridged domain by --> --> >>>--> modifying --> --> >>>--> its bridge priority when it gets elected as --> Designated by --> --> >>>--> IS-IS (this --> --> >>>--> could be an optimization). In this way the path --> length is --> --> >>>--> minimum from --> --> >>>--> all bridges of bridged domain to the DR. --> --> >>>--> --> --> >>>--> --> --> >>>--> Erik Nordmark wrote: --> --> >>>--> --> --> >>>--> >We've had some useful discussion on this mailing list. --> --> >>>--> >It would be good if somebody can capture the results --> --> >>>--> (perhaps as a long --> --> >>>--> >email) that we can fold into the draft(s) later. --> --> Any volunteers? --> --> >>>--> > --> --> >>>--> >I don't know if we will have additional issues in this --> --> >>>--> space or that it --> --> >>>--> >otherwise makes sense devoting agenda time to it in --> --> Vancouver. --> --> >>>--> > --> --> >>>--> >For instance, while I'm convinced that BLOCK works, I --> --> >>>--> wonder if there is --> --> >>>--> >something in PARTICIPATE PER PORT that can make the --> --> >>>--> interaction work better. --> --> >>>--> > --> --> >>>--> >Two cases to consider: --> --> >>>--> >1. The elected forwarder dies and a new one --> gets elected. --> --> >>>--> How quickly --> --> >>>--> >can packets sent by stations in the bridged cloud fail --> --> >>>--> over to go to the --> --> >>>--> >new elected forwarder? --> --> >>>--> > --> --> >>>--> > --> --> >>>--> > --> --> >>>--> My understanding is that if the forwarded dies, the --> --> sbridge domain --> --> >>>--> should handle it as a topology change --> --> notification, tables of --> --> >>>--> sbridges should be flushed according to the --> spanning tree --> --> >>>--> rules, so the --> --> >>>--> sbridge domain must know the DR will not forward --> frames as --> --> >>>--> it used to. --> --> >>>--> It seems Rbridge shall issue a Topology Change --> Notification --> --> >>>--> via sbridge --> --> >>>--> domain to flush MAC tables. Is a fast analysis, --> probably I --> --> >>>--> miss details. --> --> >>>--> --> --> >>>--> --> --> >>>--> >2. We have two separate bridged domains, each with --> --> their elected --> --> >>>--> >forwarder. Somebody connects the two bridged domains --> --> >>>--> together with a --> --> >>>--> >wire. This can cause a temporary loop until a single --> --> >>>--> elected forwarder --> --> >>>--> >is picked by the RBridges. --> --> >>>--> > --> --> >>>--> > --> --> >>>--> > --> --> >>>--> In this case the PARTICIPATE PER PORT seems superior, as --> --> >>>--> the two merged --> --> >>>--> bridged domains will merge their spanning trees into one --> --> >>>--> and both DRs --> --> >>>--> will compete to be the root of the merged tree, this --> --> mechanism will --> --> >>>--> likely be faster (via RSTP fast transit to --> forwarding state --> --> >>>--> over the --> --> >>>--> bridged domain) than Designation to select the --> unique DR. --> --> >>>--> In other --> --> >>>--> words , the mechanism of root election in --> sbridge could be --> --> >>>--> used to help --> --> >>>--> in DR designation and/or viceversa. --> --> >>>--> So I see in PARTICIPATE PER PORT, some coupling --> between DR --> --> >>>--> status and --> --> >>>--> root status of sbridge domain that can be used --> --> >>>--> to speed up convergence and coherence of both --> domains. It --> --> >>>--> seems that --> --> >>>--> sbridge domains should be under the control of --> --> Rbridges, but the --> --> >>>--> sbridge mechanims should be used by Rbridges to keep --> --> the network --> --> >>>--> consistency and reconfiguration capabilities of RSTP. --> --> >>>--> Guillermo --> --> >>>--> --> --> >>>--> --> --> >>>--> _______________________________________________ --> --> >>>--> 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 --> --> > --> --> > --> --> > --> --> _______________________________________________ --> --> 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 j9LAcmL06178 for <rbridge@postel.org>; Fri, 21 Oct 2005 03:38:49 -0700 (PDT) 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 j9LAchp1027357; Fri, 21 Oct 2005 06:38:43 -0400 (EDT) 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 GAA15159; Fri, 21 Oct 2005 06:38:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX5TCB>; Fri, 21 Oct 2005 07:38:41 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FD0@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org>, Radia.Perlman@Sun.COM Date: Fri, 21 Oct 2005 07:38:41 -0300 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 j9LAcmL06178 Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 10:39:00 -0000 Status: RO Content-Length: 12715 Guillermo, Actually, the thing about a spanning tree is that frames entering the tree will reach every node. Hence the result of having an RBridge be something other than the root of the local spanning tree would be that frame delivery might be sub-optimal. In fact, it is not even necessary for the R-Bridge to be directly connected to the root of a local spanning tree. That's part of the reason why an RBridge does not need to be a part of the local STP. Given the way that spanning tree works in general, sub-optimal delivery of frames would not be something new. Having th -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Friday, October 21, 2005 2:33 AM --> To: Radia.Perlman@Sun.COM; Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> --> I see the standard root election mechanism of spanning tree --> islands as --> the fastest and simpler mechanism for DR Rbridge --> designation. I see the --> DR Rbridge as being necessarily the ROOT bridge of that --> sbridged cloud --> (or "link"). The root bridge of a standard spanning tree is the --> "natural" source and sink point for the spanning tree. To --> do so, the DR --> must issue BPDUs to become the root bridge. This is part of what I --> mentioned days ago as PARTICIPATE PER PORT, but may be we --> should call it --> SOURCE OR SINK (participate, do not forward BPDUs, only --> send own BPDUs --> to contend to be the root bridge of the link). --> The consequence of this DR election mechanism is that the priority --> configured at Rbridges as bridge ID would determine their --> also their --> election priority as DRs. I think this keep both domains --> coordinated --> with a single mechanism. --> Guillermo --> --> Radia Perlman wrote: --> --> >I don't believe there should be options here. --> >It should be plug and play. --> >RBridges should BLOCK bridge spanning tree messages, --> >and isolate the bridged islands. --> > --> >I absolutely do not understand what people are --> >worried about with BLOCK. --> > --> >I suggest someone that actually thinks there is --> >some reason to do anything other than drop --> >spanning tree messages start a thread with --> >a subject line --> >"why it is good for RBridges to forward BPDUs", --> >and very very carefully explain from scratch --> >what the reasoning is. Not with a long --> >email quoting pieces of other emails, but --> >with a carefully crafted, from scratch explanation --> >of what you perceive as a problem with BLOCk, and --> >what the perceived benefit of ever having --> >RBridges forwarding BPDUs would --> >be. --> > --> >Oh...and there was a much earlier thread of the --> >thread about other devices that might forward --> >or drop BPDUs. There have always been things we --> >referred to as "simple bridges" that forwarded spanning --> >tree messages. I was careful to ensure that the --> >spanning tree would work with such devices. Of course --> >the spanning tree would not prevent a loop of all --> >simple bridges, but if there was at least one spanning --> >tree bridge in the middle of every possible loop, then --> >there would wind up being no loops. --> > --> >You can think of "simple bridges" (ones that mindlessly --> >forward BPDUs) as a layer below bridges. They are --> >invisible to bridges. Bridges see a bunch of --> >segments connected by simple bridges as a single segment. --> >(Just like RBridges will see a bunch of segments connected --> >by bridges as a single segment). --> > --> >Devices that drop BDPUs work if they are really --> >layered on top of bridges, i.e., they let the --> >bridges do their own thing to create isolated --> >broadcast domains, and then these other devices do --> >their own thing to glue these islands together. --> >Like routers do. And like RBridges will do. --> > --> >Radia --> > --> > --> > --> >Guillermo Ib??ez wrote On 10/20/05 14:35,: --> > --> > --> >>Eric, --> >> --> >> --> >>Gray, Eric wrote: --> >> --> >> --> >> --> >> --> >>>Guillermo, --> >>> --> >>> During the discussion, the terms TRANSPARENT, PARTICIPATE --> >>>and BLOCK were used (often in upper-case, exactly as I have used --> >>>them here) as if these would ultimately be options that might be --> >>>supported - either as a complete set, or as some subset. --> >>> --> >>> For example, one argument was that TRANSPARENT or PARTICIPATE --> >>>might be used, but BLOCK should not. --> >>> --> >>> Also, at certain points in the discussion, there was some --> >>>thought that these might be modes that applied at --> different states --> >>>during transitions in a network. --> >>> --> >>> From a practical stand-point - however - it would be best if --> >>>we did not have to support all of these, either as options, or as --> >>>modes. The mere fact that they were brought up does not mean we --> >>>are committed to including them. --> >>> --> >>> --> >>> --> >>> --> >>> --> >>Agreed --> >> --> >> --> >> --> >> --> >>> In particular, if we start talking about - for instance - --> >>>having a per-interface option for all of these choices (and maybe --> >>>others as well), then we either need to analyze proposals for --> >>>architecture and design to ensure that the "right things" will --> >>>happen when an arbitrary combination of all of these --> options is in --> >>>effect, or we need to define caveats for network --> operators to avoid --> >>>specific combinations of options. For example, we may --> need to say --> >>>that the same option must be set throughout the network --> or this and --> >>>that will (or may) happen. That kind of design begs --> configuration --> >>>errors to occur. --> >>> --> >>> --> >>> --> >>> --> >>> --> >>If you refer as configuration options per interface to --> the PARTICIPATE --> >>PER PORT mode as an option per port, it is not the case. --> If you refer --> >>to being the DR the root bridge of the sbridge domain, I --> think it must --> >>be analyzed as a real alternative, even if it is not the default --> >>configuration. --> >> --> >> --> >> --> >> --> >>> In this case, the fact that we want to make the solution plug --> >>>and play means that we can reduce the potential for --> disaster if we --> >>>choose (and require) a specific default set of option --> choices. If --> >>>we can get away with it, however, we should simply avoid options. --> >>> --> >>> --> >>> --> >>> --> >>> --> >>Agreed, but not for the root bridge problem because is a --> real, practical --> >>issue. --> >> --> >> --> >> --> >> --> >>> While having these same values as modes that apply during --> >>>certain transitional states is cleaner, it would require a well- --> >>>defined finite state-machine (not a particular problem) and a --> >>>genuine need for these behaviors under certain circumstances. It --> >>>may well be the case that this turns out to be true. --> >>> --> >>> --> >>> --> >>> --> >>> --> >>RSTP port state machines are there, may be they should be --> taken into --> >>consideration to make a consistent and integrated, but --> not interwoven, --> >>design for Rbridges that work with RSTP trees. --> >>Guillermo. --> >> --> >> --> >> --> >> --> >>>-- --> >>>Eric --> >>> --> >>>--> -----Original Message----- --> >>>--> From: rbridge-bounces@postel.org --> >>>--> [mailto:rbridge-bounces@postel.org]On --> >>>--> Behalf Of Guillermo Ib??ez --> >>>--> Sent: Thursday, October 20, 2005 4:19 PM --> >>>--> To: Developing a hybrid router/bridge. --> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction --> >>>--> --> >>>--> --> >>>--> I volunteer for some work on the capture, although my --> >>>--> english might be --> >>>--> not too understandable. From what date should the capture --> >>>--> to be done? --> >>>--> --> >>>--> Regarding PARTICIPATE PER PORT: --> >>>--> Although I do not have a clear position, and it --> requires detailed --> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is --> >>>--> better integrated --> >>>--> with spanning tree, while maintaining the basic decoupling --> >>>--> that BLOCK --> >>>--> provides. --> >>>--> With PARTICIPATE PER PORT it would be possible to --> force the elected --> >>>--> Rbridge to become the sbridge root of the bridged domain by --> >>>--> modifying --> >>>--> its bridge priority when it gets elected as Designated by --> >>>--> IS-IS (this --> >>>--> could be an optimization). In this way the path length is --> >>>--> minimum from --> >>>--> all bridges of bridged domain to the DR. --> >>>--> --> >>>--> --> >>>--> Erik Nordmark wrote: --> >>>--> --> >>>--> >We've had some useful discussion on this mailing list. --> >>>--> >It would be good if somebody can capture the results --> >>>--> (perhaps as a long --> >>>--> >email) that we can fold into the draft(s) later. --> Any volunteers? --> >>>--> > --> >>>--> >I don't know if we will have additional issues in this --> >>>--> space or that it --> >>>--> >otherwise makes sense devoting agenda time to it in --> Vancouver. --> >>>--> > --> >>>--> >For instance, while I'm convinced that BLOCK works, I --> >>>--> wonder if there is --> >>>--> >something in PARTICIPATE PER PORT that can make the --> >>>--> interaction work better. --> >>>--> > --> >>>--> >Two cases to consider: --> >>>--> >1. The elected forwarder dies and a new one gets elected. --> >>>--> How quickly --> >>>--> >can packets sent by stations in the bridged cloud fail --> >>>--> over to go to the --> >>>--> >new elected forwarder? --> >>>--> > --> >>>--> > --> >>>--> > --> >>>--> My understanding is that if the forwarded dies, the --> sbridge domain --> >>>--> should handle it as a topology change --> notification, tables of --> >>>--> sbridges should be flushed according to the spanning tree --> >>>--> rules, so the --> >>>--> sbridge domain must know the DR will not forward frames as --> >>>--> it used to. --> >>>--> It seems Rbridge shall issue a Topology Change Notification --> >>>--> via sbridge --> >>>--> domain to flush MAC tables. Is a fast analysis, probably I --> >>>--> miss details. --> >>>--> --> >>>--> --> >>>--> >2. We have two separate bridged domains, each with --> their elected --> >>>--> >forwarder. Somebody connects the two bridged domains --> >>>--> together with a --> >>>--> >wire. This can cause a temporary loop until a single --> >>>--> elected forwarder --> >>>--> >is picked by the RBridges. --> >>>--> > --> >>>--> > --> >>>--> > --> >>>--> In this case the PARTICIPATE PER PORT seems superior, as --> >>>--> the two merged --> >>>--> bridged domains will merge their spanning trees into one --> >>>--> and both DRs --> >>>--> will compete to be the root of the merged tree, this --> mechanism will --> >>>--> likely be faster (via RSTP fast transit to forwarding state --> >>>--> over the --> >>>--> bridged domain) than Designation to select the unique DR. --> >>>--> In other --> >>>--> words , the mechanism of root election in sbridge could be --> >>>--> used to help --> >>>--> in DR designation and/or viceversa. --> >>>--> So I see in PARTICIPATE PER PORT, some coupling between DR --> >>>--> status and --> >>>--> root status of sbridge domain that can be used --> >>>--> to speed up convergence and coherence of both domains. It --> >>>--> seems that --> >>>--> sbridge domains should be under the control of --> Rbridges, but the --> >>>--> sbridge mechanims should be used by Rbridges to keep --> the network --> >>>--> consistency and reconfiguration capabilities of RSTP. --> >>>--> Guillermo --> >>>--> --> >>>--> --> >>>--> _______________________________________________ --> >>>--> 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 --> > --> > --> > --> _______________________________________________ --> 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 j9L7TYL18746 for <rbridge@postel.org>; Fri, 21 Oct 2005 00:29:34 -0700 (PDT) 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 <0IOP002F98T2JN00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 00:29:26 -0700 (PDT) Received: from sun.com ([129.150.24.220]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOP002F88T2TW10@mail.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 00:29:26 -0700 (PDT) Date: Fri, 21 Oct 2005 00:29:33 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9EA1839@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435898DD.70603@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: <A0A653F4CB702442BFBF2FAF02C031E9EA1839@xmb-sjc-21e.amer.cisco.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] FW: Time to summarize "forward or block" BPDU thread 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, 21 Oct 2005 07:30:30 -0000 Status: RO Content-Length: 13036 If you have to beat a horse, it's more humane to beat a dead one. Yes...the whole idea of a tree is that each RBridge knows, for each port, which ports are "in" or "out" of that particular spanning tree. If a port is "in" then you receive and forward multicasts onto that port. If it's "out" then you neither receive multicasts or send multicasts on that port. And I can't resist pointing out interesting technical tidbits...with the bridge spanning tree, the packets go on all the links, even if no other bridges will be picking up the packet. Whereas with RBridges, if the link-state-computed tree indicates no downstream receivers, then the packet is not sent onto that port. Radia Larry Kreeger (kreeger) wrote: >Radia, > >Sorry if I'm beating a dead horse. It sounds like RB2 would receive the >frame sent by RB1 to the "all RBridges" Ethernet DA, but would then know >to drop it. So, it sounds like RBridges will need some mechanisms to >"block" ports on the "ingress spanning tree" of each RBridge sourcing >broadcasts and multicasts - in other words for every RBridge in the >network. > > - Larry > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Radia Perlman >Sent: Thursday, October 20, 2005 11:07 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >thread > >In the picture, it's clear it would have to go encapsulated over the >bridged link. However, if that was just a subset of the topology, it >might be the case that there is some other path to RB3 and RB4. > >It is possible that the shortest path tree to RB2 would be over the >direct link, and the shortest path to RB3 and RB4 over the bridged link. > >In that case, RB1 would send it encapsulated over the bridged link, and >RB3 and RB4 would receive it, but RB2 would not, since that port of RB2 >is not in the "ingress RB1 spanning tree". > >Radia > > > >Larry Kreeger (kreeger) wrote On 10/20/05 08:46,: > > >> Radia, >> >>OK, after I replied and re-read your reply, I realized that you must >>have been answering a different question. That part made sense. >> >>I don't understand why it would be zero if the RBridge broadcast >>distribution tree from RB1 used the new link I added to between RB1 >>and RB2. It still needs to get to RB3 and RB4. In this case, does >>the frame get multicast onto the Bridged link and discarded by RB2 due >> >> > > > >>to some type of RPF check, or is it multicast to a "RB3 and RB4" >>address, or does it get unicast twice to RB3 and RB4 respectively? >>I'm just trying to understand how many times the same frame goes >>across the Bridged network. It seems like a minimum of once (just >>from A) if the RB's have less cost path reachability than the Bridged >>network, or up to >>3 in the example I just gave. >> >>It seems like a good model for these links may be to model them as a >>single access link (iff a RB is the DR for the link) plus a tunnel >>link to every other RB on the link. >> >>Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel >>links across any size of Bridged network, which would be sub-optimal. >>Manual configuration would be needed to raise the link cost so that >>the RBridges would prefer links that were actually links, and not >>Bridged networks. If they peaked into the BPDUs, they could probably >>figure this out themselves. >> >> - Larry >> >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>On Behalf Of Radia Perlman >>Sent: Wednesday, October 19, 2005 9:10 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>thread >> >>When I say "it is sent twice", I mean that the first time it is sent >>by A, natively. RB1 does not send it natively, just encapsulated. So >>perhaps I misparsed your question. I was answering "how many times >>does the packet get sent on that link" and from this question I guess >>you were asking "how many times does RB1 transmit the packet on the >> >> >link." > > >>The answer to THAT question is "once", and it will be encapsulated. >> >>Though with you extra link that you added now, it might be zero, >>depending on whether the spanning tree the RBridges calculated from >>the link state database, for ingress RBridge RB1, includes that link >> >> >or not. > > >>So, for your first question: >> >> >> >> >>>Why does RB1 send it onto the Bridged link with a "native" DA >>> >>> >>Broadcast? >> >> >> >>>If, as you said, F will receive the frame directly from A, then >>>wouldn't this cause F to get two copies? >>> >>> >>> >>No. RB1 does not send the packet natively. If it did, then F will >>receive two copies. But it doesn't. This misunderstanding is that I >>was answering a different question than you were asking, apparently. >> >> >>For your second question: >> >> >> >> >>>Now, the broadcast distribution tree may be (and would probably be >>>better) calculated to use the direct link between RB1--RB2 instead of >>>through the Bridged network. Unfortunately, RB1 probably cannot tell >>>the difference between a direct connection and a Bridged network >>>connection, but let's say it chooses this link. Now, wouldn't RB2 get >>> >>> >> >> >>>two copies of the broadcast...or is there more to this - such as some >>>kind of RPF check that is needed. >>> >>> >>The RBridges use the link state database to calculate a tree of >>shortest paths from RB1. So packets only arrive once. >> >>Radia >> >> >> >> >>Larry Kreeger (kreeger) wrote On 10/19/05 17:53,: >> >> >> >>>Radia, >>> >>>Why does RB1 send it onto the Bridged link with a "native" DA >>> >>> >>Broadcast? >> >> >> >>>If, as you said, F will receive the frame directly from A, then >>>wouldn't this cause F to get two copies? >>> >>>Also, I'm not sure if using an "all RBridges" DA would work if the >>>RBridges had other connectivity. For example, if I add a link in the >>>topology between RB1 and RB2, >>> >>> >>> B C D E >>> | | | | >>>RB1--RB2 RB3 RB4 >>> | | | | >>>--------------------- >>> | | >>> F A >>> >>>Now, the broadcast distribution tree may be (and would probably be >>>better) calculated to use the direct link between RB1--RB2 instead of >>>through the Bridged network. Unfortunately, RB1 probably cannot tell >>>the difference between a direct connection and a Bridged network >>>connection, but let's say it chooses this link. Now, wouldn't RB2 get >>> >>> >> >> >>>two copies of the broadcast...or is there more to this - such as some >>>kind of RPF check that is needed. >>> >>>- Larry >>> >>>-----Original Message----- >>>From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] >>>Sent: Wednesday, October 19, 2005 4:24 PM >>>To: Larry Kreeger (kreeger) >>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>thread >>> >>>It is sent twice. >>>The first time it is "native", with DA=broadcast >>> >>>The second time is encapsulated by RB1, so the packet has outer header >>> >>> >> >> >>>DA="all RBridges", a shim header with "ingress=RB1", and the inner >>>packet being exactly as transmitted by A. >>> >>>Onto other links though...RB1 will transmit it to B unencapsulated, >>>i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and >>>RB4 to E. >>> >>>And just a note...in case there were other endnodes on the bridged >>>link, the RBridges don't worry about it...those endnodes receive the >>>packet directly from A. >>> >>>So, for instance, F below will receive the packet when A transmitted >>> >>> >>it. >> >> >> >>> B C D E >>> | | | | >>>RB1 RB2 RB3 RB4 >>> | | | | >>>--------------------- >>> | | >>> F A >>> >>> >>> >>>Radia >>> >>> >>> >>> >>> >>>Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: >>> >>> >>> >>> >>>>Radia, >>>> >>>>In Step 6, is the frame sent onto the link between RB1 and B1 once or >>>>3 times? If once, what is the Ethernet DA? >>>> >>>>Thanks, Larry >>>> >>>>-----Original Message----- >>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>On Behalf Of Radia Perlman >>>>Sent: Wednesday, October 19, 2005 3:57 PM >>>>To: Developing a hybrid router/bridge. >>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>>thread >>>> >>>>Step 1: The bridges create a single broadcast domain, as seen by the >>>>RBridges. So the RBridges see the following picture: >>>> >>>>B C D E >>>>| | | | >>>>RB1 RB2 RB3 RB4 >>>>| | | | >>>>--------------------- >>>> | >>>> A >>>> >>>>Step 2: RB1 is elected DR, so it is the only one that will >>>>encapsulate >>>> >>>> >>> >>> >>>>or decapsulate to/from that link. >>>> >>>>Step 3: A transmits a broadcast or multicast packet >>>> >>>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since >>>>they are not allowed to process native (non-encapsulated) packets >>>> >>>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress >>>> >>>> >>>RB1" >>> >>> >>> >>> >>>>Step 6: RB1 forwards the encapsulated packet onto the link, with an >>>>outer header with a multicast address "all RBridges" >>>> >>>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it >>>>in order to send to their upward link (to C, D, and E, respectively). >>>> >>>>Step 8: (which could certainly happen after 5 or 6...doesn't have to >>>>be in order). RB1 decapsulates the packet and sends it to B. >>>> >>>>************ >>>>Hope that helps... >>>> >>>>Radia >>>> >>>> >>>> >>>> >>>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: >>>> >>>> >>>> >>>> >>>> >>>>>Radia, >>>>> >>>>>I think I now understand now that the DR election happens only >>>>>between >>>>> >>>>> >>>> >>>> >>>>>RBridges on a single shared link - and does not require usage of any >>>>> >>>>> > > > >>>>>RBridge topology information. It would help clarify the data flow >>>>>for >>>>> >>>>> >>>> >>>> >>>>>me (and hopefully others) if, given the network diagram below, you >>>>>could please give a step by step description of how a broadcast >>>>>frame >>>>> >>>>> >> >> >>>>>sent by host A gets through each Bridge and RBridge in this network >>>>>in >>>>> >>>>> >>>> >>>> >>>>>order to be received by hosts B,C,D,E if we assume that RB1 is the >>>>>Designated RBridge on the "link" created by the Bridged network >>>>>formed >>>>> >>>>> >>>> >>>> >>>>>by Bridges B1,B2,B3,B4. >>>>> >>>>>B C D E >>>>>| | | | >>>>>RB1 RB2 RB3 RB4 >>>>>| | | | >>>>>B1---B2---B3---B4 >>>>> | >>>>> A >>>>> >>>>>Thanks, Larry >>>>> >>>>>-----Original Message----- >>>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>>On Behalf Of Radia Perlman >>>>>Sent: Wednesday, October 19, 2005 9:57 AM >>>>>To: Developing a hybrid router/bridge. >>>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>>> >>>>> > > > >>>>>thread >>>>> >>>>>The IS-IS Hello protocol is for electing a single unique switch per >>>>>link. It doesn't matter which one it is. >>>>> >>>>>On the other hand, the spanning tree protocol is picking a special >>>>>single unique bridge per link...the one that is closest to the root. >>>>> >>>>>The spanning tree algorithm is choosing a tree of shortest paths >>>>>from >>>>> >>>>> >> >> >>>>>the root. >>>>> >>>>>IS-IS is not trying to do that. It is just electing one guy on a >>>>>link >>>>> >>>>> >> >> >>>>>to do special link-specific things. >>>>> >>>>>Radia >>>>>_______________________________________________ >>>>>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 >>_______________________________________________ >>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 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 j9L7PgL17802 for <rbridge@postel.org>; Fri, 21 Oct 2005 00:25:43 -0700 (PDT) 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 <0IOP002F78MNJN00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 00:25:35 -0700 (PDT) Received: from sun.com ([129.150.24.220]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOP002F68MKTW10@mail.sunlabs.com> for rbridge@postel.org; Fri, 21 Oct 2005 00:25:33 -0700 (PDT) Date: Fri, 21 Oct 2005 00:25:40 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <43588B9D.5050306@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435897F4.5030506@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> <435815C0.4030502@Sun.COM> <43588B9D.5050306@it.uc3m.es> 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] RBridge/bridge interaction 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, 21 Oct 2005 07:26:01 -0000 Status: RO Content-Length: 12230 I don't think there's any reason, even if most of the traffic on the link comes from the DR, for the DR to be the root of the spanning tree. What would be bad is if an RBridge, participating in two bridged islands, winds up merging the islands into a bigger island. The whole point is to make the bridged islands as small as possible, so most forwarding is done protected by hop count, and with optimal routes. I'll admit that having RBridges *initiate* BPDUs to vie for being Root is not as harmful as having them *forward* BPDUs between bridged islands (provided an RBridge is careful not to merge two islands that would have been separate if the RBridge had just been blocking BPDUs). We shouldn't make things more complex in an attempt to come up with a "more optimal" spanning tree within the bridged islands. With a bidirectional tree, as happens with bridges, there's nothing special about the Root. Also, the traffic pattern might be such that most of the traffic is between endnodes within the island. So there's really no reason to believe that having the RBridge DR be the spanning tree Root will result in better performance. And is certainly complicates things. And it also certainly is dangerous because of the potential of merging islands. Radia Guillermo Ib??ez wrote: >I see the standard root election mechanism of spanning tree islands as >the fastest and simpler mechanism for DR Rbridge designation. I see the >DR Rbridge as being necessarily the ROOT bridge of that sbridged cloud >(or "link"). The root bridge of a standard spanning tree is the >"natural" source and sink point for the spanning tree. To do so, the DR >must issue BPDUs to become the root bridge. This is part of what I >mentioned days ago as PARTICIPATE PER PORT, but may be we should call it >SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs >to contend to be the root bridge of the link). >The consequence of this DR election mechanism is that the priority >configured at Rbridges as bridge ID would determine their also their >election priority as DRs. I think this keep both domains coordinated >with a single mechanism. >Guillermo > >Radia Perlman wrote: > > > >>I don't believe there should be options here. >>It should be plug and play. >>RBridges should BLOCK bridge spanning tree messages, >>and isolate the bridged islands. >> >>I absolutely do not understand what people are >>worried about with BLOCK. >> >>I suggest someone that actually thinks there is >>some reason to do anything other than drop >>spanning tree messages start a thread with >>a subject line >>"why it is good for RBridges to forward BPDUs", >>and very very carefully explain from scratch >>what the reasoning is. Not with a long >>email quoting pieces of other emails, but >>with a carefully crafted, from scratch explanation >>of what you perceive as a problem with BLOCk, and >>what the perceived benefit of ever having >>RBridges forwarding BPDUs would >>be. >> >>Oh...and there was a much earlier thread of the >>thread about other devices that might forward >>or drop BPDUs. There have always been things we >>referred to as "simple bridges" that forwarded spanning >>tree messages. I was careful to ensure that the >>spanning tree would work with such devices. Of course >>the spanning tree would not prevent a loop of all >>simple bridges, but if there was at least one spanning >>tree bridge in the middle of every possible loop, then >>there would wind up being no loops. >> >>You can think of "simple bridges" (ones that mindlessly >>forward BPDUs) as a layer below bridges. They are >>invisible to bridges. Bridges see a bunch of >>segments connected by simple bridges as a single segment. >>(Just like RBridges will see a bunch of segments connected >>by bridges as a single segment). >> >>Devices that drop BDPUs work if they are really >>layered on top of bridges, i.e., they let the >>bridges do their own thing to create isolated >>broadcast domains, and then these other devices do >>their own thing to glue these islands together. >>Like routers do. And like RBridges will do. >> >>Radia >> >> >> >>Guillermo Ib??ez wrote On 10/20/05 14:35,: >> >> >> >> >>>Eric, >>> >>> >>>Gray, Eric wrote: >>> >>> >>> >>> >>> >>> >>>>Guillermo, >>>> >>>> During the discussion, the terms TRANSPARENT, PARTICIPATE >>>>and BLOCK were used (often in upper-case, exactly as I have used >>>>them here) as if these would ultimately be options that might be >>>>supported - either as a complete set, or as some subset. >>>> >>>> For example, one argument was that TRANSPARENT or PARTICIPATE >>>>might be used, but BLOCK should not. >>>> >>>> Also, at certain points in the discussion, there was some >>>>thought that these might be modes that applied at different states >>>>during transitions in a network. >>>> >>>> From a practical stand-point - however - it would be best if >>>>we did not have to support all of these, either as options, or as >>>>modes. The mere fact that they were brought up does not mean we >>>>are committed to including them. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Agreed >>> >>> >>> >>> >>> >>> >>>> In particular, if we start talking about - for instance - >>>>having a per-interface option for all of these choices (and maybe >>>>others as well), then we either need to analyze proposals for >>>>architecture and design to ensure that the "right things" will >>>>happen when an arbitrary combination of all of these options is in >>>>effect, or we need to define caveats for network operators to avoid >>>>specific combinations of options. For example, we may need to say >>>>that the same option must be set throughout the network or this and >>>>that will (or may) happen. That kind of design begs configuration >>>>errors to occur. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>If you refer as configuration options per interface to the PARTICIPATE >>>PER PORT mode as an option per port, it is not the case. If you refer >>>to being the DR the root bridge of the sbridge domain, I think it must >>>be analyzed as a real alternative, even if it is not the default >>>configuration. >>> >>> >>> >>> >>> >>> >>>> In this case, the fact that we want to make the solution plug >>>>and play means that we can reduce the potential for disaster if we >>>>choose (and require) a specific default set of option choices. If >>>>we can get away with it, however, we should simply avoid options. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Agreed, but not for the root bridge problem because is a real, practical >>>issue. >>> >>> >>> >>> >>> >>> >>>> While having these same values as modes that apply during >>>>certain transitional states is cleaner, it would require a well- >>>>defined finite state-machine (not a particular problem) and a >>>>genuine need for these behaviors under certain circumstances. It >>>>may well be the case that this turns out to be true. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>RSTP port state machines are there, may be they should be taken into >>>consideration to make a consistent and integrated, but not interwoven, >>>design for Rbridges that work with RSTP trees. >>>Guillermo. >>> >>> >>> >>> >>> >>> >>>>-- >>>>Eric >>>> >>>>--> -----Original Message----- >>>>--> From: rbridge-bounces@postel.org >>>>--> [mailto:rbridge-bounces@postel.org]On >>>>--> Behalf Of Guillermo Ib??ez >>>>--> Sent: Thursday, October 20, 2005 4:19 PM >>>>--> To: Developing a hybrid router/bridge. >>>>--> Subject: Re: [rbridge] RBridge/bridge interaction >>>>--> >>>>--> >>>>--> I volunteer for some work on the capture, although my >>>>--> english might be >>>>--> not too understandable. From what date should the capture >>>>--> to be done? >>>>--> >>>>--> Regarding PARTICIPATE PER PORT: >>>>--> Although I do not have a clear position, and it requires detailed >>>>--> analysis, it seems to me that PARTICIPATE PER PORT is >>>>--> better integrated >>>>--> with spanning tree, while maintaining the basic decoupling >>>>--> that BLOCK >>>>--> provides. >>>>--> With PARTICIPATE PER PORT it would be possible to force the elected >>>>--> Rbridge to become the sbridge root of the bridged domain by >>>>--> modifying >>>>--> its bridge priority when it gets elected as Designated by >>>>--> IS-IS (this >>>>--> could be an optimization). In this way the path length is >>>>--> minimum from >>>>--> all bridges of bridged domain to the DR. >>>>--> >>>>--> >>>>--> Erik Nordmark wrote: >>>>--> >>>>--> >We've had some useful discussion on this mailing list. >>>>--> >It would be good if somebody can capture the results >>>>--> (perhaps as a long >>>>--> >email) that we can fold into the draft(s) later. Any volunteers? >>>>--> > >>>>--> >I don't know if we will have additional issues in this >>>>--> space or that it >>>>--> >otherwise makes sense devoting agenda time to it in Vancouver. >>>>--> > >>>>--> >For instance, while I'm convinced that BLOCK works, I >>>>--> wonder if there is >>>>--> >something in PARTICIPATE PER PORT that can make the >>>>--> interaction work better. >>>>--> > >>>>--> >Two cases to consider: >>>>--> >1. The elected forwarder dies and a new one gets elected. >>>>--> How quickly >>>>--> >can packets sent by stations in the bridged cloud fail >>>>--> over to go to the >>>>--> >new elected forwarder? >>>>--> > >>>>--> > >>>>--> > >>>>--> My understanding is that if the forwarded dies, the sbridge domain >>>>--> should handle it as a topology change notification, tables of >>>>--> sbridges should be flushed according to the spanning tree >>>>--> rules, so the >>>>--> sbridge domain must know the DR will not forward frames as >>>>--> it used to. >>>>--> It seems Rbridge shall issue a Topology Change Notification >>>>--> via sbridge >>>>--> domain to flush MAC tables. Is a fast analysis, probably I >>>>--> miss details. >>>>--> >>>>--> >>>>--> >2. We have two separate bridged domains, each with their elected >>>>--> >forwarder. Somebody connects the two bridged domains >>>>--> together with a >>>>--> >wire. This can cause a temporary loop until a single >>>>--> elected forwarder >>>>--> >is picked by the RBridges. >>>>--> > >>>>--> > >>>>--> > >>>>--> In this case the PARTICIPATE PER PORT seems superior, as >>>>--> the two merged >>>>--> bridged domains will merge their spanning trees into one >>>>--> and both DRs >>>>--> will compete to be the root of the merged tree, this mechanism will >>>>--> likely be faster (via RSTP fast transit to forwarding state >>>>--> over the >>>>--> bridged domain) than Designation to select the unique DR. >>>>--> In other >>>>--> words , the mechanism of root election in sbridge could be >>>>--> used to help >>>>--> in DR designation and/or viceversa. >>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR >>>>--> status and >>>>--> root status of sbridge domain that can be used >>>>--> to speed up convergence and coherence of both domains. It >>>>--> seems that >>>>--> sbridge domains should be under the control of Rbridges, but the >>>>--> sbridge mechanims should be used by Rbridges to keep the network >>>>--> consistency and reconfiguration capabilities of RSTP. >>>>--> Guillermo >>>>--> >>>>--> >>>>--> _______________________________________________ >>>>--> 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 >> >> >> >> >> >_______________________________________________ >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 j9L6X7L06480 for <rbridge@postel.org>; Thu, 20 Oct 2005 23:33:08 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B21FD9D2C7; Fri, 21 Oct 2005 08:33:01 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id 38C7F9D293; Fri, 21 Oct 2005 08:33:00 +0200 (CEST) Message-ID: <43588B9D.5050306@it.uc3m.es> Date: Fri, 21 Oct 2005 08:33:01 +0200 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: Radia.Perlman@Sun.COM, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> <435815C0.4030502@Sun.COM> In-Reply-To: <435815C0.4030502@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] RBridge/bridge interaction 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, 21 Oct 2005 06:34:01 -0000 Status: RO Content-Length: 10301 I see the standard root election mechanism of spanning tree islands as the fastest and simpler mechanism for DR Rbridge designation. I see the DR Rbridge as being necessarily the ROOT bridge of that sbridged cloud (or "link"). The root bridge of a standard spanning tree is the "natural" source and sink point for the spanning tree. To do so, the DR must issue BPDUs to become the root bridge. This is part of what I mentioned days ago as PARTICIPATE PER PORT, but may be we should call it SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs to contend to be the root bridge of the link). The consequence of this DR election mechanism is that the priority configured at Rbridges as bridge ID would determine their also their election priority as DRs. I think this keep both domains coordinated with a single mechanism. Guillermo Radia Perlman wrote: >I don't believe there should be options here. >It should be plug and play. >RBridges should BLOCK bridge spanning tree messages, >and isolate the bridged islands. > >I absolutely do not understand what people are >worried about with BLOCK. > >I suggest someone that actually thinks there is >some reason to do anything other than drop >spanning tree messages start a thread with >a subject line >"why it is good for RBridges to forward BPDUs", >and very very carefully explain from scratch >what the reasoning is. Not with a long >email quoting pieces of other emails, but >with a carefully crafted, from scratch explanation >of what you perceive as a problem with BLOCk, and >what the perceived benefit of ever having >RBridges forwarding BPDUs would >be. > >Oh...and there was a much earlier thread of the >thread about other devices that might forward >or drop BPDUs. There have always been things we >referred to as "simple bridges" that forwarded spanning >tree messages. I was careful to ensure that the >spanning tree would work with such devices. Of course >the spanning tree would not prevent a loop of all >simple bridges, but if there was at least one spanning >tree bridge in the middle of every possible loop, then >there would wind up being no loops. > >You can think of "simple bridges" (ones that mindlessly >forward BPDUs) as a layer below bridges. They are >invisible to bridges. Bridges see a bunch of >segments connected by simple bridges as a single segment. >(Just like RBridges will see a bunch of segments connected >by bridges as a single segment). > >Devices that drop BDPUs work if they are really >layered on top of bridges, i.e., they let the >bridges do their own thing to create isolated >broadcast domains, and then these other devices do >their own thing to glue these islands together. >Like routers do. And like RBridges will do. > >Radia > > > >Guillermo Ib??ez wrote On 10/20/05 14:35,: > > >>Eric, >> >> >>Gray, Eric wrote: >> >> >> >> >>>Guillermo, >>> >>> During the discussion, the terms TRANSPARENT, PARTICIPATE >>>and BLOCK were used (often in upper-case, exactly as I have used >>>them here) as if these would ultimately be options that might be >>>supported - either as a complete set, or as some subset. >>> >>> For example, one argument was that TRANSPARENT or PARTICIPATE >>>might be used, but BLOCK should not. >>> >>> Also, at certain points in the discussion, there was some >>>thought that these might be modes that applied at different states >>>during transitions in a network. >>> >>> From a practical stand-point - however - it would be best if >>>we did not have to support all of these, either as options, or as >>>modes. The mere fact that they were brought up does not mean we >>>are committed to including them. >>> >>> >>> >>> >>> >>Agreed >> >> >> >> >>> In particular, if we start talking about - for instance - >>>having a per-interface option for all of these choices (and maybe >>>others as well), then we either need to analyze proposals for >>>architecture and design to ensure that the "right things" will >>>happen when an arbitrary combination of all of these options is in >>>effect, or we need to define caveats for network operators to avoid >>>specific combinations of options. For example, we may need to say >>>that the same option must be set throughout the network or this and >>>that will (or may) happen. That kind of design begs configuration >>>errors to occur. >>> >>> >>> >>> >>> >>If you refer as configuration options per interface to the PARTICIPATE >>PER PORT mode as an option per port, it is not the case. If you refer >>to being the DR the root bridge of the sbridge domain, I think it must >>be analyzed as a real alternative, even if it is not the default >>configuration. >> >> >> >> >>> In this case, the fact that we want to make the solution plug >>>and play means that we can reduce the potential for disaster if we >>>choose (and require) a specific default set of option choices. If >>>we can get away with it, however, we should simply avoid options. >>> >>> >>> >>> >>> >>Agreed, but not for the root bridge problem because is a real, practical >>issue. >> >> >> >> >>> While having these same values as modes that apply during >>>certain transitional states is cleaner, it would require a well- >>>defined finite state-machine (not a particular problem) and a >>>genuine need for these behaviors under certain circumstances. It >>>may well be the case that this turns out to be true. >>> >>> >>> >>> >>> >>RSTP port state machines are there, may be they should be taken into >>consideration to make a consistent and integrated, but not interwoven, >>design for Rbridges that work with RSTP trees. >>Guillermo. >> >> >> >> >>>-- >>>Eric >>> >>>--> -----Original Message----- >>>--> From: rbridge-bounces@postel.org >>>--> [mailto:rbridge-bounces@postel.org]On >>>--> Behalf Of Guillermo Ib??ez >>>--> Sent: Thursday, October 20, 2005 4:19 PM >>>--> To: Developing a hybrid router/bridge. >>>--> Subject: Re: [rbridge] RBridge/bridge interaction >>>--> >>>--> >>>--> I volunteer for some work on the capture, although my >>>--> english might be >>>--> not too understandable. From what date should the capture >>>--> to be done? >>>--> >>>--> Regarding PARTICIPATE PER PORT: >>>--> Although I do not have a clear position, and it requires detailed >>>--> analysis, it seems to me that PARTICIPATE PER PORT is >>>--> better integrated >>>--> with spanning tree, while maintaining the basic decoupling >>>--> that BLOCK >>>--> provides. >>>--> With PARTICIPATE PER PORT it would be possible to force the elected >>>--> Rbridge to become the sbridge root of the bridged domain by >>>--> modifying >>>--> its bridge priority when it gets elected as Designated by >>>--> IS-IS (this >>>--> could be an optimization). In this way the path length is >>>--> minimum from >>>--> all bridges of bridged domain to the DR. >>>--> >>>--> >>>--> Erik Nordmark wrote: >>>--> >>>--> >We've had some useful discussion on this mailing list. >>>--> >It would be good if somebody can capture the results >>>--> (perhaps as a long >>>--> >email) that we can fold into the draft(s) later. Any volunteers? >>>--> > >>>--> >I don't know if we will have additional issues in this >>>--> space or that it >>>--> >otherwise makes sense devoting agenda time to it in Vancouver. >>>--> > >>>--> >For instance, while I'm convinced that BLOCK works, I >>>--> wonder if there is >>>--> >something in PARTICIPATE PER PORT that can make the >>>--> interaction work better. >>>--> > >>>--> >Two cases to consider: >>>--> >1. The elected forwarder dies and a new one gets elected. >>>--> How quickly >>>--> >can packets sent by stations in the bridged cloud fail >>>--> over to go to the >>>--> >new elected forwarder? >>>--> > >>>--> > >>>--> > >>>--> My understanding is that if the forwarded dies, the sbridge domain >>>--> should handle it as a topology change notification, tables of >>>--> sbridges should be flushed according to the spanning tree >>>--> rules, so the >>>--> sbridge domain must know the DR will not forward frames as >>>--> it used to. >>>--> It seems Rbridge shall issue a Topology Change Notification >>>--> via sbridge >>>--> domain to flush MAC tables. Is a fast analysis, probably I >>>--> miss details. >>>--> >>>--> >>>--> >2. We have two separate bridged domains, each with their elected >>>--> >forwarder. Somebody connects the two bridged domains >>>--> together with a >>>--> >wire. This can cause a temporary loop until a single >>>--> elected forwarder >>>--> >is picked by the RBridges. >>>--> > >>>--> > >>>--> > >>>--> In this case the PARTICIPATE PER PORT seems superior, as >>>--> the two merged >>>--> bridged domains will merge their spanning trees into one >>>--> and both DRs >>>--> will compete to be the root of the merged tree, this mechanism will >>>--> likely be faster (via RSTP fast transit to forwarding state >>>--> over the >>>--> bridged domain) than Designation to select the unique DR. >>>--> In other >>>--> words , the mechanism of root election in sbridge could be >>>--> used to help >>>--> in DR designation and/or viceversa. >>>--> So I see in PARTICIPATE PER PORT, some coupling between DR >>>--> status and >>>--> root status of sbridge domain that can be used >>>--> to speed up convergence and coherence of both domains. It >>>--> seems that >>>--> sbridge domains should be under the control of Rbridges, but the >>>--> sbridge mechanims should be used by Rbridges to keep the network >>>--> consistency and reconfiguration capabilities of RSTP. >>>--> Guillermo >>>--> >>>--> >>>--> _______________________________________________ >>>--> 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 zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9L2jZL18824 for <rbridge@postel.org>; Thu, 20 Oct 2005 19:45:36 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9L2jSa17057 for <rbridge@postel.org>; Thu, 20 Oct 2005 22:45:28 -0400 (EDT) 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, 20 Oct 2005 22:45:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D52@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge/bridge interaction Thread-Index: AcXVukFc1XHBc5s/SL+MgvvROQqOCAALlePA From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9L2jZL18824 Subject: Re: [rbridge] RBridge/bridge interaction 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, 21 Oct 2005 02:45:58 -0000 Status: RO Content-Length: 466 > > During the discussion, the terms TRANSPARENT, PARTICIPATE > and BLOCK were used (often in upper-case, exactly as I have > used them here) as if these would ultimately be options that > might be supported - either as a complete set, or as some subset. I am guilty of introducing those terms but it was not with the intention that they be options but to give concrete terms to the different points of view that were being debated. Peter Ashwood-Smith Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9L0k6L22070 for <rbridge@postel.org>; Thu, 20 Oct 2005 17:46:06 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2005 17:46:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9L0jl9G020881; Thu, 20 Oct 2005 17:45:59 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 17:45:41 -0700 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, 20 Oct 2005 17:45:39 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D87A97922@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXVLaFSpPXXs4MVTsCmICDLbRYLSQAqZTtw From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: <Radia.Perlman@Sun.COM>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 21 Oct 2005 00:45:41.0004 (UTC) FILETIME=[C2EF44C0:01C5D5D8] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9L0k6L22070 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 21 Oct 2005 00:47:00 -0000 Status: RO Content-Length: 9203 Are multicasts also carried over edge rbridge's per-rbridge-spanning-tree ..? If so, assuming all entities (RBx, host A & F) are interested in a particular multicast group G1, what outer address is used (for the same topology discussed in this thread) for multicast originating from host A ..? As I understand multicasts also go on a per-rbridge-spanning-tree. What outer address would be used by RB1 such that RB3 & RB4 understand it's a TRILL encpasulated packet, and is a multicast, but at the same time, such a packet should be thrown away by host F. Also, if an IGMP packet seen by any designated rbridge, is sent as a broadcast to other rbridges, over that rbridge's spanning tree, then I don't think *traditional* IGMP snooping would work to form the {S,G} multicast state. (where S == source rbridge). -Sanjay >-----Original Message----- >From: rbridge-bounces@postel.org >[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >Sent: Wednesday, October 19, 2005 9:10 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] FW: Time to summarize "forward or >block" BPDU thread > >When I say "it is sent twice", I mean that the first time it >is sent by A, natively. RB1 does not send it natively, just >encapsulated. So perhaps I misparsed your question. I was >answering "how many times does the packet get sent on that >link" and from this question I guess you were asking "how many >times does RB1 transmit the packet on the link." > >The answer to THAT question is "once", and it will be encapsulated. > >Though with you extra link that you added now, it might be >zero, depending on whether the spanning tree the RBridges >calculated from the link state database, for ingress RBridge >RB1, includes that link or not. > >So, for your first question: > >> Why does RB1 send it onto the Bridged link with a "native" >DA Broadcast? >> If, as you said, F will receive the frame directly from A, then >> wouldn't this cause F to get two copies? >> > >No. RB1 does not send the packet natively. If it did, then F >will receive two copies. But it doesn't. This misunderstanding >is that I was answering a different question than you were >asking, apparently. > > >For your second question: > >> Now, the broadcast distribution tree may be (and would probably be >> better) calculated to use the direct link between RB1--RB2 >instead of >> through the Bridged network. Unfortunately, RB1 probably >cannot tell >> the difference between a direct connection and a Bridged network >> connection, but let's say it chooses this link. Now, >wouldn't RB2 get >> two copies of the broadcast...or is there more to this - >such as some >> kind of RPF check that is needed. > >The RBridges use the link state database to calculate a tree >of shortest paths from RB1. So packets only arrive once. > >Radia > > > > >Larry Kreeger (kreeger) wrote On 10/19/05 17:53,: >> Radia, >> >> Why does RB1 send it onto the Bridged link with a "native" >DA Broadcast? >> If, as you said, F will receive the frame directly from A, then >> wouldn't this cause F to get two copies? >> >> Also, I'm not sure if using an "all RBridges" DA would work if the >> RBridges had other connectivity. For example, if I add a >link in the >> topology between RB1 and RB2, >> >> >> B C D E >> | | | | >> RB1--RB2 RB3 RB4 >> | | | | >> --------------------- >> | | >> F A >> >> Now, the broadcast distribution tree may be (and would probably be >> better) calculated to use the direct link between RB1--RB2 >instead of >> through the Bridged network. Unfortunately, RB1 probably >cannot tell >> the difference between a direct connection and a Bridged network >> connection, but let's say it chooses this link. Now, >wouldn't RB2 get >> two copies of the broadcast...or is there more to this - >such as some >> kind of RPF check that is needed. >> >> - Larry >> >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] >> Sent: Wednesday, October 19, 2005 4:24 PM >> To: Larry Kreeger (kreeger) >> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >> thread >> >> It is sent twice. >> The first time it is "native", with DA=broadcast >> >> The second time is encapsulated by RB1, so the packet has >outer header >> DA="all RBridges", a shim header with "ingress=RB1", and the inner >> packet being exactly as transmitted by A. >> >> Onto other links though...RB1 will transmit it to B unencapsulated, >> i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and >> RB4 to E. >> >> And just a note...in case there were other endnodes on the bridged >> link, the RBridges don't worry about it...those endnodes receive the >> packet directly from A. >> >> So, for instance, F below will receive the packet when A >transmitted it. >> >> B C D E >> | | | | >> RB1 RB2 RB3 RB4 >> | | | | >> --------------------- >> | | >> F A >> >> >> >> Radia >> >> >> >> >> >> Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: >> >>>Radia, >>> >>>In Step 6, is the frame sent onto the link between RB1 and B1 once or >>>3 times? If once, what is the Ethernet DA? >>> >>>Thanks, Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Radia Perlman >>>Sent: Wednesday, October 19, 2005 3:57 PM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>thread >>> >>>Step 1: The bridges create a single broadcast domain, as seen by the >>>RBridges. So the RBridges see the following picture: >>> >>> B C D E >>> | | | | >>> RB1 RB2 RB3 RB4 >>> | | | | >>> --------------------- >>> | >>> A >>> >>>Step 2: RB1 is elected DR, so it is the only one that will >encapsulate >> >> >>>or decapsulate to/from that link. >>> >>>Step 3: A transmits a broadcast or multicast packet >>> >>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since >>>they are not allowed to process native (non-encapsulated) packets >>> >>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress >> >> RB1" >> >>>Step 6: RB1 forwards the encapsulated packet onto the link, with an >>>outer header with a multicast address "all RBridges" >>> >>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it >>>in order to send to their upward link (to C, D, and E, respectively). >>> >>>Step 8: (which could certainly happen after 5 or 6...doesn't have to >>>be in order). RB1 decapsulates the packet and sends it to B. >>> >>>************ >>>Hope that helps... >>> >>>Radia >>> >>> >>> >>> >>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: >>> >>> >>>>Radia, >>>> >>>>I think I now understand now that the DR election happens only >>>>between >>> >>> >>>>RBridges on a single shared link - and does not require >usage of any >>>>RBridge topology information. It would help clarify the data flow >>>>for >>> >>> >>>>me (and hopefully others) if, given the network diagram below, you >>>>could please give a step by step description of how a >broadcast frame >>>>sent by host A gets through each Bridge and RBridge in this network >>>>in >>> >>> >>>>order to be received by hosts B,C,D,E if we assume that RB1 is the >>>>Designated RBridge on the "link" created by the Bridged network >>>>formed >>> >>> >>>>by Bridges B1,B2,B3,B4. >>>> >>>> B C D E >>>> | | | | >>>>RB1 RB2 RB3 RB4 >>>> | | | | >>>> B1---B2---B3---B4 >>>> | >>>> A >>>> >>>>Thanks, Larry >>>> >>>>-----Original Message----- >>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>On Behalf Of Radia Perlman >>>>Sent: Wednesday, October 19, 2005 9:57 AM >>>>To: Developing a hybrid router/bridge. >>>>Subject: Re: [rbridge] FW: Time to summarize "forward or >block" BPDU >>>>thread >>>> >>>>The IS-IS Hello protocol is for electing a single unique switch per >>>>link. It doesn't matter which one it is. >>>> >>>>On the other hand, the spanning tree protocol is picking a special >>>>single unique bridge per link...the one that is closest to the root. >>>> >>>>The spanning tree algorithm is choosing a tree of shortest >paths from >>>>the root. >>>> >>>>IS-IS is not trying to do that. It is just electing one guy >on a link >>>>to do special link-specific things. >>>> >>>>Radia >>>>_______________________________________________ >>>>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 sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9L00eL06886 for <rbridge@postel.org>; Thu, 20 Oct 2005 17:00:40 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2005 17:00:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9L00QJl012546 for <rbridge@postel.org>; Thu, 20 Oct 2005 17:00:33 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 17:00:26 -0700 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, 20 Oct 2005 16:59:48 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9EA1839@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXVooZEjCDwGwCwTV+ADd0EzXuahAALf6Uw From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 21 Oct 2005 00:00:26.0492 (UTC) FILETIME=[70F59BC0:01C5D5D2] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9L00eL06886 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 21 Oct 2005 00:00:59 -0000 Status: RO Content-Length: 11330 Radia, Sorry if I'm beating a dead horse. It sounds like RB2 would receive the frame sent by RB1 to the "all RBridges" Ethernet DA, but would then know to drop it. So, it sounds like RBridges will need some mechanisms to "block" ports on the "ingress spanning tree" of each RBridge sourcing broadcasts and multicasts - in other words for every RBridge in the network. - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Thursday, October 20, 2005 11:07 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread In the picture, it's clear it would have to go encapsulated over the bridged link. However, if that was just a subset of the topology, it might be the case that there is some other path to RB3 and RB4. It is possible that the shortest path tree to RB2 would be over the direct link, and the shortest path to RB3 and RB4 over the bridged link. In that case, RB1 would send it encapsulated over the bridged link, and RB3 and RB4 would receive it, but RB2 would not, since that port of RB2 is not in the "ingress RB1 spanning tree". Radia Larry Kreeger (kreeger) wrote On 10/20/05 08:46,: > Radia, > > OK, after I replied and re-read your reply, I realized that you must > have been answering a different question. That part made sense. > > I don't understand why it would be zero if the RBridge broadcast > distribution tree from RB1 used the new link I added to between RB1 > and RB2. It still needs to get to RB3 and RB4. In this case, does > the frame get multicast onto the Bridged link and discarded by RB2 due > to some type of RPF check, or is it multicast to a "RB3 and RB4" > address, or does it get unicast twice to RB3 and RB4 respectively? > I'm just trying to understand how many times the same frame goes > across the Bridged network. It seems like a minimum of once (just > from A) if the RB's have less cost path reachability than the Bridged > network, or up to > 3 in the example I just gave. > > It seems like a good model for these links may be to model them as a > single access link (iff a RB is the DR for the link) plus a tunnel > link to every other RB on the link. > > Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel > links across any size of Bridged network, which would be sub-optimal. > Manual configuration would be needed to raise the link cost so that > the RBridges would prefer links that were actually links, and not > Bridged networks. If they peaked into the BPDUs, they could probably > figure this out themselves. > > - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Radia Perlman > Sent: Wednesday, October 19, 2005 9:10 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > When I say "it is sent twice", I mean that the first time it is sent > by A, natively. RB1 does not send it natively, just encapsulated. So > perhaps I misparsed your question. I was answering "how many times > does the packet get sent on that link" and from this question I guess > you were asking "how many times does RB1 transmit the packet on the link." > > The answer to THAT question is "once", and it will be encapsulated. > > Though with you extra link that you added now, it might be zero, > depending on whether the spanning tree the RBridges calculated from > the link state database, for ingress RBridge RB1, includes that link or not. > > So, for your first question: > > >>Why does RB1 send it onto the Bridged link with a "native" DA > > Broadcast? > >>If, as you said, F will receive the frame directly from A, then >>wouldn't this cause F to get two copies? >> > > > No. RB1 does not send the packet natively. If it did, then F will > receive two copies. But it doesn't. This misunderstanding is that I > was answering a different question than you were asking, apparently. > > > For your second question: > > >>Now, the broadcast distribution tree may be (and would probably be >>better) calculated to use the direct link between RB1--RB2 instead of >>through the Bridged network. Unfortunately, RB1 probably cannot tell >>the difference between a direct connection and a Bridged network >>connection, but let's say it chooses this link. Now, wouldn't RB2 get > > >>two copies of the broadcast...or is there more to this - such as some >>kind of RPF check that is needed. > > > The RBridges use the link state database to calculate a tree of > shortest paths from RB1. So packets only arrive once. > > Radia > > > > > Larry Kreeger (kreeger) wrote On 10/19/05 17:53,: > >>Radia, >> >>Why does RB1 send it onto the Bridged link with a "native" DA > > Broadcast? > >>If, as you said, F will receive the frame directly from A, then >>wouldn't this cause F to get two copies? >> >>Also, I'm not sure if using an "all RBridges" DA would work if the >>RBridges had other connectivity. For example, if I add a link in the >>topology between RB1 and RB2, >> >> >> B C D E >> | | | | >> RB1--RB2 RB3 RB4 >> | | | | >> --------------------- >> | | >> F A >> >>Now, the broadcast distribution tree may be (and would probably be >>better) calculated to use the direct link between RB1--RB2 instead of >>through the Bridged network. Unfortunately, RB1 probably cannot tell >>the difference between a direct connection and a Bridged network >>connection, but let's say it chooses this link. Now, wouldn't RB2 get > > >>two copies of the broadcast...or is there more to this - such as some >>kind of RPF check that is needed. >> >> - Larry >> >>-----Original Message----- >>From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] >>Sent: Wednesday, October 19, 2005 4:24 PM >>To: Larry Kreeger (kreeger) >>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>thread >> >>It is sent twice. >>The first time it is "native", with DA=broadcast >> >>The second time is encapsulated by RB1, so the packet has outer header > > >>DA="all RBridges", a shim header with "ingress=RB1", and the inner >>packet being exactly as transmitted by A. >> >>Onto other links though...RB1 will transmit it to B unencapsulated, >>i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and >>RB4 to E. >> >>And just a note...in case there were other endnodes on the bridged >>link, the RBridges don't worry about it...those endnodes receive the >>packet directly from A. >> >>So, for instance, F below will receive the packet when A transmitted > > it. > >> B C D E >> | | | | >> RB1 RB2 RB3 RB4 >> | | | | >> --------------------- >> | | >> F A >> >> >> >>Radia >> >> >> >> >> >>Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: >> >> >>>Radia, >>> >>>In Step 6, is the frame sent onto the link between RB1 and B1 once or >>>3 times? If once, what is the Ethernet DA? >>> >>>Thanks, Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Radia Perlman >>>Sent: Wednesday, October 19, 2005 3:57 PM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>thread >>> >>>Step 1: The bridges create a single broadcast domain, as seen by the >>>RBridges. So the RBridges see the following picture: >>> >>> B C D E >>> | | | | >>>RB1 RB2 RB3 RB4 >>> | | | | >>>--------------------- >>> | >>> A >>> >>>Step 2: RB1 is elected DR, so it is the only one that will >>>encapsulate >> >> >>>or decapsulate to/from that link. >>> >>>Step 3: A transmits a broadcast or multicast packet >>> >>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since >>>they are not allowed to process native (non-encapsulated) packets >>> >>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress >> >>RB1" >> >> >>>Step 6: RB1 forwards the encapsulated packet onto the link, with an >>>outer header with a multicast address "all RBridges" >>> >>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it >>>in order to send to their upward link (to C, D, and E, respectively). >>> >>>Step 8: (which could certainly happen after 5 or 6...doesn't have to >>>be in order). RB1 decapsulates the packet and sends it to B. >>> >>>************ >>>Hope that helps... >>> >>>Radia >>> >>> >>> >>> >>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: >>> >>> >>> >>>>Radia, >>>> >>>>I think I now understand now that the DR election happens only >>>>between >>> >>> >>>>RBridges on a single shared link - and does not require usage of any >>>>RBridge topology information. It would help clarify the data flow >>>>for >>> >>> >>>>me (and hopefully others) if, given the network diagram below, you >>>>could please give a step by step description of how a broadcast >>>>frame > > >>>>sent by host A gets through each Bridge and RBridge in this network >>>>in >>> >>> >>>>order to be received by hosts B,C,D,E if we assume that RB1 is the >>>>Designated RBridge on the "link" created by the Bridged network >>>>formed >>> >>> >>>>by Bridges B1,B2,B3,B4. >>>> >>>>B C D E >>>>| | | | >>>>RB1 RB2 RB3 RB4 >>>>| | | | >>>>B1---B2---B3---B4 >>>> | >>>> A >>>> >>>>Thanks, Larry >>>> >>>>-----Original Message----- >>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>On Behalf Of Radia Perlman >>>>Sent: Wednesday, October 19, 2005 9:57 AM >>>>To: Developing a hybrid router/bridge. >>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>>thread >>>> >>>>The IS-IS Hello protocol is for electing a single unique switch per >>>>link. It doesn't matter which one it is. >>>> >>>>On the other hand, the spanning tree protocol is picking a special >>>>single unique bridge per link...the one that is closest to the root. >>>> >>>>The spanning tree algorithm is choosing a tree of shortest paths >>>>from > > >>>>the root. >>>> >>>>IS-IS is not trying to do that. It is just electing one guy on a >>>>link > > >>>>to do special link-specific things. >>>> >>>>Radia >>>>_______________________________________________ >>>>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 > _______________________________________________ > 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 brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KMA9L01115 for <rbridge@postel.org>; Thu, 20 Oct 2005 15:10:09 -0700 (PDT) Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9KMA8k8013487 for <rbridge@postel.org>; Thu, 20 Oct 2005 16:10:09 -0600 (MDT) 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 <0IOO00D01ITDB3@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Thu, 20 Oct 2005 18:10:08 -0400 (EDT) Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IOO00476IWWDI@bur-mail2.east.sun.com> for rbridge@postel.org; Thu, 20 Oct 2005 18:10:08 -0400 (EDT) Date: Thu, 20 Oct 2005 15:10:08 -0700 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <43580D98.4070507@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435815C0.4030502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> <43580D98.4070507@it.uc3m.es> 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 j9KMA9L01115 Subject: Re: [rbridge] RBridge/bridge interaction 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: Thu, 20 Oct 2005 22:11:11 -0000 Status: RO Content-Length: 8935 I don't believe there should be options here. It should be plug and play. RBridges should BLOCK bridge spanning tree messages, and isolate the bridged islands. I absolutely do not understand what people are worried about with BLOCK. I suggest someone that actually thinks there is some reason to do anything other than drop spanning tree messages start a thread with a subject line "why it is good for RBridges to forward BPDUs", and very very carefully explain from scratch what the reasoning is. Not with a long email quoting pieces of other emails, but with a carefully crafted, from scratch explanation of what you perceive as a problem with BLOCk, and what the perceived benefit of ever having RBridges forwarding BPDUs would be. Oh...and there was a much earlier thread of the thread about other devices that might forward or drop BPDUs. There have always been things we referred to as "simple bridges" that forwarded spanning tree messages. I was careful to ensure that the spanning tree would work with such devices. Of course the spanning tree would not prevent a loop of all simple bridges, but if there was at least one spanning tree bridge in the middle of every possible loop, then there would wind up being no loops. You can think of "simple bridges" (ones that mindlessly forward BPDUs) as a layer below bridges. They are invisible to bridges. Bridges see a bunch of segments connected by simple bridges as a single segment. (Just like RBridges will see a bunch of segments connected by bridges as a single segment). Devices that drop BDPUs work if they are really layered on top of bridges, i.e., they let the bridges do their own thing to create isolated broadcast domains, and then these other devices do their own thing to glue these islands together. Like routers do. And like RBridges will do. Radia Guillermo Ib??ez wrote On 10/20/05 14:35,: > Eric, > > > Gray, Eric wrote: > > >>Guillermo, >> >> During the discussion, the terms TRANSPARENT, PARTICIPATE >>and BLOCK were used (often in upper-case, exactly as I have used >>them here) as if these would ultimately be options that might be >>supported - either as a complete set, or as some subset. >> >> For example, one argument was that TRANSPARENT or PARTICIPATE >>might be used, but BLOCK should not. >> >> Also, at certain points in the discussion, there was some >>thought that these might be modes that applied at different states >>during transitions in a network. >> >> From a practical stand-point - however - it would be best if >>we did not have to support all of these, either as options, or as >>modes. The mere fact that they were brought up does not mean we >>are committed to including them. >> >> >> > > Agreed > > >> In particular, if we start talking about - for instance - >>having a per-interface option for all of these choices (and maybe >>others as well), then we either need to analyze proposals for >>architecture and design to ensure that the "right things" will >>happen when an arbitrary combination of all of these options is in >>effect, or we need to define caveats for network operators to avoid >>specific combinations of options. For example, we may need to say >>that the same option must be set throughout the network or this and >>that will (or may) happen. That kind of design begs configuration >>errors to occur. >> >> >> > > If you refer as configuration options per interface to the PARTICIPATE > PER PORT mode as an option per port, it is not the case. If you refer > to being the DR the root bridge of the sbridge domain, I think it must > be analyzed as a real alternative, even if it is not the default > configuration. > > >> In this case, the fact that we want to make the solution plug >>and play means that we can reduce the potential for disaster if we >>choose (and require) a specific default set of option choices. If >>we can get away with it, however, we should simply avoid options. >> >> >> > > Agreed, but not for the root bridge problem because is a real, practical > issue. > > >> While having these same values as modes that apply during >>certain transitional states is cleaner, it would require a well- >>defined finite state-machine (not a particular problem) and a >>genuine need for these behaviors under certain circumstances. It >>may well be the case that this turns out to be true. >> >> >> > > RSTP port state machines are there, may be they should be taken into > consideration to make a consistent and integrated, but not interwoven, > design for Rbridges that work with RSTP trees. > Guillermo. > > >>-- >>Eric >> >>--> -----Original Message----- >>--> From: rbridge-bounces@postel.org >>--> [mailto:rbridge-bounces@postel.org]On >>--> Behalf Of Guillermo Ib??ez >>--> Sent: Thursday, October 20, 2005 4:19 PM >>--> To: Developing a hybrid router/bridge. >>--> Subject: Re: [rbridge] RBridge/bridge interaction >>--> >>--> >>--> I volunteer for some work on the capture, although my >>--> english might be >>--> not too understandable. From what date should the capture >>--> to be done? >>--> >>--> Regarding PARTICIPATE PER PORT: >>--> Although I do not have a clear position, and it requires detailed >>--> analysis, it seems to me that PARTICIPATE PER PORT is >>--> better integrated >>--> with spanning tree, while maintaining the basic decoupling >>--> that BLOCK >>--> provides. >>--> With PARTICIPATE PER PORT it would be possible to force the elected >>--> Rbridge to become the sbridge root of the bridged domain by >>--> modifying >>--> its bridge priority when it gets elected as Designated by >>--> IS-IS (this >>--> could be an optimization). In this way the path length is >>--> minimum from >>--> all bridges of bridged domain to the DR. >>--> >>--> >>--> Erik Nordmark wrote: >>--> >>--> >We've had some useful discussion on this mailing list. >>--> >It would be good if somebody can capture the results >>--> (perhaps as a long >>--> >email) that we can fold into the draft(s) later. Any volunteers? >>--> > >>--> >I don't know if we will have additional issues in this >>--> space or that it >>--> >otherwise makes sense devoting agenda time to it in Vancouver. >>--> > >>--> >For instance, while I'm convinced that BLOCK works, I >>--> wonder if there is >>--> >something in PARTICIPATE PER PORT that can make the >>--> interaction work better. >>--> > >>--> >Two cases to consider: >>--> >1. The elected forwarder dies and a new one gets elected. >>--> How quickly >>--> >can packets sent by stations in the bridged cloud fail >>--> over to go to the >>--> >new elected forwarder? >>--> > >>--> > >>--> > >>--> My understanding is that if the forwarded dies, the sbridge domain >>--> should handle it as a topology change notification, tables of >>--> sbridges should be flushed according to the spanning tree >>--> rules, so the >>--> sbridge domain must know the DR will not forward frames as >>--> it used to. >>--> It seems Rbridge shall issue a Topology Change Notification >>--> via sbridge >>--> domain to flush MAC tables. Is a fast analysis, probably I >>--> miss details. >>--> >>--> >>--> >2. We have two separate bridged domains, each with their elected >>--> >forwarder. Somebody connects the two bridged domains >>--> together with a >>--> >wire. This can cause a temporary loop until a single >>--> elected forwarder >>--> >is picked by the RBridges. >>--> > >>--> > >>--> > >>--> In this case the PARTICIPATE PER PORT seems superior, as >>--> the two merged >>--> bridged domains will merge their spanning trees into one >>--> and both DRs >>--> will compete to be the root of the merged tree, this mechanism will >>--> likely be faster (via RSTP fast transit to forwarding state >>--> over the >>--> bridged domain) than Designation to select the unique DR. >>--> In other >>--> words , the mechanism of root election in sbridge could be >>--> used to help >>--> in DR designation and/or viceversa. >>--> So I see in PARTICIPATE PER PORT, some coupling between DR >>--> status and >>--> root status of sbridge domain that can be used >>--> to speed up convergence and coherence of both domains. It >>--> seems that >>--> sbridge domains should be under the control of Rbridges, but the >>--> sbridge mechanims should be used by Rbridges to keep the network >>--> consistency and reconfiguration capabilities of RSTP. >>--> Guillermo >>--> >>--> >>--> _______________________________________________ >>--> 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 j9KLtjL25771 for <rbridge@postel.org>; Thu, 20 Oct 2005 14:55:45 -0700 (PDT) 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 j9KLtdp1020375; Thu, 20 Oct 2005 17:55:39 -0400 (EDT) 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 RAA21524; Thu, 20 Oct 2005 17:55:38 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX5F5R>; Thu, 20 Oct 2005 18:55:38 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FCC@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Thu, 20 Oct 2005 18:55:37 -0300 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: [rbridge] R-Bridge Routing Requirements draft is 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: Thu, 20 Oct 2005 21:55:57 -0000 Status: RO Content-Length: 497 The draft "Routing Requirements in Support of R-Bridges" - submitted last Friday - is now available at: http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.txt This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt and is very preliminary. I am looking for input for the various sections - particularly those that currently only contain "TBD" :-) This was one of the drafts that the working group felt would be required at the last meeting. -- Eric Gray 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 j9KLZSL18251 for <rbridge@postel.org>; Thu, 20 Oct 2005 14:35:28 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EF4899D38A for <rbridge@postel.org>; Thu, 20 Oct 2005 23:35:21 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id 24F389D3BC for <rbridge@postel.org>; Thu, 20 Oct 2005 23:35:19 +0200 (CEST) Message-ID: <43580D98.4070507@it.uc3m.es> Date: Thu, 20 Oct 2005 23:35:20 +0200 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: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.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] RBridge/bridge interaction 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, 20 Oct 2005 21:35:58 -0000 Status: RO Content-Length: 6687 Eric, Gray, Eric wrote: >Guillermo, > > During the discussion, the terms TRANSPARENT, PARTICIPATE >and BLOCK were used (often in upper-case, exactly as I have used >them here) as if these would ultimately be options that might be >supported - either as a complete set, or as some subset. > > For example, one argument was that TRANSPARENT or PARTICIPATE >might be used, but BLOCK should not. > > Also, at certain points in the discussion, there was some >thought that these might be modes that applied at different states >during transitions in a network. > > From a practical stand-point - however - it would be best if >we did not have to support all of these, either as options, or as >modes. The mere fact that they were brought up does not mean we >are committed to including them. > > > Agreed > In particular, if we start talking about - for instance - >having a per-interface option for all of these choices (and maybe >others as well), then we either need to analyze proposals for >architecture and design to ensure that the "right things" will >happen when an arbitrary combination of all of these options is in >effect, or we need to define caveats for network operators to avoid >specific combinations of options. For example, we may need to say >that the same option must be set throughout the network or this and >that will (or may) happen. That kind of design begs configuration >errors to occur. > > > If you refer as configuration options per interface to the PARTICIPATE PER PORT mode as an option per port, it is not the case. If you refer to being the DR the root bridge of the sbridge domain, I think it must be analyzed as a real alternative, even if it is not the default configuration. > In this case, the fact that we want to make the solution plug >and play means that we can reduce the potential for disaster if we >choose (and require) a specific default set of option choices. If >we can get away with it, however, we should simply avoid options. > > > Agreed, but not for the root bridge problem because is a real, practical issue. > While having these same values as modes that apply during >certain transitional states is cleaner, it would require a well- >defined finite state-machine (not a particular problem) and a >genuine need for these behaviors under certain circumstances. It >may well be the case that this turns out to be true. > > > RSTP port state machines are there, may be they should be taken into consideration to make a consistent and integrated, but not interwoven, design for Rbridges that work with RSTP trees. Guillermo. >-- >Eric > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Guillermo Ib??ez >--> Sent: Thursday, October 20, 2005 4:19 PM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] RBridge/bridge interaction >--> >--> >--> I volunteer for some work on the capture, although my >--> english might be >--> not too understandable. From what date should the capture >--> to be done? >--> >--> Regarding PARTICIPATE PER PORT: >--> Although I do not have a clear position, and it requires detailed >--> analysis, it seems to me that PARTICIPATE PER PORT is >--> better integrated >--> with spanning tree, while maintaining the basic decoupling >--> that BLOCK >--> provides. >--> With PARTICIPATE PER PORT it would be possible to force the elected >--> Rbridge to become the sbridge root of the bridged domain by >--> modifying >--> its bridge priority when it gets elected as Designated by >--> IS-IS (this >--> could be an optimization). In this way the path length is >--> minimum from >--> all bridges of bridged domain to the DR. >--> >--> >--> Erik Nordmark wrote: >--> >--> >We've had some useful discussion on this mailing list. >--> >It would be good if somebody can capture the results >--> (perhaps as a long >--> >email) that we can fold into the draft(s) later. Any volunteers? >--> > >--> >I don't know if we will have additional issues in this >--> space or that it >--> >otherwise makes sense devoting agenda time to it in Vancouver. >--> > >--> >For instance, while I'm convinced that BLOCK works, I >--> wonder if there is >--> >something in PARTICIPATE PER PORT that can make the >--> interaction work better. >--> > >--> >Two cases to consider: >--> >1. The elected forwarder dies and a new one gets elected. >--> How quickly >--> >can packets sent by stations in the bridged cloud fail >--> over to go to the >--> >new elected forwarder? >--> > >--> > >--> > >--> My understanding is that if the forwarded dies, the sbridge domain >--> should handle it as a topology change notification, tables of >--> sbridges should be flushed according to the spanning tree >--> rules, so the >--> sbridge domain must know the DR will not forward frames as >--> it used to. >--> It seems Rbridge shall issue a Topology Change Notification >--> via sbridge >--> domain to flush MAC tables. Is a fast analysis, probably I >--> miss details. >--> >--> >--> >2. We have two separate bridged domains, each with their elected >--> >forwarder. Somebody connects the two bridged domains >--> together with a >--> >wire. This can cause a temporary loop until a single >--> elected forwarder >--> >is picked by the RBridges. >--> > >--> > >--> > >--> In this case the PARTICIPATE PER PORT seems superior, as >--> the two merged >--> bridged domains will merge their spanning trees into one >--> and both DRs >--> will compete to be the root of the merged tree, this mechanism will >--> likely be faster (via RSTP fast transit to forwarding state >--> over the >--> bridged domain) than Designation to select the unique DR. >--> In other >--> words , the mechanism of root election in sbridge could be >--> used to help >--> in DR designation and/or viceversa. >--> So I see in PARTICIPATE PER PORT, some coupling between DR >--> status and >--> root status of sbridge domain that can be used >--> to speed up convergence and coherence of both domains. It >--> seems that >--> sbridge domains should be under the control of Rbridges, but the >--> sbridge mechanims should be used by Rbridges to keep the network >--> consistency and reconfiguration capabilities of RSTP. >--> Guillermo >--> >--> >--> _______________________________________________ >--> 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 j9KL8EL08872 for <rbridge@postel.org>; Thu, 20 Oct 2005 14:08:15 -0700 (PDT) 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 j9KL89p1019577; Thu, 20 Oct 2005 17:08:09 -0400 (EDT) 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 RAA16429; Thu, 20 Oct 2005 17:07:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX51NF>; Thu, 20 Oct 2005 18:07:53 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FC7@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Radia.Perlman@Sun.COM'" <Radia.Perlman@Sun.COM> Date: Thu, 20 Oct 2005 18:07:43 -0300 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 Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] RBridge/bridge interaction 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, 20 Oct 2005 21:08:58 -0000 Status: RO Content-Length: 5816 Radia, Does that mean you're looking for someone to volunteer to give that tutorial at the next IETF meeting? :-) -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Radia Perlman --> Sent: Thursday, October 20, 2005 4:43 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> Well, actually, I don't think he meant capturing the whole --> discussion. The problem is that no mortal can really follow --> a long discussion in email. It needs to be periodically summarized. --> Ideally, once someone does a summary of a thread, people can start --> with that note, and ignore all the previous ones. And if --> the summarizer --> missed anything, people can respond to the summary. --> --> So I do think it is useful to summarize again. Though if I were to --> write the summary, I'd say the same thing I did in the last summary, --> since I don't think there's anything too new technically. --> --> What I will volunteer to do is write a tutorial, going through --> cases like the topologies I was asked about, and exactly what --> happens in them, since I think that actually does help people --> visualize it. Having people ask questions is actually helpful, by --> the way, since sometimes it's hard to see what might confuse --> people unless people do ask questions. So thank you, people who --> have asked questions...it's really helpful. --> --> By the way, I will not be at the next IETF. --> --> Radia --> --> Gray, Eric wrote On 10/20/05 13:22,: --> > Peter/Erik, --> > --> > Perhaps it might be a good idea to summarize the discussion, --> > but I was under the impression that has been tried already in this --> > thread. If Peter wants to give it a try, that's fine with me. --> > --> > As for capturing the discussion, short of reproducing it, it --> > is unlikely that we would benefit from such an effort - especially --> > given that is what an E-Mail archive is for. --> > --> > I certainly hope we are not planning to include all of the --> > discussion in a draft - unless you are referring to the framework --> > or requirements draft. As commedable as the idea is to capture a --> > thought process so that we can avoid having to hash it out again, --> > a specification is not the place to do that. It can be extremely --> > difficult to parse a specification if it contains every --> crufty idea --> > that was considered in various brain-storming sessions. --> > --> > In the worst case, such a specification may imply a need to --> > implement all of those things and end up sinking implementations --> > from an excessive burden of options. --> > --> > -- --> > Eric --> > --> > --> -----Original Message----- --> > --> From: rbridge-bounces@postel.org --> > --> [mailto:rbridge-bounces@postel.org]On --> > --> Behalf Of Peter Ashwood-Smith --> > --> Sent: Thursday, October 20, 2005 11:39 AM --> > --> To: Developing a hybrid router/bridge. --> > --> Subject: Re: [rbridge] RBridge/bridge interaction --> > --> --> > --> --> > --> If nobody else wants to I'm happy to give it a whirl. --> > --> Any objections? or anybody else prefer to do it? --> > --> --> > --> Peter --> > --> --> > --> > -----Original Message----- --> > --> > From: rbridge-bounces@postel.org --> > --> > [mailto:rbridge-bounces@postel.org] On Behalf Of --> Erik Nordmark --> > --> > Sent: Thursday, October 20, 2005 10:24 AM --> > --> > To: Developing a hybrid router/bridge. --> > --> > Subject: [rbridge] RBridge/bridge interaction --> > --> > --> > --> > --> > --> > --> > --> > We've had some useful discussion on this mailing list. --> > --> > It would be good if somebody can capture the --> results (perhaps --> > --> > as a long --> > --> > email) that we can fold into the draft(s) later. --> Any volunteers? --> > --> > --> > --> > I don't know if we will have additional issues in --> this space --> > --> > or that it --> > --> > otherwise makes sense devoting agenda time to it in --> Vancouver. --> > --> > --> > --> > For instance, while I'm convinced that BLOCK works, --> I wonder --> > --> > if there is --> > --> > something in PARTICIPATE PER PORT that can make the --> > --> > interaction work better. --> > --> > --> > --> > Two cases to consider: --> > --> > 1. The elected forwarder dies and a new one gets elected. --> > --> How quickly --> > --> > can packets sent by stations in the bridged cloud fail over --> > --> > to go to the --> > --> > new elected forwarder? --> > --> > --> > --> > 2. We have two separate bridged domains, each with --> their elected --> > --> > forwarder. Somebody connects the two bridged domains --> > --> together with a --> > --> > wire. This can cause a temporary loop until a --> single elected --> > --> > forwarder --> > --> > is picked by the RBridges. --> > --> > --> > --> > Can some form of PARTICIPATE PER PORT scheme makes --> things work --> > --> > better/faster in those two cases? --> > --> > --> > --> > Erik --> > --> > --> > --> > _______________________________________________ --> > --> > 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 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 j9KL2wL07304 for <rbridge@postel.org>; Thu, 20 Oct 2005 14:02:58 -0700 (PDT) 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 j9KL2rp1019485 for <rbridge@postel.org>; Thu, 20 Oct 2005 17:02:53 -0400 (EDT) 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 RAA15996 for <rbridge@postel.org>; Thu, 20 Oct 2005 17:02:52 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX51J1>; Thu, 20 Oct 2005 18:02:52 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FC6@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Thu, 20 Oct 2005 18:02:47 -0300 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 j9KL2wL07304 Subject: Re: [rbridge] RBridge/bridge interaction 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, 20 Oct 2005 21:04:00 -0000 Status: RO Content-Length: 5750 Guillermo, During the discussion, the terms TRANSPARENT, PARTICIPATE and BLOCK were used (often in upper-case, exactly as I have used them here) as if these would ultimately be options that might be supported - either as a complete set, or as some subset. For example, one argument was that TRANSPARENT or PARTICIPATE might be used, but BLOCK should not. Also, at certain points in the discussion, there was some thought that these might be modes that applied at different states during transitions in a network. From a practical stand-point - however - it would be best if we did not have to support all of these, either as options, or as modes. The mere fact that they were brought up does not mean we are committed to including them. In particular, if we start talking about - for instance - having a per-interface option for all of these choices (and maybe others as well), then we either need to analyze proposals for architecture and design to ensure that the "right things" will happen when an arbitrary combination of all of these options is in effect, or we need to define caveats for network operators to avoid specific combinations of options. For example, we may need to say that the same option must be set throughout the network or this and that will (or may) happen. That kind of design begs configuration errors to occur. In this case, the fact that we want to make the solution plug and play means that we can reduce the potential for disaster if we choose (and require) a specific default set of option choices. If we can get away with it, however, we should simply avoid options. While having these same values as modes that apply during certain transitional states is cleaner, it would require a well- defined finite state-machine (not a particular problem) and a genuine need for these behaviors under certain circumstances. It may well be the case that this turns out to be true. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Guillermo Ib??ez --> Sent: Thursday, October 20, 2005 4:19 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> I volunteer for some work on the capture, although my --> english might be --> not too understandable. From what date should the capture --> to be done? --> --> Regarding PARTICIPATE PER PORT: --> Although I do not have a clear position, and it requires detailed --> analysis, it seems to me that PARTICIPATE PER PORT is --> better integrated --> with spanning tree, while maintaining the basic decoupling --> that BLOCK --> provides. --> With PARTICIPATE PER PORT it would be possible to force the elected --> Rbridge to become the sbridge root of the bridged domain by --> modifying --> its bridge priority when it gets elected as Designated by --> IS-IS (this --> could be an optimization). In this way the path length is --> minimum from --> all bridges of bridged domain to the DR. --> --> --> Erik Nordmark wrote: --> --> >We've had some useful discussion on this mailing list. --> >It would be good if somebody can capture the results --> (perhaps as a long --> >email) that we can fold into the draft(s) later. Any volunteers? --> > --> >I don't know if we will have additional issues in this --> space or that it --> >otherwise makes sense devoting agenda time to it in Vancouver. --> > --> >For instance, while I'm convinced that BLOCK works, I --> wonder if there is --> >something in PARTICIPATE PER PORT that can make the --> interaction work better. --> > --> >Two cases to consider: --> >1. The elected forwarder dies and a new one gets elected. --> How quickly --> >can packets sent by stations in the bridged cloud fail --> over to go to the --> >new elected forwarder? --> > --> > --> > --> My understanding is that if the forwarded dies, the sbridge domain --> should handle it as a topology change notification, tables of --> sbridges should be flushed according to the spanning tree --> rules, so the --> sbridge domain must know the DR will not forward frames as --> it used to. --> It seems Rbridge shall issue a Topology Change Notification --> via sbridge --> domain to flush MAC tables. Is a fast analysis, probably I --> miss details. --> --> --> >2. We have two separate bridged domains, each with their elected --> >forwarder. Somebody connects the two bridged domains --> together with a --> >wire. This can cause a temporary loop until a single --> elected forwarder --> >is picked by the RBridges. --> > --> > --> > --> In this case the PARTICIPATE PER PORT seems superior, as --> the two merged --> bridged domains will merge their spanning trees into one --> and both DRs --> will compete to be the root of the merged tree, this mechanism will --> likely be faster (via RSTP fast transit to forwarding state --> over the --> bridged domain) than Designation to select the unique DR. --> In other --> words , the mechanism of root election in sbridge could be --> used to help --> in DR designation and/or viceversa. --> So I see in PARTICIPATE PER PORT, some coupling between DR --> status and --> root status of sbridge domain that can be used --> to speed up convergence and coherence of both domains. It --> seems that --> sbridge domains should be under the control of Rbridges, but the --> sbridge mechanims should be used by Rbridges to keep the network --> consistency and reconfiguration capabilities of RSTP. --> Guillermo --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KKgoL01081 for <rbridge@postel.org>; Thu, 20 Oct 2005 13:42:50 -0700 (PDT) Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9KKgoeT022085 for <rbridge@postel.org>; Thu, 20 Oct 2005 14:42:50 -0600 (MDT) 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 <0IOO00301EUPWO@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Thu, 20 Oct 2005 16:42:50 -0400 (EDT) Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IOO000DZEVDR5@bur-mail2.east.sun.com> for rbridge@postel.org; Thu, 20 Oct 2005 16:42:50 -0400 (EDT) Date: Thu, 20 Oct 2005 13:42:49 -0700 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <313680C9A886D511A06000204840E1CF0C885FC5@whq-msgusr-02.pit.comms.marconi.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43580149.30602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <313680C9A886D511A06000204840E1CF0C885FC5@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] RBridge/bridge interaction 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: Thu, 20 Oct 2005 20:43:29 -0000 Status: RO Content-Length: 4702 Well, actually, I don't think he meant capturing the whole discussion. The problem is that no mortal can really follow a long discussion in email. It needs to be periodically summarized. Ideally, once someone does a summary of a thread, people can start with that note, and ignore all the previous ones. And if the summarizer missed anything, people can respond to the summary. So I do think it is useful to summarize again. Though if I were to write the summary, I'd say the same thing I did in the last summary, since I don't think there's anything too new technically. What I will volunteer to do is write a tutorial, going through cases like the topologies I was asked about, and exactly what happens in them, since I think that actually does help people visualize it. Having people ask questions is actually helpful, by the way, since sometimes it's hard to see what might confuse people unless people do ask questions. So thank you, people who have asked questions...it's really helpful. By the way, I will not be at the next IETF. Radia Gray, Eric wrote On 10/20/05 13:22,: > Peter/Erik, > > Perhaps it might be a good idea to summarize the discussion, > but I was under the impression that has been tried already in this > thread. If Peter wants to give it a try, that's fine with me. > > As for capturing the discussion, short of reproducing it, it > is unlikely that we would benefit from such an effort - especially > given that is what an E-Mail archive is for. > > I certainly hope we are not planning to include all of the > discussion in a draft - unless you are referring to the framework > or requirements draft. As commedable as the idea is to capture a > thought process so that we can avoid having to hash it out again, > a specification is not the place to do that. It can be extremely > difficult to parse a specification if it contains every crufty idea > that was considered in various brain-storming sessions. > > In the worst case, such a specification may imply a need to > implement all of those things and end up sinking implementations > from an excessive burden of options. > > -- > Eric > > --> -----Original Message----- > --> From: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org]On > --> Behalf Of Peter Ashwood-Smith > --> Sent: Thursday, October 20, 2005 11:39 AM > --> To: Developing a hybrid router/bridge. > --> Subject: Re: [rbridge] RBridge/bridge interaction > --> > --> > --> If nobody else wants to I'm happy to give it a whirl. > --> Any objections? or anybody else prefer to do it? > --> > --> Peter > --> > --> > -----Original Message----- > --> > From: rbridge-bounces@postel.org > --> > [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark > --> > Sent: Thursday, October 20, 2005 10:24 AM > --> > To: Developing a hybrid router/bridge. > --> > Subject: [rbridge] RBridge/bridge interaction > --> > > --> > > --> > > --> > We've had some useful discussion on this mailing list. > --> > It would be good if somebody can capture the results (perhaps > --> > as a long > --> > email) that we can fold into the draft(s) later. Any volunteers? > --> > > --> > I don't know if we will have additional issues in this space > --> > or that it > --> > otherwise makes sense devoting agenda time to it in Vancouver. > --> > > --> > For instance, while I'm convinced that BLOCK works, I wonder > --> > if there is > --> > something in PARTICIPATE PER PORT that can make the > --> > interaction work better. > --> > > --> > Two cases to consider: > --> > 1. The elected forwarder dies and a new one gets elected. > --> How quickly > --> > can packets sent by stations in the bridged cloud fail over > --> > to go to the > --> > new elected forwarder? > --> > > --> > 2. We have two separate bridged domains, each with their elected > --> > forwarder. Somebody connects the two bridged domains > --> together with a > --> > wire. This can cause a temporary loop until a single elected > --> > forwarder > --> > is picked by the RBridges. > --> > > --> > Can some form of PARTICIPATE PER PORT scheme makes things work > --> > better/faster in those two cases? > --> > > --> > Erik > --> > > --> > _______________________________________________ > --> > 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 j9KKN2L23813 for <rbridge@postel.org>; Thu, 20 Oct 2005 13:23:03 -0700 (PDT) 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 j9KKMrp1018628 for <rbridge@postel.org>; Thu, 20 Oct 2005 16:22:53 -0400 (EDT) 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 QAA10848 for <rbridge@postel.org>; Thu, 20 Oct 2005 16:22:52 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SX5C63>; Thu, 20 Oct 2005 17:22:52 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FC5@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Thu, 20 Oct 2005 17:22:50 -0300 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] RBridge/bridge interaction 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, 20 Oct 2005 20:23:58 -0000 Status: RO Content-Length: 3290 Peter/Erik, Perhaps it might be a good idea to summarize the discussion, but I was under the impression that has been tried already in this thread. If Peter wants to give it a try, that's fine with me. As for capturing the discussion, short of reproducing it, it is unlikely that we would benefit from such an effort - especially given that is what an E-Mail archive is for. I certainly hope we are not planning to include all of the discussion in a draft - unless you are referring to the framework or requirements draft. As commedable as the idea is to capture a thought process so that we can avoid having to hash it out again, a specification is not the place to do that. It can be extremely difficult to parse a specification if it contains every crufty idea that was considered in various brain-storming sessions. In the worst case, such a specification may imply a need to implement all of those things and end up sinking implementations from an excessive burden of options. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Peter Ashwood-Smith --> Sent: Thursday, October 20, 2005 11:39 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] RBridge/bridge interaction --> --> --> If nobody else wants to I'm happy to give it a whirl. --> Any objections? or anybody else prefer to do it? --> --> Peter --> --> > -----Original Message----- --> > From: rbridge-bounces@postel.org --> > [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark --> > Sent: Thursday, October 20, 2005 10:24 AM --> > To: Developing a hybrid router/bridge. --> > Subject: [rbridge] RBridge/bridge interaction --> > --> > --> > --> > We've had some useful discussion on this mailing list. --> > It would be good if somebody can capture the results (perhaps --> > as a long --> > email) that we can fold into the draft(s) later. Any volunteers? --> > --> > I don't know if we will have additional issues in this space --> > or that it --> > otherwise makes sense devoting agenda time to it in Vancouver. --> > --> > For instance, while I'm convinced that BLOCK works, I wonder --> > if there is --> > something in PARTICIPATE PER PORT that can make the --> > interaction work better. --> > --> > Two cases to consider: --> > 1. The elected forwarder dies and a new one gets elected. --> How quickly --> > can packets sent by stations in the bridged cloud fail over --> > to go to the --> > new elected forwarder? --> > --> > 2. We have two separate bridged domains, each with their elected --> > forwarder. Somebody connects the two bridged domains --> together with a --> > wire. This can cause a temporary loop until a single elected --> > forwarder --> > is picked by the RBridges. --> > --> > Can some form of PARTICIPATE PER PORT scheme makes things work --> > better/faster in those two cases? --> > --> > Erik --> > --> > _______________________________________________ --> > 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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KKJZL21848 for <rbridge@postel.org>; Thu, 20 Oct 2005 13:19:35 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 055109D268 for <rbridge@postel.org>; Thu, 20 Oct 2005 22:19:29 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id AB6509D30E for <rbridge@postel.org>; Thu, 20 Oct 2005 22:19:27 +0200 (CEST) Message-ID: <4357FBD1.1080307@it.uc3m.es> Date: Thu, 20 Oct 2005 22:19:29 +0200 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: <4357A866.2000100@sun.com> In-Reply-To: <4357A866.2000100@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] RBridge/bridge interaction 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, 20 Oct 2005 20:20:21 -0000 Status: RO Content-Length: 2971 I volunteer for some work on the capture, although my english might be not too understandable. From what date should the capture to be done? Regarding PARTICIPATE PER PORT: Although I do not have a clear position, and it requires detailed analysis, it seems to me that PARTICIPATE PER PORT is better integrated with spanning tree, while maintaining the basic decoupling that BLOCK provides. With PARTICIPATE PER PORT it would be possible to force the elected Rbridge to become the sbridge root of the bridged domain by modifying its bridge priority when it gets elected as Designated by IS-IS (this could be an optimization). In this way the path length is minimum from all bridges of bridged domain to the DR. Erik Nordmark wrote: >We've had some useful discussion on this mailing list. >It would be good if somebody can capture the results (perhaps as a long >email) that we can fold into the draft(s) later. Any volunteers? > >I don't know if we will have additional issues in this space or that it >otherwise makes sense devoting agenda time to it in Vancouver. > >For instance, while I'm convinced that BLOCK works, I wonder if there is >something in PARTICIPATE PER PORT that can make the interaction work better. > >Two cases to consider: >1. The elected forwarder dies and a new one gets elected. How quickly >can packets sent by stations in the bridged cloud fail over to go to the >new elected forwarder? > > > My understanding is that if the forwarded dies, the sbridge domain should handle it as a topology change notification, tables of sbridges should be flushed according to the spanning tree rules, so the sbridge domain must know the DR will not forward frames as it used to. It seems Rbridge shall issue a Topology Change Notification via sbridge domain to flush MAC tables. Is a fast analysis, probably I miss details. >2. We have two separate bridged domains, each with their elected >forwarder. Somebody connects the two bridged domains together with a >wire. This can cause a temporary loop until a single elected forwarder >is picked by the RBridges. > > > In this case the PARTICIPATE PER PORT seems superior, as the two merged bridged domains will merge their spanning trees into one and both DRs will compete to be the root of the merged tree, this mechanism will likely be faster (via RSTP fast transit to forwarding state over the bridged domain) than Designation to select the unique DR. In other words , the mechanism of root election in sbridge could be used to help in DR designation and/or viceversa. So I see in PARTICIPATE PER PORT, some coupling between DR status and root status of sbridge domain that can be used to speed up convergence and coherence of both domains. It seems that sbridge domains should be under the control of Rbridges, but the sbridge mechanims should be used by Rbridges to keep the network consistency and reconfiguration capabilities of RSTP. Guillermo Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KI6eL05032 for <rbridge@postel.org>; Thu, 20 Oct 2005 11:06:40 -0700 (PDT) Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9KI6dh0021756 for <rbridge@postel.org>; Thu, 20 Oct 2005 11:06:39 -0700 (PDT) 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 <0IOO000017JX2F@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Thu, 20 Oct 2005 14:06:39 -0400 (EDT) Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IOO00IKB7MZU9@bur-mail2.east.sun.com> for rbridge@postel.org; Thu, 20 Oct 2005 14:06:39 -0400 (EDT) Date: Thu, 20 Oct 2005 11:06:35 -0700 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9E3592B@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4357DCAB.8080705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <A0A653F4CB702442BFBF2FAF02C031E9E3592B@xmb-sjc-21e.amer.cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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: Thu, 20 Oct 2005 18:07:15 -0000 Status: RO Content-Length: 10485 In the picture, it's clear it would have to go encapsulated over the bridged link. However, if that was just a subset of the topology, it might be the case that there is some other path to RB3 and RB4. It is possible that the shortest path tree to RB2 would be over the direct link, and the shortest path to RB3 and RB4 over the bridged link. In that case, RB1 would send it encapsulated over the bridged link, and RB3 and RB4 would receive it, but RB2 would not, since that port of RB2 is not in the "ingress RB1 spanning tree". Radia Larry Kreeger (kreeger) wrote On 10/20/05 08:46,: > Radia, > > OK, after I replied and re-read your reply, I realized that you must > have been answering a different question. That part made sense. > > I don't understand why it would be zero if the RBridge broadcast > distribution tree from RB1 used the new link I added to between RB1 and > RB2. It still needs to get to RB3 and RB4. In this case, does the > frame get multicast onto the Bridged link and discarded by RB2 due to > some type of RPF check, or is it multicast to a "RB3 and RB4" address, > or does it get unicast twice to RB3 and RB4 respectively? I'm just > trying to understand how many times the same frame goes across the > Bridged network. It seems like a minimum of once (just from A) if the > RB's have less cost path reachability than the Bridged network, or up to > 3 in the example I just gave. > > It seems like a good model for these links may be to model them as a > single access link (iff a RB is the DR for the link) plus a tunnel link > to every other RB on the link. > > Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel > links across any size of Bridged network, which would be sub-optimal. > Manual configuration would be needed to raise the link cost so that the > RBridges would prefer links that were actually links, and not Bridged > networks. If they peaked into the BPDUs, they could probably figure > this out themselves. > > - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, October 19, 2005 9:10 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > When I say "it is sent twice", I mean that the first time it is sent by > A, natively. RB1 does not send it natively, just encapsulated. So > perhaps I misparsed your question. I was answering "how many times does > the packet get sent on that link" and from this question I guess you > were asking "how many times does RB1 transmit the packet on the link." > > The answer to THAT question is "once", and it will be encapsulated. > > Though with you extra link that you added now, it might be zero, > depending on whether the spanning tree the RBridges calculated from the > link state database, for ingress RBridge RB1, includes that link or not. > > So, for your first question: > > >>Why does RB1 send it onto the Bridged link with a "native" DA > > Broadcast? > >>If, as you said, F will receive the frame directly from A, then >>wouldn't this cause F to get two copies? >> > > > No. RB1 does not send the packet natively. If it did, then F will > receive two copies. But it doesn't. This misunderstanding is that I was > answering a different question than you were asking, apparently. > > > For your second question: > > >>Now, the broadcast distribution tree may be (and would probably be >>better) calculated to use the direct link between RB1--RB2 instead of >>through the Bridged network. Unfortunately, RB1 probably cannot tell >>the difference between a direct connection and a Bridged network >>connection, but let's say it chooses this link. Now, wouldn't RB2 get > > >>two copies of the broadcast...or is there more to this - such as some >>kind of RPF check that is needed. > > > The RBridges use the link state database to calculate a tree of shortest > paths from RB1. So packets only arrive once. > > Radia > > > > > Larry Kreeger (kreeger) wrote On 10/19/05 17:53,: > >>Radia, >> >>Why does RB1 send it onto the Bridged link with a "native" DA > > Broadcast? > >>If, as you said, F will receive the frame directly from A, then >>wouldn't this cause F to get two copies? >> >>Also, I'm not sure if using an "all RBridges" DA would work if the >>RBridges had other connectivity. For example, if I add a link in the >>topology between RB1 and RB2, >> >> >> B C D E >> | | | | >> RB1--RB2 RB3 RB4 >> | | | | >> --------------------- >> | | >> F A >> >>Now, the broadcast distribution tree may be (and would probably be >>better) calculated to use the direct link between RB1--RB2 instead of >>through the Bridged network. Unfortunately, RB1 probably cannot tell >>the difference between a direct connection and a Bridged network >>connection, but let's say it chooses this link. Now, wouldn't RB2 get > > >>two copies of the broadcast...or is there more to this - such as some >>kind of RPF check that is needed. >> >> - Larry >> >>-----Original Message----- >>From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] >>Sent: Wednesday, October 19, 2005 4:24 PM >>To: Larry Kreeger (kreeger) >>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>thread >> >>It is sent twice. >>The first time it is "native", with DA=broadcast >> >>The second time is encapsulated by RB1, so the packet has outer header > > >>DA="all RBridges", a shim header with "ingress=RB1", and the inner >>packet being exactly as transmitted by A. >> >>Onto other links though...RB1 will transmit it to B unencapsulated, >>i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and >>RB4 to E. >> >>And just a note...in case there were other endnodes on the bridged >>link, the RBridges don't worry about it...those endnodes receive the >>packet directly from A. >> >>So, for instance, F below will receive the packet when A transmitted > > it. > >> B C D E >> | | | | >> RB1 RB2 RB3 RB4 >> | | | | >> --------------------- >> | | >> F A >> >> >> >>Radia >> >> >> >> >> >>Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: >> >> >>>Radia, >>> >>>In Step 6, is the frame sent onto the link between RB1 and B1 once or >>>3 times? If once, what is the Ethernet DA? >>> >>>Thanks, Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Radia Perlman >>>Sent: Wednesday, October 19, 2005 3:57 PM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>thread >>> >>>Step 1: The bridges create a single broadcast domain, as seen by the >>>RBridges. So the RBridges see the following picture: >>> >>> B C D E >>> | | | | >>>RB1 RB2 RB3 RB4 >>> | | | | >>>--------------------- >>> | >>> A >>> >>>Step 2: RB1 is elected DR, so it is the only one that will encapsulate >> >> >>>or decapsulate to/from that link. >>> >>>Step 3: A transmits a broadcast or multicast packet >>> >>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since >>>they are not allowed to process native (non-encapsulated) packets >>> >>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress >> >>RB1" >> >> >>>Step 6: RB1 forwards the encapsulated packet onto the link, with an >>>outer header with a multicast address "all RBridges" >>> >>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it >>>in order to send to their upward link (to C, D, and E, respectively). >>> >>>Step 8: (which could certainly happen after 5 or 6...doesn't have to >>>be in order). RB1 decapsulates the packet and sends it to B. >>> >>>************ >>>Hope that helps... >>> >>>Radia >>> >>> >>> >>> >>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: >>> >>> >>> >>>>Radia, >>>> >>>>I think I now understand now that the DR election happens only >>>>between >>> >>> >>>>RBridges on a single shared link - and does not require usage of any >>>>RBridge topology information. It would help clarify the data flow >>>>for >>> >>> >>>>me (and hopefully others) if, given the network diagram below, you >>>>could please give a step by step description of how a broadcast frame > > >>>>sent by host A gets through each Bridge and RBridge in this network >>>>in >>> >>> >>>>order to be received by hosts B,C,D,E if we assume that RB1 is the >>>>Designated RBridge on the "link" created by the Bridged network >>>>formed >>> >>> >>>>by Bridges B1,B2,B3,B4. >>>> >>>>B C D E >>>>| | | | >>>>RB1 RB2 RB3 RB4 >>>>| | | | >>>>B1---B2---B3---B4 >>>> | >>>> A >>>> >>>>Thanks, Larry >>>> >>>>-----Original Message----- >>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>On Behalf Of Radia Perlman >>>>Sent: Wednesday, October 19, 2005 9:57 AM >>>>To: Developing a hybrid router/bridge. >>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>>thread >>>> >>>>The IS-IS Hello protocol is for electing a single unique switch per >>>>link. It doesn't matter which one it is. >>>> >>>>On the other hand, the spanning tree protocol is picking a special >>>>single unique bridge per link...the one that is closest to the root. >>>> >>>>The spanning tree algorithm is choosing a tree of shortest paths from > > >>>>the root. >>>> >>>>IS-IS is not trying to do that. It is just electing one guy on a link > > >>>>to do special link-specific things. >>>> >>>>Radia >>>>_______________________________________________ >>>>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 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KFkaL14906 for <rbridge@postel.org>; Thu, 20 Oct 2005 08:46:36 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2005 08:46:31 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="667900757:sNHT573263766" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KFkGJp006773 for <rbridge@postel.org>; Thu, 20 Oct 2005 08:46:29 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 08:46:28 -0700 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, 20 Oct 2005 08:46:19 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9E3592B@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXVLaF0cf6OUguaQyKLJ9/PnJImWAAXbLEg From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 20 Oct 2005 15:46:28.0043 (UTC) FILETIME=[6F1131B0:01C5D58D] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9KFkaL14906 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 20 Oct 2005 15:47:23 -0000 Status: RO Content-Length: 9414 Radia, OK, after I replied and re-read your reply, I realized that you must have been answering a different question. That part made sense. I don't understand why it would be zero if the RBridge broadcast distribution tree from RB1 used the new link I added to between RB1 and RB2. It still needs to get to RB3 and RB4. In this case, does the frame get multicast onto the Bridged link and discarded by RB2 due to some type of RPF check, or is it multicast to a "RB3 and RB4" address, or does it get unicast twice to RB3 and RB4 respectively? I'm just trying to understand how many times the same frame goes across the Bridged network. It seems like a minimum of once (just from A) if the RB's have less cost path reachability than the Bridged network, or up to 3 in the example I just gave. It seems like a good model for these links may be to model them as a single access link (iff a RB is the DR for the link) plus a tunnel link to every other RB on the link. Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel links across any size of Bridged network, which would be sub-optimal. Manual configuration would be needed to raise the link cost so that the RBridges would prefer links that were actually links, and not Bridged networks. If they peaked into the BPDUs, they could probably figure this out themselves. - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Wednesday, October 19, 2005 9:10 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread When I say "it is sent twice", I mean that the first time it is sent by A, natively. RB1 does not send it natively, just encapsulated. So perhaps I misparsed your question. I was answering "how many times does the packet get sent on that link" and from this question I guess you were asking "how many times does RB1 transmit the packet on the link." The answer to THAT question is "once", and it will be encapsulated. Though with you extra link that you added now, it might be zero, depending on whether the spanning tree the RBridges calculated from the link state database, for ingress RBridge RB1, includes that link or not. So, for your first question: > Why does RB1 send it onto the Bridged link with a "native" DA Broadcast? > If, as you said, F will receive the frame directly from A, then > wouldn't this cause F to get two copies? > No. RB1 does not send the packet natively. If it did, then F will receive two copies. But it doesn't. This misunderstanding is that I was answering a different question than you were asking, apparently. For your second question: > Now, the broadcast distribution tree may be (and would probably be > better) calculated to use the direct link between RB1--RB2 instead of > through the Bridged network. Unfortunately, RB1 probably cannot tell > the difference between a direct connection and a Bridged network > connection, but let's say it chooses this link. Now, wouldn't RB2 get > two copies of the broadcast...or is there more to this - such as some > kind of RPF check that is needed. The RBridges use the link state database to calculate a tree of shortest paths from RB1. So packets only arrive once. Radia Larry Kreeger (kreeger) wrote On 10/19/05 17:53,: > Radia, > > Why does RB1 send it onto the Bridged link with a "native" DA Broadcast? > If, as you said, F will receive the frame directly from A, then > wouldn't this cause F to get two copies? > > Also, I'm not sure if using an "all RBridges" DA would work if the > RBridges had other connectivity. For example, if I add a link in the > topology between RB1 and RB2, > > > B C D E > | | | | > RB1--RB2 RB3 RB4 > | | | | > --------------------- > | | > F A > > Now, the broadcast distribution tree may be (and would probably be > better) calculated to use the direct link between RB1--RB2 instead of > through the Bridged network. Unfortunately, RB1 probably cannot tell > the difference between a direct connection and a Bridged network > connection, but let's say it chooses this link. Now, wouldn't RB2 get > two copies of the broadcast...or is there more to this - such as some > kind of RPF check that is needed. > > - Larry > > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] > Sent: Wednesday, October 19, 2005 4:24 PM > To: Larry Kreeger (kreeger) > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > It is sent twice. > The first time it is "native", with DA=broadcast > > The second time is encapsulated by RB1, so the packet has outer header > DA="all RBridges", a shim header with "ingress=RB1", and the inner > packet being exactly as transmitted by A. > > Onto other links though...RB1 will transmit it to B unencapsulated, > i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and > RB4 to E. > > And just a note...in case there were other endnodes on the bridged > link, the RBridges don't worry about it...those endnodes receive the > packet directly from A. > > So, for instance, F below will receive the packet when A transmitted it. > > B C D E > | | | | > RB1 RB2 RB3 RB4 > | | | | > --------------------- > | | > F A > > > > Radia > > > > > > Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: > >>Radia, >> >>In Step 6, is the frame sent onto the link between RB1 and B1 once or >>3 times? If once, what is the Ethernet DA? >> >>Thanks, Larry >> >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>On Behalf Of Radia Perlman >>Sent: Wednesday, October 19, 2005 3:57 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>thread >> >>Step 1: The bridges create a single broadcast domain, as seen by the >>RBridges. So the RBridges see the following picture: >> >> B C D E >> | | | | >> RB1 RB2 RB3 RB4 >> | | | | >> --------------------- >> | >> A >> >>Step 2: RB1 is elected DR, so it is the only one that will encapsulate > > >>or decapsulate to/from that link. >> >>Step 3: A transmits a broadcast or multicast packet >> >>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since >>they are not allowed to process native (non-encapsulated) packets >> >>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress > > RB1" > >>Step 6: RB1 forwards the encapsulated packet onto the link, with an >>outer header with a multicast address "all RBridges" >> >>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it >>in order to send to their upward link (to C, D, and E, respectively). >> >>Step 8: (which could certainly happen after 5 or 6...doesn't have to >>be in order). RB1 decapsulates the packet and sends it to B. >> >>************ >>Hope that helps... >> >>Radia >> >> >> >> >>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: >> >> >>>Radia, >>> >>>I think I now understand now that the DR election happens only >>>between >> >> >>>RBridges on a single shared link - and does not require usage of any >>>RBridge topology information. It would help clarify the data flow >>>for >> >> >>>me (and hopefully others) if, given the network diagram below, you >>>could please give a step by step description of how a broadcast frame >>>sent by host A gets through each Bridge and RBridge in this network >>>in >> >> >>>order to be received by hosts B,C,D,E if we assume that RB1 is the >>>Designated RBridge on the "link" created by the Bridged network >>>formed >> >> >>>by Bridges B1,B2,B3,B4. >>> >>> B C D E >>> | | | | >>>RB1 RB2 RB3 RB4 >>> | | | | >>> B1---B2---B3---B4 >>> | >>> A >>> >>>Thanks, Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Radia Perlman >>>Sent: Wednesday, October 19, 2005 9:57 AM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>thread >>> >>>The IS-IS Hello protocol is for electing a single unique switch per >>>link. It doesn't matter which one it is. >>> >>>On the other hand, the spanning tree protocol is picking a special >>>single unique bridge per link...the one that is closest to the root. >>> >>>The spanning tree algorithm is choosing a tree of shortest paths from >>>the root. >>> >>>IS-IS is not trying to do that. It is just electing one guy on a link >>>to do special link-specific things. >>> >>>Radia >>>_______________________________________________ >>>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 zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KFdGL12150 for <rbridge@postel.org>; Thu, 20 Oct 2005 08:39:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9KFd6j27433 for <rbridge@postel.org>; Thu, 20 Oct 2005 11:39:06 -0400 (EDT) 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, 20 Oct 2005 11:39:06 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D4B@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge/bridge interaction Thread-Index: AcXVgncXcLcGxILaQ6SiAbpUk+WfIgACcWjA From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9KFdGL12150 Subject: Re: [rbridge] RBridge/bridge interaction 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, 20 Oct 2005 15:39:58 -0000 Status: RO Content-Length: 1618 If nobody else wants to I'm happy to give it a whirl. Any objections? or anybody else prefer to do it? Peter > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark > Sent: Thursday, October 20, 2005 10:24 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] RBridge/bridge interaction > > > > We've had some useful discussion on this mailing list. > It would be good if somebody can capture the results (perhaps > as a long > email) that we can fold into the draft(s) later. Any volunteers? > > I don't know if we will have additional issues in this space > or that it > otherwise makes sense devoting agenda time to it in Vancouver. > > For instance, while I'm convinced that BLOCK works, I wonder > if there is > something in PARTICIPATE PER PORT that can make the > interaction work better. > > Two cases to consider: > 1. The elected forwarder dies and a new one gets elected. How quickly > can packets sent by stations in the bridged cloud fail over > to go to the > new elected forwarder? > > 2. We have two separate bridged domains, each with their elected > forwarder. Somebody connects the two bridged domains together with a > wire. This can cause a temporary loop until a single elected > forwarder > is picked by the RBridges. > > Can some form of PARTICIPATE PER PORT scheme makes things work > better/faster in those two cases? > > Erik > > _______________________________________________ > 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 j9KENjL16594 for <rbridge@postel.org>; Thu, 20 Oct 2005 07:23:45 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9KENjZa021979 for <rbridge@postel.org>; Thu, 20 Oct 2005 07:23:45 -0700 (PDT) Received: from [129.157.211.182] (dhcp-gnb07-211-182.France.Sun.COM [129.157.211.182]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9KENcRa921688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Oct 2005 07:23:44 -0700 (PDT) Message-ID: <4357A866.2000100@sun.com> Date: Thu, 20 Oct 2005 07:23:34 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: [rbridge] RBridge/bridge interaction 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, 20 Oct 2005 14:23:52 -0000 Status: RO Content-Length: 1021 We've had some useful discussion on this mailing list. It would be good if somebody can capture the results (perhaps as a long email) that we can fold into the draft(s) later. Any volunteers? I don't know if we will have additional issues in this space or that it otherwise makes sense devoting agenda time to it in Vancouver. For instance, while I'm convinced that BLOCK works, I wonder if there is something in PARTICIPATE PER PORT that can make the interaction work better. Two cases to consider: 1. The elected forwarder dies and a new one gets elected. How quickly can packets sent by stations in the bridged cloud fail over to go to the new elected forwarder? 2. We have two separate bridged domains, each with their elected forwarder. Somebody connects the two bridged domains together with a wire. This can cause a temporary loop until a single elected forwarder is picked by the RBridges. Can some form of PARTICIPATE PER PORT scheme makes things work better/faster in those two cases? Erik 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 j9K49qL07549 for <rbridge@postel.org>; Wed, 19 Oct 2005 21:09:52 -0700 (PDT) Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9K49pZa002867 for <rbridge@postel.org>; Wed, 19 Oct 2005 21:09:51 -0700 (PDT) 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 <0ION00001405TV@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Thu, 20 Oct 2005 00:09:51 -0400 (EDT) Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ION00E7H4WELI@bur-mail2.east.sun.com> for rbridge@postel.org; Thu, 20 Oct 2005 00:09:51 -0400 (EDT) Date: Wed, 19 Oct 2005 21:09:50 -0700 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9E35815@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4357188E.4020605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <A0A653F4CB702442BFBF2FAF02C031E9E35815@xmb-sjc-21e.amer.cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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: Thu, 20 Oct 2005 04:10:59 -0000 Status: RO Content-Length: 7609 When I say "it is sent twice", I mean that the first time it is sent by A, natively. RB1 does not send it natively, just encapsulated. So perhaps I misparsed your question. I was answering "how many times does the packet get sent on that link" and from this question I guess you were asking "how many times does RB1 transmit the packet on the link." The answer to THAT question is "once", and it will be encapsulated. Though with you extra link that you added now, it might be zero, depending on whether the spanning tree the RBridges calculated from the link state database, for ingress RBridge RB1, includes that link or not. So, for your first question: > Why does RB1 send it onto the Bridged link with a "native" DA Broadcast? > If, as you said, F will receive the frame directly from A, then wouldn't > this cause F to get two copies? > No. RB1 does not send the packet natively. If it did, then F will receive two copies. But it doesn't. This misunderstanding is that I was answering a different question than you were asking, apparently. For your second question: > Now, the broadcast distribution tree may be (and would probably be > better) calculated to use the direct link between RB1--RB2 instead of > through the Bridged network. Unfortunately, RB1 probably cannot tell > the difference between a direct connection and a Bridged network > connection, but let's say it chooses this link. Now, wouldn't RB2 get > two copies of the broadcast...or is there more to this - such as some > kind of RPF check that is needed. The RBridges use the link state database to calculate a tree of shortest paths from RB1. So packets only arrive once. Radia Larry Kreeger (kreeger) wrote On 10/19/05 17:53,: > Radia, > > Why does RB1 send it onto the Bridged link with a "native" DA Broadcast? > If, as you said, F will receive the frame directly from A, then wouldn't > this cause F to get two copies? > > Also, I'm not sure if using an "all RBridges" DA would work if the > RBridges had other connectivity. For example, if I add a link in the > topology between RB1 and RB2, > > > B C D E > | | | | > RB1--RB2 RB3 RB4 > | | | | > --------------------- > | | > F A > > Now, the broadcast distribution tree may be (and would probably be > better) calculated to use the direct link between RB1--RB2 instead of > through the Bridged network. Unfortunately, RB1 probably cannot tell > the difference between a direct connection and a Bridged network > connection, but let's say it chooses this link. Now, wouldn't RB2 get > two copies of the broadcast...or is there more to this - such as some > kind of RPF check that is needed. > > - Larry > > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] > Sent: Wednesday, October 19, 2005 4:24 PM > To: Larry Kreeger (kreeger) > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > It is sent twice. > The first time it is "native", with DA=broadcast > > The second time is encapsulated by RB1, so the packet has outer header > DA="all RBridges", a shim header with "ingress=RB1", and the inner > packet being exactly as transmitted by A. > > Onto other links though...RB1 will transmit it to B unencapsulated, > i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and RB4 > to E. > > And just a note...in case there were other endnodes on the bridged link, > the RBridges don't worry about it...those endnodes receive the packet > directly from A. > > So, for instance, F below will receive the packet when A transmitted it. > > B C D E > | | | | > RB1 RB2 RB3 RB4 > | | | | > --------------------- > | | > F A > > > > Radia > > > > > > Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: > >>Radia, >> >>In Step 6, is the frame sent onto the link between RB1 and B1 once or >>3 times? If once, what is the Ethernet DA? >> >>Thanks, Larry >> >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>On Behalf Of Radia Perlman >>Sent: Wednesday, October 19, 2005 3:57 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>thread >> >>Step 1: The bridges create a single broadcast domain, as seen by the >>RBridges. So the RBridges see the following picture: >> >> B C D E >> | | | | >> RB1 RB2 RB3 RB4 >> | | | | >> --------------------- >> | >> A >> >>Step 2: RB1 is elected DR, so it is the only one that will encapsulate > > >>or decapsulate to/from that link. >> >>Step 3: A transmits a broadcast or multicast packet >> >>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since >>they are not allowed to process native (non-encapsulated) packets >> >>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress > > RB1" > >>Step 6: RB1 forwards the encapsulated packet onto the link, with an >>outer header with a multicast address "all RBridges" >> >>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it >>in order to send to their upward link (to C, D, and E, respectively). >> >>Step 8: (which could certainly happen after 5 or 6...doesn't have to >>be in order). RB1 decapsulates the packet and sends it to B. >> >>************ >>Hope that helps... >> >>Radia >> >> >> >> >>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: >> >> >>>Radia, >>> >>>I think I now understand now that the DR election happens only between >> >> >>>RBridges on a single shared link - and does not require usage of any >>>RBridge topology information. It would help clarify the data flow for >> >> >>>me (and hopefully others) if, given the network diagram below, you >>>could please give a step by step description of how a broadcast frame >>>sent by host A gets through each Bridge and RBridge in this network in >> >> >>>order to be received by hosts B,C,D,E if we assume that RB1 is the >>>Designated RBridge on the "link" created by the Bridged network formed >> >> >>>by Bridges B1,B2,B3,B4. >>> >>> B C D E >>> | | | | >>>RB1 RB2 RB3 RB4 >>> | | | | >>> B1---B2---B3---B4 >>> | >>> A >>> >>>Thanks, Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Radia Perlman >>>Sent: Wednesday, October 19, 2005 9:57 AM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>>thread >>> >>>The IS-IS Hello protocol is for electing a single unique switch per >>>link. It doesn't matter which one it is. >>> >>>On the other hand, the spanning tree protocol is picking a special >>>single unique bridge per link...the one that is closest to the root. >>> >>>The spanning tree algorithm is choosing a tree of shortest paths from >>>the root. >>> >>>IS-IS is not trying to do that. It is just electing one guy on a link >>>to do special link-specific things. >>> >>>Radia >>>_______________________________________________ >>>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 sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9K0sFL21999 for <rbridge@postel.org>; Wed, 19 Oct 2005 17:54:15 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2005 17:54:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9K0rZ9Q016894 for <rbridge@postel.org>; Wed, 19 Oct 2005 17:54:06 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 17:54:00 -0700 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: Wed, 19 Oct 2005 17:53:37 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9E35815@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXVBEOllW05kS9XRIK4t97RdKsGCwACtLMQ From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 20 Oct 2005 00:54:00.0535 (UTC) FILETIME=[C243E670:01C5D510] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9K0sFL21999 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 20 Oct 2005 00:54:50 -0000 Status: RO Content-Length: 5545 Radia, Why does RB1 send it onto the Bridged link with a "native" DA Broadcast? If, as you said, F will receive the frame directly from A, then wouldn't this cause F to get two copies? Also, I'm not sure if using an "all RBridges" DA would work if the RBridges had other connectivity. For example, if I add a link in the topology between RB1 and RB2, B C D E | | | | RB1--RB2 RB3 RB4 | | | | --------------------- | | F A Now, the broadcast distribution tree may be (and would probably be better) calculated to use the direct link between RB1--RB2 instead of through the Bridged network. Unfortunately, RB1 probably cannot tell the difference between a direct connection and a Bridged network connection, but let's say it chooses this link. Now, wouldn't RB2 get two copies of the broadcast...or is there more to this - such as some kind of RPF check that is needed. - Larry -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@Sun.COM] Sent: Wednesday, October 19, 2005 4:24 PM To: Larry Kreeger (kreeger) Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread It is sent twice. The first time it is "native", with DA=broadcast The second time is encapsulated by RB1, so the packet has outer header DA="all RBridges", a shim header with "ingress=RB1", and the inner packet being exactly as transmitted by A. Onto other links though...RB1 will transmit it to B unencapsulated, i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and RB4 to E. And just a note...in case there were other endnodes on the bridged link, the RBridges don't worry about it...those endnodes receive the packet directly from A. So, for instance, F below will receive the packet when A transmitted it. B C D E | | | | RB1 RB2 RB3 RB4 | | | | --------------------- | | F A Radia Larry Kreeger (kreeger) wrote On 10/19/05 16:17,: > Radia, > > In Step 6, is the frame sent onto the link between RB1 and B1 once or > 3 times? If once, what is the Ethernet DA? > > Thanks, Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Radia Perlman > Sent: Wednesday, October 19, 2005 3:57 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > Step 1: The bridges create a single broadcast domain, as seen by the > RBridges. So the RBridges see the following picture: > > B C D E > | | | | > RB1 RB2 RB3 RB4 > | | | | > --------------------- > | > A > > Step 2: RB1 is elected DR, so it is the only one that will encapsulate > or decapsulate to/from that link. > > Step 3: A transmits a broadcast or multicast packet > > Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since > they are not allowed to process native (non-encapsulated) packets > > Step 5: RB1 encapsulates it to be sent over spanning tree "ingress RB1" > > Step 6: RB1 forwards the encapsulated packet onto the link, with an > outer header with a multicast address "all RBridges" > > Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it > in order to send to their upward link (to C, D, and E, respectively). > > Step 8: (which could certainly happen after 5 or 6...doesn't have to > be in order). RB1 decapsulates the packet and sends it to B. > > ************ > Hope that helps... > > Radia > > > > > Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: > >>Radia, >> >>I think I now understand now that the DR election happens only between > > >>RBridges on a single shared link - and does not require usage of any >>RBridge topology information. It would help clarify the data flow for > > >>me (and hopefully others) if, given the network diagram below, you >>could please give a step by step description of how a broadcast frame >>sent by host A gets through each Bridge and RBridge in this network in > > >>order to be received by hosts B,C,D,E if we assume that RB1 is the >>Designated RBridge on the "link" created by the Bridged network formed > > >>by Bridges B1,B2,B3,B4. >> >> B C D E >> | | | | >> RB1 RB2 RB3 RB4 >> | | | | >> B1---B2---B3---B4 >> | >> A >> >>Thanks, Larry >> >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>On Behalf Of Radia Perlman >>Sent: Wednesday, October 19, 2005 9:57 AM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU >>thread >> >>The IS-IS Hello protocol is for electing a single unique switch per >>link. It doesn't matter which one it is. >> >>On the other hand, the spanning tree protocol is picking a special >>single unique bridge per link...the one that is closest to the root. >> >>The spanning tree algorithm is choosing a tree of shortest paths from >>the root. >> >>IS-IS is not trying to do that. It is just electing one guy on a link >>to do special link-specific things. >> >>Radia >>_______________________________________________ >>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 sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JNHwL23997 for <rbridge@postel.org>; Wed, 19 Oct 2005 16:17:58 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 19 Oct 2005 16:17:53 -0700 X-IronPort-AV: i="3.97,232,1125903600"; d="scan'208"; a="354315590:sNHT37366016" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9JNHQ9M010634; Wed, 19 Oct 2005 16:17:51 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 16:17:34 -0700 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: Wed, 19 Oct 2005 16:17:33 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9E357B3@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXVAfeeFZeixIF/QrmYUOxpvXPdeAAASJrg From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: <Radia.Perlman@Sun.COM>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 19 Oct 2005 23:17:34.0906 (UTC) FILETIME=[49C2F9A0:01C5D503] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9JNHwL23997 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 19 Oct 2005 23:18:52 -0000 Status: RO Content-Length: 3376 Radia, In Step 6, is the frame sent onto the link between RB1 and B1 once or 3 times? If once, what is the Ethernet DA? Thanks, Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Wednesday, October 19, 2005 3:57 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread Step 1: The bridges create a single broadcast domain, as seen by the RBridges. So the RBridges see the following picture: B C D E | | | | RB1 RB2 RB3 RB4 | | | | --------------------- | A Step 2: RB1 is elected DR, so it is the only one that will encapsulate or decapsulate to/from that link. Step 3: A transmits a broadcast or multicast packet Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since they are not allowed to process native (non-encapsulated) packets Step 5: RB1 encapsulates it to be sent over spanning tree "ingress RB1" Step 6: RB1 forwards the encapsulated packet onto the link, with an outer header with a multicast address "all RBridges" Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it in order to send to their upward link (to C, D, and E, respectively). Step 8: (which could certainly happen after 5 or 6...doesn't have to be in order). RB1 decapsulates the packet and sends it to B. ************ Hope that helps... Radia Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: > Radia, > > I think I now understand now that the DR election happens only between > RBridges on a single shared link - and does not require usage of any > RBridge topology information. It would help clarify the data flow for > me (and hopefully others) if, given the network diagram below, you > could please give a step by step description of how a broadcast frame > sent by host A gets through each Bridge and RBridge in this network in > order to be received by hosts B,C,D,E if we assume that RB1 is the > Designated RBridge on the "link" created by the Bridged network formed > by Bridges B1,B2,B3,B4. > > B C D E > | | | | > RB1 RB2 RB3 RB4 > | | | | > B1---B2---B3---B4 > | > A > > Thanks, Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Radia Perlman > Sent: Wednesday, October 19, 2005 9:57 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > The IS-IS Hello protocol is for electing a single unique switch per > link. It doesn't matter which one it is. > > On the other hand, the spanning tree protocol is picking a special > single unique bridge per link...the one that is closest to the root. > > The spanning tree algorithm is choosing a tree of shortest paths from > the root. > > IS-IS is not trying to do that. It is just electing one guy on a link > to do special link-specific things. > > Radia > _______________________________________________ > 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 brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JMulL15639 for <rbridge@postel.org>; Wed, 19 Oct 2005 15:56:47 -0700 (PDT) Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9JMukeT024643 for <rbridge@postel.org>; Wed, 19 Oct 2005 16:56:46 -0600 (MDT) 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 <0IOM00L01QC1XT@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Wed, 19 Oct 2005 18:56:46 -0400 (EDT) Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IOM00E2BQELLI@bur-mail2.east.sun.com> for rbridge@postel.org; Wed, 19 Oct 2005 18:56:46 -0400 (EDT) Date: Wed, 19 Oct 2005 15:56:45 -0700 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9E35767@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4356CF2D.80508@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <A0A653F4CB702442BFBF2FAF02C031E9E35767@xmb-sjc-21e.amer.cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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: Wed, 19 Oct 2005 22:58:59 -0000 Status: RO Content-Length: 2807 Step 1: The bridges create a single broadcast domain, as seen by the RBridges. So the RBridges see the following picture: B C D E | | | | RB1 RB2 RB3 RB4 | | | | --------------------- | A Step 2: RB1 is elected DR, so it is the only one that will encapsulate or decapsulate to/from that link. Step 3: A transmits a broadcast or multicast packet Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since they are not allowed to process native (non-encapsulated) packets Step 5: RB1 encapsulates it to be sent over spanning tree "ingress RB1" Step 6: RB1 forwards the encapsulated packet onto the link, with an outer header with a multicast address "all RBridges" Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it in order to send to their upward link (to C, D, and E, respectively). Step 8: (which could certainly happen after 5 or 6...doesn't have to be in order). RB1 decapsulates the packet and sends it to B. ************ Hope that helps... Radia Larry Kreeger (kreeger) wrote On 10/19/05 15:25,: > Radia, > > I think I now understand now that the DR election happens only between > RBridges on a single shared link - and does not require usage of any > RBridge topology information. It would help clarify the data flow for > me (and hopefully others) if, given the network diagram below, you could > please give a step by step description of how a broadcast frame sent by > host A gets through each Bridge and RBridge in this network in order to > be received by hosts B,C,D,E if we assume that RB1 is the Designated > RBridge on the "link" created by the Bridged network formed by Bridges > B1,B2,B3,B4. > > B C D E > | | | | > RB1 RB2 RB3 RB4 > | | | | > B1---B2---B3---B4 > | > A > > Thanks, Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, October 19, 2005 9:57 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU > thread > > The IS-IS Hello protocol is for electing a single unique switch per > link. It doesn't matter which one it is. > > On the other hand, the spanning tree protocol is picking a special > single unique bridge per link...the one that is closest to the root. > > The spanning tree algorithm is choosing a tree of shortest paths from > the root. > > IS-IS is not trying to do that. It is just electing one guy on a link to > do special link-specific things. > > Radia > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JMPqL07041 for <rbridge@postel.org>; Wed, 19 Oct 2005 15:25:52 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 19 Oct 2005 15:25:47 -0700 X-IronPort-AV: i="3.97,232,1125903600"; d="scan'208"; a="354294471:sNHT1319429200" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9JMPa9C011749 for <rbridge@postel.org>; Wed, 19 Oct 2005 15:25:45 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 15:25:38 -0700 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: Wed, 19 Oct 2005 15:25:37 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9E35767@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FW: Time to summarize "forward or block" BPDU thread Thread-Index: AcXUz7CnftnkJthRQAm/NFaGzkW2bgAKwQXA From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 19 Oct 2005 22:25:38.0305 (UTC) FILETIME=[081F6710:01C5D4FC] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9JMPqL07041 Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 19 Oct 2005 22:26:51 -0000 Status: RO Content-Length: 1463 Radia, I think I now understand now that the DR election happens only between RBridges on a single shared link - and does not require usage of any RBridge topology information. It would help clarify the data flow for me (and hopefully others) if, given the network diagram below, you could please give a step by step description of how a broadcast frame sent by host A gets through each Bridge and RBridge in this network in order to be received by hosts B,C,D,E if we assume that RB1 is the Designated RBridge on the "link" created by the Bridged network formed by Bridges B1,B2,B3,B4. B C D E | | | | RB1 RB2 RB3 RB4 | | | | B1---B2---B3---B4 | A Thanks, Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Wednesday, October 19, 2005 9:57 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread The IS-IS Hello protocol is for electing a single unique switch per link. It doesn't matter which one it is. On the other hand, the spanning tree protocol is picking a special single unique bridge per link...the one that is closest to the root. The spanning tree algorithm is choosing a tree of shortest paths from the root. IS-IS is not trying to do that. It is just electing one guy on a link to do special link-specific things. Radia 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 j9JGv2L20404 for <rbridge@postel.org>; Wed, 19 Oct 2005 09:57:02 -0700 (PDT) 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 <0IOM000PV9QURT00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 19 Oct 2005 09:56:54 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOM000JP9QUU510@mail.sunlabs.com> for rbridge@postel.org; Wed, 19 Oct 2005 09:56:54 -0700 (PDT) Date: Wed, 19 Oct 2005 09:57:00 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4355A400.3020904@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43567ADC.3060607@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: <200510181557.j9IFvPog016032@lion.seas.upenn.edu> <4355A400.3020904@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: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 19 Oct 2005 16:58:13 -0000 Status: RO Content-Length: 3633 The IS-IS Hello protocol is for electing a single unique switch per link. It doesn't matter which one it is. On the other hand, the spanning tree protocol is picking a special single unique bridge per link...the one that is closest to the root. The spanning tree algorithm is choosing a tree of shortest paths from the root. IS-IS is not trying to do that. It is just electing one guy on a link to do special link-specific things. Radia Joe Touch wrote: >Saikat Ray wrote: > > >>Saikat Ray wrote: >> >> >> >>>Now you can have an rbridge and an sbridge in the same L2 (how do you >>>know you don't?). They form an undetectable, uncorrectable loop. >>> >>> >>>[Saikat] I do not see how this happens. First I am assuming that if >>>"sbridges" are connected by physical links, then they know how to avoid >>>packet loops by some mechanism they choose to implement. Now, as far as >>>"sbridges" are concerned, the network consisting of RBridges, STP-running >>>bridges, physical links etc., is simply a "link". In other words, the >>> >>> >>entire >> >> >> >>>network (consisting of RBridges, STP-running bridges, physical links etc.) >>>could be replaced by a physical link. Thus even in this case, there would >>> >>> >>be >> >> >> >>>no packet loop in the steady state. >>> >>>Another way of looking at this argument is the following. Suppose you >>> >>> >>remove >> >> >> >>>all the RBridges from the network. sBridges and legacy bridges are left, >>> >>> >>and >> >> >> >>>the assumption is that in that case, at least, a loop-free network >>> >>> >>results. >> >> >> >>>Then when you add RBridges (in their original position), the rest of the >>>network is simply one or more "link"s, and RBridges would ensure that >>> >>> >>there >> >> >> >>>would be no loops. >>> >>> >>Except that the rbridges add a 'link' between themselves - that's the >>extra 'link' that can cause the loop. >> >>Joe >> >>[Saikat] We discussed this possibility before (Radia and I exchanged a >>couple of emails). When RBbridges add a "link" between themselves (actually >>you need to consider only the scenario when "designated" RBridges add a >>"link" between themselves), there will be a temporary loop. Then the >>designated RBridges will start seeing each others' hello messages, and they >>will know that there is a loop. In that case, all but one designated >>RBridges (who are connected to themselves by a single "link") will >>"de-designate" themselves. Thus in the steady state there would be no loop. >> >>Thinking more about the problem of "Lateral compatibility"---i.e. when there >>is a third protocol (the one your imaginary "sBridge" implements) that do >>not know about RBridges and vice versa---I am quite convinced that *if* all >>the protocols jointly converge to a steady state, there will be no loop in >>the system. This basically follows from the fact that in the steady state, >>each given protocol can view the rest of the network as one or more "links". >>However, in the presence of 3 or more protocols, it is not clear to me >>whether joint convergence to a steady state is guaranteed in all cases (I >>posted a message regarding this before). I tend to believe that in >>"ordinary" cases it should, but there may exist special cases... >> >> > >If all this is true, why not do this for ordinary bridges? > >Joe > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JEaFL04519 for <rbridge@postel.org>; Wed, 19 Oct 2005 07:36:15 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9JEaDgZ005681 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Oct 2005 10:36:14 -0400 Message-Id: <200510191436.j9JEaDgZ005681@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Joe Touch'" <touch@ISI.EDU> Date: Wed, 19 Oct 2005 10:36:24 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUr7MnQHmX/GiqTOGuCgqT0aRUBAABzKEwAADhquA= X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 19 Oct 2005 14:36:50 -0000 Status: RO Content-Length: 3693 >>Now you can have an rbridge and an sbridge in the same L2 (how do you >>know you don't?). They form an undetectable, uncorrectable loop. >> >> >>[Saikat] I do not see how this happens. First I am assuming that if >>"sbridges" are connected by physical links, then they know how to avoid >>packet loops by some mechanism they choose to implement. Now, as far as >>"sbridges" are concerned, the network consisting of RBridges, STP-running >>bridges, physical links etc., is simply a "link". In other words, the > > entire > >>network (consisting of RBridges, STP-running bridges, physical links etc.) >>could be replaced by a physical link. Thus even in this case, there would > > be > >>no packet loop in the steady state. >> >>Another way of looking at this argument is the following. Suppose you > > remove > >>all the RBridges from the network. sBridges and legacy bridges are left, > > and > >>the assumption is that in that case, at least, a loop-free network > > results. > >>Then when you add RBridges (in their original position), the rest of the >>network is simply one or more "link"s, and RBridges would ensure that > > there > >>would be no loops. > > > Except that the rbridges add a 'link' between themselves - that's the > extra 'link' that can cause the loop. > > Joe > > [Saikat] We discussed this possibility before (Radia and I exchanged a > couple of emails). When RBbridges add a "link" between themselves (actually > you need to consider only the scenario when "designated" RBridges add a > "link" between themselves), there will be a temporary loop. Then the > designated RBridges will start seeing each others' hello messages, and they > will know that there is a loop. In that case, all but one designated > RBridges (who are connected to themselves by a single "link") will > "de-designate" themselves. Thus in the steady state there would be no loop. > > Thinking more about the problem of "Lateral compatibility"---i.e. when there > is a third protocol (the one your imaginary "sBridge" implements) that do > not know about RBridges and vice versa---I am quite convinced that *if* all > the protocols jointly converge to a steady state, there will be no loop in > the system. This basically follows from the fact that in the steady state, > each given protocol can view the rest of the network as one or more "links". > However, in the presence of 3 or more protocols, it is not clear to me > whether joint convergence to a steady state is guaranteed in all cases (I > posted a message regarding this before). I tend to believe that in > "ordinary" cases it should, but there may exist special cases... If all this is true, why not do this for ordinary bridges? Joe [Saikat] I just sent an email yesterday to the list regarding the situation if ordinary bridges simply choose an arbitrary "designated" bridge per LAN without regard to its distance from a given bridge (the "root"). Probably you missed it. You can check it here. http://www.postel.org/pipermail/rbridge/2005-October/000744.html Basically, loops are avoided, but the network may end up disconnected! This does not happen in RBridges because RBridges send *encapsulated* packets without any restriction, which preserve connectivity. In other words, if you allow ordinary bridges to encapsulate packets and send them without any topological restriction, then you could as well use an arbitrary designated bridge per LAN, but then ordinary bridges would simply become RBridges! In other words, the critical difference between the ordinary bridge and RBridge (in my mind, at least) is that ordinary bridges are not allowed to modify the data packets in any way, but RBridges are. Received: from [128.9.176.133] (ras33.isi.edu [128.9.176.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JDFPL06667; Wed, 19 Oct 2005 06:15:26 -0700 (PDT) Message-ID: <4355A400.3020904@isi.edu> Date: Tue, 18 Oct 2005 18:40:16 -0700 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: saikat@seas.upenn.edu References: <200510181557.j9IFvPog016032@lion.seas.upenn.edu> In-Reply-To: <200510181557.j9IFvPog016032@lion.seas.upenn.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1FC76960D69853CF464B7017" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 19 Oct 2005 13:19:15 -0000 Status: RO Content-Length: 3450 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1FC76960D69853CF464B7017 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > Saikat Ray wrote: > >>Now you can have an rbridge and an sbridge in the same L2 (how do you >>know you don't?). They form an undetectable, uncorrectable loop. >> >> >>[Saikat] I do not see how this happens. First I am assuming that if >>"sbridges" are connected by physical links, then they know how to avoid >>packet loops by some mechanism they choose to implement. Now, as far as >>"sbridges" are concerned, the network consisting of RBridges, STP-running >>bridges, physical links etc., is simply a "link". In other words, the > > entire > >>network (consisting of RBridges, STP-running bridges, physical links etc.) >>could be replaced by a physical link. Thus even in this case, there would > > be > >>no packet loop in the steady state. >> >>Another way of looking at this argument is the following. Suppose you > > remove > >>all the RBridges from the network. sBridges and legacy bridges are left, > > and > >>the assumption is that in that case, at least, a loop-free network > > results. > >>Then when you add RBridges (in their original position), the rest of the >>network is simply one or more "link"s, and RBridges would ensure that > > there > >>would be no loops. > > > Except that the rbridges add a 'link' between themselves - that's the > extra 'link' that can cause the loop. > > Joe > > [Saikat] We discussed this possibility before (Radia and I exchanged a > couple of emails). When RBbridges add a "link" between themselves (actually > you need to consider only the scenario when "designated" RBridges add a > "link" between themselves), there will be a temporary loop. Then the > designated RBridges will start seeing each others' hello messages, and they > will know that there is a loop. In that case, all but one designated > RBridges (who are connected to themselves by a single "link") will > "de-designate" themselves. Thus in the steady state there would be no loop. > > Thinking more about the problem of "Lateral compatibility"---i.e. when there > is a third protocol (the one your imaginary "sBridge" implements) that do > not know about RBridges and vice versa---I am quite convinced that *if* all > the protocols jointly converge to a steady state, there will be no loop in > the system. This basically follows from the fact that in the steady state, > each given protocol can view the rest of the network as one or more "links". > However, in the presence of 3 or more protocols, it is not clear to me > whether joint convergence to a steady state is guaranteed in all cases (I > posted a message regarding this before). I tend to believe that in > "ordinary" cases it should, but there may exist special cases... If all this is true, why not do this for ordinary bridges? Joe --------------enig1FC76960D69853CF464B7017 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDVaQAE5f5cImnZrsRAlK2AKDNW4HZgn7qe6aPh7qSC0dd27+5rQCeOE+Y zkc2GJMHJZ1rtiEUZm4gnj0= =YXY0 -----END PGP SIGNATURE----- --------------enig1FC76960D69853CF464B7017-- Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JD50L02871 for <rbridge@postel.org>; Wed, 19 Oct 2005 06:05:00 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9JD4xk8023372 for <rbridge@postel.org>; Wed, 19 Oct 2005 07:05:00 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9JD4aPG228255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Oct 2005 06:04:52 -0700 (PDT) Message-ID: <4356445F.9020201@sun.com> Date: Wed, 19 Oct 2005 06:04:31 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <713043CE8B8E1348AF3C546DBE02C1B405213D23@zcarhxm2.corp.nortel.com> <43553FCF.1010202@sun.com> In-Reply-To: <43553FCF.1010202@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 19 Oct 2005 13:05:44 -0000 Status: RO Content-Length: 1712 Thanks for doing the summaries. Radia Perlman wrote: > I'm assuming Peter is saying the same thing I am. But without speaking > for him, let me say > a) RBridges have to block. That's a nice simple clean thing to do. It works > b) I don't understand why people think there is a problem, and I don't > think they've > stated what they are worried about clearly enough, at least for me to > understand it Having caught up on trill email, it seems like the root of the concern that Joe has (and I haven't seen others express it) is that things are simple to understand if the rbridged cloud can be abstracted as a single bridge. I would agree that things are harder to understand if this is not the case. My take is that there can be different abstractions in the data plane and the control plane. In the data plane I think we all want the rbridged cloud to behave as a single bridge (for instance, a packet to an unknown destination would be flooded to all ports of this conceptual bridge). But for the control plane we have (at least) two choices: - make the rbridge cloud behave exactly as a single bridge from the perspective of an observer that can look at all the ports of this conceptual bridge - make the rbridge cloud behave in a way that interoperates with (does not violate any assumptions of) the bridged networks they interconnect. My understanding is that Joe has been arguing for the former. But this seems to lead to undesirable behavior due to the interdependency of 802.1D and RBridges. For instance, the bridges would pick a single root bridge for the whole campus, and should the root bridge fail it will affect the whole campus until 802.1D has converged. Erik Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9JCFQL18269 for <rbridge@postel.org>; Wed, 19 Oct 2005 05:15:26 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9JCFPeT027083 for <rbridge@postel.org>; Wed, 19 Oct 2005 06:15:26 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9JCFJxI220643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Oct 2005 05:15:23 -0700 (PDT) Message-ID: <435637D8.1020709@sun.com> Date: Wed, 19 Oct 2005 05:11:04 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <28f32dda66a3.435355f5@sunlabs.com> <43546833.8090301@isi.edu> In-Reply-To: <43546833.8090301@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 19 Oct 2005 12:15:44 -0000 Status: RO Content-Length: 415 Joe Touch wrote: > What exactly are rbridges 'like' if they BLOCK? I think they would be like IP multicast routers, but operating at L2 instead of L3. Multicast routers, unlike IP unicast routers, need to be concerned with multiple next-hops picking up the same packet. Same issue appears for RBridges. The proposed solution for RBridges is what we have for multicast (a single elected forwarder). Erik Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9INcwL26643 for <rbridge@postel.org>; Tue, 18 Oct 2005 16:38:58 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9INcvm0013460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Tue, 18 Oct 2005 19:38:57 -0400 Message-Id: <200510182338.j9INcvm0013460@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Tue, 18 Oct 2005 19:39:07 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXTrHACg9Pl/pHhSr2ImdOjZ7VRQQAWMIcAAA2CLCA= In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213D23@zcarhxm2.corp.nortel.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 18 Oct 2005 23:39:41 -0000 Status: RO Content-Length: 2074 This I believe is what he was alluding too in his example. In Particular he was asserting that if the DR mechanism can work without looking at BPDUS then why can't it work in a regular bridge without BPDUS. The answer I believe to that question is that it could but you would lose the ability to compute a shortest path first tree to a preferred root. You'd just converge on some tree. [Saikat] In the legacy network, if you choose an arbitrary bridge connected to a LAN segment as its designated bridge, then you do avoid loops, but you may end up in a disconnected network! I am not good at ASCII art, but I will try to show an example. ___ |_| | _______|_________ | _|_ | | /---\ ______________/ \__________________ _|_ _|__ |_| |__| Assume that there are three LAN segments (the straight lines) and 4 bridges (the boxes). One of the bridges is connected to all the 3 LAN segments; the rest 3 bridges connect these three LAN segments to the rest of the network (i.e. the network has more LAN segments). Now if there is an arbitrary bridge designation process that does not look into the distance from root, then all the three LANs may choose the middle bridge as their designated bridge, and then this part of the network would be disconnected from the rest because the other three bridges will not send/receive packets to/from these LAN segments. In the RBridge case, of course, the system works because RBridges send encapsulated packets without restriction. Legacy bridges did not have that luxury, I guess! Hopefully some of this or the previous explanation is enough to convince folks that BLOCK does indeed work. .. if not ... well I'm out of ideas too. Peter _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9ILlxL26899 for <rbridge@postel.org>; Tue, 18 Oct 2005 14:47:59 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9ILlpp15160 for <rbridge@postel.org>; Tue, 18 Oct 2005 17:47:51 -0400 (EDT) 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: Tue, 18 Oct 2005 17:47:51 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D2E@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXUH+jmxoj/1dXWQhWJ8CYpvvhbhAADY7Qg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9ILlxL26899 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 21:49:11 -0000 Status: RO Content-Length: 2421 Well if you need help with the drafts I do have a bit of bandwidth at the moment and would be happy to help out if I can. Peter > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric > Sent: Tuesday, October 18, 2005 4:05 PM > To: 'Developing a hybrid router/bridge.' > Subject: Re: [rbridge] Time to summarize "forward or block" > BPDU thread > > > Joe, > > I am deeply concerned that there seems to be some > differences in opinion between those that are working on the > draft(s?) and a lot of the rest of the working group. > > More-over, I am not sure that the differences are > entirely in terminology. But I guess we'll just have to wait > and see... > > -- > Eric > > --> -----Original Message----- > --> From: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org]On > --> Behalf Of Joe Touch > --> Sent: Monday, October 17, 2005 10:27 AM > --> To: Developing a hybrid router/bridge. > --> Subject: Re: [rbridge] Time to summarize "forward or block" > --> BPDU thread > --> > --> > --> _______________________________________________ > --> rbridge mailing list > --> rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge > --> > > Earlier you wrote (and by the way I wish I didn't have to do it > this way, but your E-Mail is broken :-): > > > > Harald Tveit Alvestrand wrote: > > > > > > --On 17. oktober 2005 05:17 -0700 Joe Touch <touch@ISI.EDU> wrote: > > > >> WHEN (note the use of 'when', not 'if', since there's > *nothing* that > >> can be done to enforce this) this isn't the case, the following > >> problems > >> arise: > >> > >> a) there is no way to detect the error > >> > >> b) loops *will* occur > > > > > > You know, I really can't tell whether this is true or not without > > looking at the protocol specification that says how the RBridges > > detect each other. > > > > Should this discussion wait for the drafts to come out? > > As someone trying to write the drafts, I'm trying to > understand the terminology that will determine this. > > I have a MUCH better idea of how to explain things now - > whether I agree with them at all levels or not, so this > discussion IS helping, FWIW. > > Joe > _______________________________________________ > rbridge mailing list > rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge > > Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9ILhRL25623 for <rbridge@postel.org>; Tue, 18 Oct 2005 14:43:28 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 304672596AF for <rbridge@postel.org>; Tue, 18 Oct 2005 23:42:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06520-06 for <rbridge@postel.org>; Tue, 18 Oct 2005 23:42:50 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86BDA258082 for <rbridge@postel.org>; Tue, 18 Oct 2005 23:42:49 +0200 (CEST) Date: Tue, 18 Oct 2005 23:40:53 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: rbridge@postel.org Message-ID: <0B16C1301E04DAF7CF892B64@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========B12939CA737273ACCFFD==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: [rbridge] Non-Spanning-Tree bridges do exist 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, 18 Oct 2005 21:44:06 -0000 Status: RO Content-Length: 1606 --==========B12939CA737273ACCFFD========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline My curiosity got the better of me.... I remembered that the el-cheapo switch I'm using as a junction box in my=20 office had 2 spare ports. So I crawled under my desk and connected a wire between the two. Sure enough, in a little while the two lamps turned green; a little later=20 the lamps started flashing, and just a few moments later, ALL the lamps on=20 the box started flashing. I had created a broadcast storm. I hurriedly disconnected the link, and the network went back to normal. End = of experiment. Conclusion: Not all bridges implement spanning tree. Users who have physical access to such a device, and connect wires without=20 thinking, can create broadcast storms. But as long as the physical topology is a tree, they do no harm. Not sure what implications this has for this group. (note: Either this device is in category BLOCK, or it's TRANSPARENT, and=20 ALL the switches in my house, which are of about 4 different makes, all of=20 them cheap, fail to implement any form of ST - because I don't see any=20 BPDUs on the wire). Harald --==========B12939CA737273ACCFFD========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDVWvmOMj+2+WY0F4RAkprAJwOw4Yt+0keUdc//7c79kMw9KIWTQCgiBND LiZj1/rw0AqMtu0LQhJeQE0= =O/zR -----END PGP SIGNATURE----- --==========B12939CA737273ACCFFD==========-- 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 j9ILHuL19022 for <rbridge@postel.org>; Tue, 18 Oct 2005 14:17:56 -0700 (PDT) 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 j9ILHnrP002287 for <rbridge@postel.org>; Tue, 18 Oct 2005 17:17:50 -0400 (EDT) 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 RAA19584 for <rbridge@postel.org>; Tue, 18 Oct 2005 17:17:49 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXX5GM>; Tue, 18 Oct 2005 18:17:49 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FB3@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, 18 Oct 2005 18:17:48 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D429.0D39D04C" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 18 Oct 2005 21:18:55 -0000 Status: RO Content-Length: 12217 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D429.0D39D04C Content-Type: text/plain; charset="iso-8859-1" Alia, Slightly larger is large enough for people who are just a little too large to have a simple bridged network. It may also be large enough if routing table size is forcing larger L2 networks to be as large as possible and no other choices exist. -- Eric -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]On Behalf Of Alia Atlas Sent: Monday, October 17, 2005 3:02 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] MAN scale and future uses of Rbridge On 10/17/05, Peter Ashwood-Smith < petera@nortel.com <mailto:petera@nortel.com> > wrote: I think the main impediment to very large scale is the large flat address space and its rate of change. Not the number or Rbridge nodes and networks/links. While use of IS-IS or OSPF areas can help when addressing is hierarchical, they are not going to help much when you cannot aggregate the addresses into specific areas. There are environments where the rate of change could be reasonably bounded, so that brings it back to the flat address space... Then again I don't think that Rbridge needs to scale that large to be enormously useful. If it pushes the attainable size out a bit, gives better routes, is more stable and allows future innovations based on the topology it is going to be very useful. After that .. well its routers all the way down ;) What do you think is large enough? (I remember the discussion earlier, but not specific numbers.) Alia Peter -----Original Message----- From: rbridge-bounces@postel.org <mailto:rbridge-bounces@postel.org> [mailto: <mailto:rbridge-bounces@postel.org> rbridge-bounces@postel.org] On Behalf Of Alia Atlas Sent: Monday, October 17, 2005 2:37 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] MAN scale and future uses of Rbridge On 10/17/05, Sofia, Rute < rute.sofia@siemens.com <mailto:rute.sofia@siemens.com> > wrote: Considering Rbridges application from a MAN scope, other scalability issues relate to: - storage cost (the price of flat addressing and of having every Rbridge learning both requested and unrequested MAC destination addresses) may be decreased, but is something that has not be considered up until now, given that the scope is limited to a campus... What number of MAC addresses is the target for the rbridge campus? Do you think the constraints are on the memory or on the notifications required due to changes? - scalability related to the IS-IS tuning. On this point, (I am not completely sure about the price but...), there is a price to pay to tune IS-IS in order to achieve convergence in the order of hundreds of seconds. This is another issue to be checked. Is there a reason that different areas couldn't be used in the IS-IS instance for rbridges? Do you think this would be adequate? Are the topological restrictions (i.e. hub and spoke) acceptable? Could we work around that? Summing up, these are issues to be considered *if* Rbridges is to be extended to something larger than a campus. But going back to the participate vs. non-participate in the ST issue, then the scope is something that may help in deciding this issue. As I said, I do not see that Rbridges need to intervene *if* the scope is limited to a campus. Why? Because as stated in Radia's paper, Rbridges can simply terminate STs, which makes all the sense given that a Rbridge is a hybrid router. But this scenario does not seem to make the same sense, if a MAN scope is considered... While improving the scalability may not be immediately in scope, I think it is worthwhile to consider where the restrictions are coming from. Alia _______________________________________________ rbridge mailing list rbridge@postel.org <mailto:rbridge@postel.org> http://www.postel.org/mailman/listinfo/rbridge <http://www.postel.org/mailman/listinfo/rbridge> ------_=_NextPart_001_01C5D429.0D39D04C Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>Alia,</FONT></SPAN></DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=186231521-18102005> <FONT face=Arial color=#0000ff size=2>Slightly larger is large enough for people who are just a little too large</FONT></SPAN></DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>to have a simple bridged network. It may also be large enough if routing</FONT></SPAN></DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>table size is forcing larger L2 networks to be as large as possible and no</FONT></SPAN></DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>other choices exist.</FONT></SPAN></DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>--</FONT></SPAN></DIV> <DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>Eric</FONT></SPAN></DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]<B>On Behalf Of </B>Alia Atlas<BR><B>Sent:</B> Monday, October 17, 2005 3:02 PM<BR><B>To:</B> Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] MAN scale and future uses of Rbridge<BR><BR></FONT></DIV>On 10/17/05, <B class=gmail_sendername>Peter Ashwood-Smith</B> <<A href="mailto:petera@nortel.com">petera@nortel.com</A>> wrote: <DIV><SPAN class=gmail_quote></SPAN> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><SPAN><FONT face=Arial color=#0000ff size=2>I think the main impediment to very large scale is the large flat address space and its rate of change. Not the number or Rbridge nodes and networks/links. While use of IS-IS or OSPF areas can help when addressing is hierarchical, they are not going to help much when you cannot aggregate the addresses into specific areas.</FONT></SPAN></DIV></BLOCKQUOTE> <DIV><BR>There are environments where the rate of change could be reasonably bounded, so that brings it back to the flat address space...<BR></DIV><BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><SPAN><FONT face=Arial color=#0000ff size=2>Then again I don't think that Rbridge needs to scale that large to be enormously useful. If it pushes the attainable size out a bit, gives better routes, is more stable and allows future innovations based on the topology it is going to be very useful. After that .. well its routers all the way down ;)</FONT></SPAN></DIV></BLOCKQUOTE> <DIV><BR>What do you think is large enough? (I remember the discussion earlier, but not specific numbers.)<BR><BR>Alia <BR></DIV><BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><SPAN class=sg> <DIV><SPAN><FONT face=Arial color=#0000ff size=2>Peter</FONT> </SPAN></DIV></SPAN> <DIV><SPAN class=e id=q_106ffefd56937552_2> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV lang=en-us dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> <A onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rbridge-bounces@postel.org" target=_blank>rbridge-bounces@postel.org</A> [mailto:<A onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rbridge-bounces@postel.org" target=_blank> rbridge-bounces@postel.org</A>] <B>On Behalf Of </B>Alia Atlas<BR><B>Sent:</B> Monday, October 17, 2005 2:37 PM<BR><B>To:</B> Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] MAN scale and future uses of Rbridge<BR><BR></FONT></DIV><BR><BR> <DIV><SPAN class=gmail_quote>On 10/17/05, <B class=gmail_sendername>Sofia, Rute</B> <<A onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rute.sofia@siemens.com" target=_blank>rute.sofia@siemens.com</A>> wrote:</SPAN> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Considering Rbridges application from a MAN scope, other scalability<BR>issues relate to:<BR>- storage cost (the price of flat addressing and of having every<BR>Rbridge learning both requested and unrequested MAC destination <BR>addresses) may be decreased, but is something that has not be considered<BR>up until now, given that the scope is limited to a campus...</BLOCKQUOTE> <DIV><BR> What number of MAC addresses is the target for the rbridge campus? Do you<BR>think the constraints are on the memory or on the notifications required due to changes? <BR><BR></DIV> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">- scalability related to the IS-IS tuning. On this point, (I am not<BR>completely sure about the price but...), there is a price to pay to tune <BR>IS-IS in order to achieve convergence in the order of hundreds of<BR>seconds. This is another issue to be checked.</BLOCKQUOTE> <DIV><BR>Is there a reason that different areas couldn't be used in the IS-IS instance for rbridges?<BR>Do you think this would be adequate? Are the topological restrictions (i.e. hub and spoke)<BR>acceptable? Could we work around that?<BR></DIV><BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Summing up, these are issues to be considered *if* Rbridges is to be<BR>extended to something larger than a campus. But going back to the <BR>participate vs. non-participate in the ST issue, then the scope is<BR>something that may help in deciding this issue. As I said, I do not see<BR>that Rbridges need to intervene *if* the scope is limited to a campus.<BR>Why? Because as stated in Radia's paper, Rbridges can simply terminate<BR>STs, which makes all the sense given that a Rbridge is a hybrid router.<BR>But this scenario does not seem to make the same sense, if a MAN scope<BR>is considered...<BR></BLOCKQUOTE></DIV><BR>While improving the scalability may not be immediately in scope, I think it is<BR>worthwhile to consider where the restrictions are coming from.<BR><BR>Alia<BR></BLOCKQUOTE></SPAN></DIV><BR>_______________________________________________<BR>rbridge mailing list<BR><A onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rbridge@postel.org">rbridge@postel.org</A><BR><A onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.postel.org/mailman/listinfo/rbridge" target=_blank>http://www.postel.org/mailman/listinfo/rbridge</A><BR><BR><BR><BR clear=all></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C5D429.0D39D04C-- 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 j9IKhtL08170 for <rbridge@postel.org>; Tue, 18 Oct 2005 13:43:55 -0700 (PDT) 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 j9IKhnrP001695 for <rbridge@postel.org>; Tue, 18 Oct 2005 16:43:49 -0400 (EDT) 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 QAA16472 for <rbridge@postel.org>; Tue, 18 Oct 2005 16:43:48 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXXZKV>; Tue, 18 Oct 2005 17:43:48 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FAC@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, 18 Oct 2005 17:43:47 -0300 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] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 20:44:42 -0000 Status: RO Content-Length: 4135 Joe, Assuming that discovery of another RBridge on a link means that the link is internal, then any link that connects two RBridges is internal. That in turn forces the formation of a single campus - unless another behavior is configured. Conceded. However, we do not have to worry about an environment in which mythical devices that also block STP exist. That's because we never could avoid those environments and therefore always had to allow for them. Also, we do not have to worry about a loop external to the RBridges. The existence of such a loop indicates either that there are two ports of the same RBridge on a bridged network segment (which the RBridge could handle itself), or that the loop is not external (because more than one RBridge is on the same bridged network segment). If we consider how an RBridge looks to the existing L2 network, if it does block STP, what we find is that the rest of the network will see each distinct port of an Rbridge as a separate Hub with a possibly large number of MAC addresses attached to it. It's important to understand this, because it will have serious effects on bridge stability, both for STP and bridge learning, if we do not handle this correctly in specifying RBridge behavior. One simple approach might be to have the whole RBridge campus behave exactly as a bridge would behave - including STP, port blocking, etc. But that is neither a necessity, nor necessarily a good idea. And, it may not be the simplest approach either. I think this is the perspective from which many are currently arguing. There are at least a couple of reasons why this perspective makes sense: 1) behaving exactly like a bridge is exactly what we hope to get away from, and 2) getting an RBridge campus to behave as one large bridge is not itself a simple goal The simplest approach - to A) improve on the behavior of bridges and B) avoid trying to look like a single large bridge - is to simply block STP. As far as what happens if some other device(s) also block STP, we have to expect that a network having those devices is expected to work - because otherwise we cannot improve the situation. If it works, then RBridges will not make the situation worse. If these - possibly mythical - devices are capable of creating a loop for frame transport, then the RBridges are better off not relying on STP as a mechanism to detect this. If such a loop exists, then it should be easily detected by sending some form of limited broadcast message. If it blocks STP, then what good would it do to participate in STP? If it doesn't forward broadcast messages, then what's the problem? -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Monday, October 17, 2005 10:22 AM --> To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. --> Subject: Re: [rbridge] Time to summarize "forward or block" --> BPDU thread --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier you wrote: Saikat Ray wrote: > AFAICT, this all works when there is at most one rbridge campus in an L2. > > [Saikat] I think that the assumption (definition) is that if two RBridges > are connected directly (i.e. no IP router in between), then they are parts > of a single campus, thus must talk to each other. If that is true, then how > would you have more than one campuses that are not separated by an IP > router? You won't - the rbridge campuses will merge. But we're the IETF, and we're making 'rbridges', which will BLOCK. Let's say the IEEE decides to allow another group to make 'sbridges', which also decide to BLOCK. Now you can have an rbridge and an sbridge in the same L2 (how do you know you don't?). They form an undetectable, uncorrectable loop. -- I.e. - this all works only if everyone plays by OUR rules. Since we're NOT the IEEE, how is it that we can decide to create a protocol that relies on us being the ONLY exception? Joe 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 j9IKOOL00788 for <rbridge@postel.org>; Tue, 18 Oct 2005 13:24:24 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 37A9F9D270 for <rbridge@postel.org>; Tue, 18 Oct 2005 22:24:18 +0200 (CEST) Received: from [163.117.203.234] (unknown [163.117.203.234]) by smtp01.uc3m.es (Postfix) with ESMTP id 4A4A99D241 for <rbridge@postel.org>; Tue, 18 Oct 2005 22:24:17 +0200 (CEST) Message-ID: <435559F2.5020204@it.uc3m.es> Date: Tue, 18 Oct 2005 22:24:18 +0200 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: <83AB0942FD087D499DF2DD5CEE1B613302837053@cacexc06.americas.cpqcorp.net> <43553C1D.10102@sun.com> In-Reply-To: <43553C1D.10102@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] Optimizing Performance Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 20:24:41 -0000 Status: RO Content-Length: 1598 One way, although somewhat restrictive, to achieve optimality in paths and high performance, is to restrict the Rbridges to connect between themselves, forming the core of the campus network, sbridges not allowed inside the core, only outside. In this way, all paths in the core go throug per ingress bridge tree and are optimal. Besides this, the paths through the sbridges spanning tree to the ingress and egress Rbridge are also optimal. Guillermo Radia Perlman wrote: >Right. I wasn't saying something other than that. >What I'm saying is that if there's just a single shared tree, and >multiple transmitters, >then it's not clear what the optimal tree would be...probably one would >have to know the >volume of traffic between each pair of speakers. > >So at any rate, I don't think we should be trying for "optimal", even if >we knew what we were >optimizing, since it would be really expensive to try to get the extra >tiny bit of possible >performance by going from simple, easy, and pretty good, to optimal. > >But per-ingress trees is pretty close to optimal anyway. It will be a >tree of shortest paths from >the sender to each receiver. > >Radia > > > >Ghanwani, Anoop wrote: > > > >>This is not necessarily true. Depending on which ports >>block, traffic sourced from some nodes will have to >>travel more hops to get to all of the links. The tree >>is optimal only for the root node. >> >>Anoop >> >> >> >> >> > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > > Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IKGlL28015 for <rbridge@postel.org>; Tue, 18 Oct 2005 13:16:47 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9IKGGp27160 for <rbridge@postel.org>; Tue, 18 Oct 2005 16:16:16 -0400 (EDT) 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: Tue, 18 Oct 2005 16:16:01 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D29@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXUHe5lbuoINuShT02NvQJMDguypgAAebsQ From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9IKGlL28015 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 20:17:40 -0000 Status: RO Content-Length: 8340 > Peter, > > Privately I agree strongly with your first statement and > would extend it to include understanding of STP, bridge > learning and a slew of other things. I have this > understanding from my > days working at Cabletron, and I suspect that a few of the > other people in this discussion do as well. But I don't > think it is ever going to be true generally in this venue. > And this was why > I questioned the wisdom of trying to do this in the IETF - and > especially trying to do it in the IETF in the Internet Area. Unfortunately if you do it somewhere else you get the reverse problem. Expertise at L2 but not as much understanding of L3 protocols. > I also want to thank you for fielding Joe's questions in > the last few days. I have been unable to get connected to my > company network (and it's Exchange server) for the last couple days... Well let's hope I did not add to the confusion. Peter > > -- > Eric > > --> -----Original Message----- > --> From: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org]On > --> Behalf Of Peter Ashwood-Smith > --> Sent: Sunday, October 16, 2005 9:10 PM > --> To: Developing a hybrid router/bridge. > --> Subject: Re: [rbridge] Time to summarize "forward or block" > --> BPDU thread > --> > --> > --> > --> This lack of understanding of the DRs seems to be the > --> cause of a lot > --> of this debate. > --> > --> Also, the 'problems' that people are attributing to > --> blocking and not > --> processing BPDUs [BLOCK] are also 'problems' when no STP > is running. > --> In the case where two broadcast domains are rbridged > --> together in such a > --> way > --> as to create a loop, the DR mechanism will detect and > --> prevent it, so it > --> works > --> even when BPDUs are not present. > --> > --> So far the only reason I can think of to allow BPDUs to > --> passively pass > --> is for migration purposes. To keep the tree from changing > --> 'just yet' but > --> it certainly won't speed anything up, fix anything or do > --> more to prevent > --> loops than blocking will. > --> > --> Peter Ashwood-Smith > --> > --> > -----Original Message----- > --> > From: rbridge-bounces@postel.org > --> > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > --> > Sent: Sunday, October 16, 2005 8:46 PM > --> > To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. > --> > Subject: Re: [rbridge] Time to summarize "forward or block" > --> > BPDU thread > --> > > --> > > --> > The scenario you mention is where there is temporarily > --> two Designated > --> > RBridges (DRs), because > --> > two links were merged. > --> > > --> > The DRs will notice this when they start seeing each other's > --> > IS-IS Hello > --> > messages, and that > --> > will break the loop. > --> > > --> > I don't think this case is that much of a problem, and > --> > certainly would > --> > not be helped by trying to run a big > --> > global spanning tree. The big global spanning tree would > --> > converge much > --> > slower than the RBridge > --> > DR election protocol would. So attempting to avoid a > --> > temporary loop when > --> > two bridged domains > --> > are merged, by running a big global instance > --> > of the spanning tree algorithm, will not solve the > --> problem, and will > --> > actually > --> > make things worse. > --> > > --> > Radia > --> > > --> > > --> > > --> > > --> > Saikat Ray wrote: > --> > > --> > >It is probably a standard scenario in IS-IS protocol (and > --> > consequently > --> > >a standard solution is known), but I was thinking that if > --> > the RBridges > --> > >disregards BPDUs entirely, then in some situations loops may > --> > form for > --> > >some period. For example, suppose $T_1$ and $T_2$ are > --> disjoint trees > --> > >formed entirely by legacy elements. $R_1$ and $R_2$ are the > --> > designated > --> > >RBridges for the "links" $T_1$ and $T_2$, respectively. At > --> > this point, > --> > >there is no loop in the system. Now suppose that a physical > --> > link (or a > --> > >legacy bridge) is added that connects a legacy bridge of > --> $T_1$ to a > --> > >legacy bridge of $T_2$. This addition will trigger a new > --> > Spanning tree > --> > >computation, which will result into a single spanning tree > --> > that spans > --> > >the nodes of $T_1$ and $T_2$. At this point, effectively the > --> > RBridges > --> > >$R_1$ and $R_2$ are connected by a single "link" and until > --> > one of the > --> > >RBridge gets "de-designated", there would exist a loop. Two > --> > questions > --> > >arise in my mind: (i) how fast would that "de-designation" > --> > process be? > --> > >And (ii) would it be useful (i.e. would it accelerate the > --> > convergence) > --> > >if RBridges "listen" to the BPDUs? > --> > > > --> > >-----Original Message----- > --> > >From: rbridge-bounces@postel.org > --> > [mailto:rbridge-bounces@postel.org] On > --> > >Behalf Of Radia Perlman > --> > >Sent: Sunday, October 16, 2005 7:12 PM > --> > >To: Developing a hybrid router/bridge. > --> > >Subject: [rbridge] Time to summarize "forward or block" > --> BPDU thread > --> > > > --> > >It looks like this thread was discussed with two > --> different subject > --> > >lines, and it's also > --> > >gone on long enough it's time for someone to summarize it. > --> > > > --> > >I strongly believe that things will be more stable if > --> RBridges do NOT > --> > >forward BPDUs...that > --> > >we decouple the protocols. > --> > > > --> > >That TRILL is kind of like a layer between bridging > and routing. > --> > > > --> > >If RBridges do not forward BPDUs, then whether or not > --> the TRILL link > --> > >state protocol is > --> > >converged, it won't affect the little spanning tree inside a > --> > particular > --> > >bridged segment. > --> > > > --> > >That way, the little spanning trees will converge as quickly as > --> > >possible > --> > >(because it's small), > --> > >and cannot possibly be disrupted by RBridges wormholing BPDUs. > --> > > > --> > >I do not understand the reasons why people want to > --> forward BPDUs. I > --> > >think the arguments (which > --> > >I may not be presenting fairly because I don't > --> understand them) are: > --> > >a) you'll get a more optimal combined spanning tree on which > --> > >unknown/broadcast frames will > --> > >be sent if it is one global spanning tree, rather than little > --> > >independent spanning trees hooked together > --> > >by the independently computed spanning tree calculated > by IS-IS. > --> > >b) forwarding BPDUs, and having a global spanning tree, will > --> > prevent loops. > --> > > > --> > >I strongly disagree with both those arguments. For a) > --> What do people > --> > >think is more optimal about a tree > --> > >computed that way vs having independent trees inside > --> each bridged > --> > >island? And besides, there isn't > --> > >a single spanning tree...it's a spanning tree per > --> ingress RBridge. > --> > >For b) no...I believe that having both the RBridge > --> algorithm and the > --> > >bridge algorithm feeding into > --> > >each other will create much slower convergence. > --> > > > --> > >If I haven't summarized correctly, then someone else can try > --> > to capture > --> > >the arguments, but I do > --> > >think we should merge discussion under one subject line, > --> and restart > --> > >with a summary. > --> > > > --> > >Radia > --> > > > --> > >_______________________________________________ > --> > >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 > --> > _______________________________________________ > 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 j9IK5LL23825 for <rbridge@postel.org>; Tue, 18 Oct 2005 13:05:26 -0700 (PDT) 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 j9IK4WrP000799 for <rbridge@postel.org>; Tue, 18 Oct 2005 16:04:40 -0400 (EDT) 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 QAA11664 for <rbridge@postel.org>; Tue, 18 Oct 2005 16:04:32 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXXX98>; Tue, 18 Oct 2005 17:04:32 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FAB@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, 18 Oct 2005 17:04:31 -0300 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] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 20:05:41 -0000 Status: RO Content-Length: 1712 Joe, I am deeply concerned that there seems to be some differences in opinion between those that are working on the draft(s?) and a lot of the rest of the working group. More-over, I am not sure that the differences are entirely in terminology. But I guess we'll just have to wait and see... -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Monday, October 17, 2005 10:27 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] Time to summarize "forward or block" --> BPDU thread --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier you wrote (and by the way I wish I didn't have to do it this way, but your E-Mail is broken :-): Harald Tveit Alvestrand wrote: > > > --On 17. oktober 2005 05:17 -0700 Joe Touch <touch@ISI.EDU> wrote: > >> WHEN (note the use of 'when', not 'if', since there's *nothing* that can >> be done to enforce this) this isn't the case, the following problems >> arise: >> >> a) there is no way to detect the error >> >> b) loops *will* occur > > > You know, I really can't tell whether this is true or not without > looking at the protocol specification that says how the RBridges detect > each other. > > Should this discussion wait for the drafts to come out? As someone trying to write the drafts, I'm trying to understand the terminology that will determine this. I have a MUCH better idea of how to explain things now - whether I agree with them at all levels or not, so this discussion IS helping, FWIW. Joe 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 j9IJp4L20313 for <rbridge@postel.org>; Tue, 18 Oct 2005 12:51:04 -0700 (PDT) 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 j9IJowrP000538 for <rbridge@postel.org>; Tue, 18 Oct 2005 15:50:58 -0400 (EDT) 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 PAA10102 for <rbridge@postel.org>; Tue, 18 Oct 2005 15:50:58 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXXXQM>; Tue, 18 Oct 2005 16:50:57 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FA9@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, 18 Oct 2005 16:50:57 -0300 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] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 19:51:38 -0000 Status: RO Content-Length: 7595 Peter, Privately I agree strongly with your first statement and would extend it to include understanding of STP, bridge learning and a slew of other things. I have this understanding from my days working at Cabletron, and I suspect that a few of the other people in this discussion do as well. But I don't think it is ever going to be true generally in this venue. And this was why I questioned the wisdom of trying to do this in the IETF - and especially trying to do it in the IETF in the Internet Area. I also want to thank you for fielding Joe's questions in the last few days. I have been unable to get connected to my company network (and it's Exchange server) for the last couple days... -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Peter Ashwood-Smith --> Sent: Sunday, October 16, 2005 9:10 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] Time to summarize "forward or block" --> BPDU thread --> --> --> --> This lack of understanding of the DRs seems to be the --> cause of a lot --> of this debate. --> --> Also, the 'problems' that people are attributing to --> blocking and not --> processing BPDUs [BLOCK] are also 'problems' when no STP is running. --> In the case where two broadcast domains are rbridged --> together in such a --> way --> as to create a loop, the DR mechanism will detect and --> prevent it, so it --> works --> even when BPDUs are not present. --> --> So far the only reason I can think of to allow BPDUs to --> passively pass --> is for migration purposes. To keep the tree from changing --> 'just yet' but --> it certainly won't speed anything up, fix anything or do --> more to prevent --> loops than blocking will. --> --> Peter Ashwood-Smith --> --> > -----Original Message----- --> > From: rbridge-bounces@postel.org --> > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> > Sent: Sunday, October 16, 2005 8:46 PM --> > To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. --> > Subject: Re: [rbridge] Time to summarize "forward or block" --> > BPDU thread --> > --> > --> > The scenario you mention is where there is temporarily --> two Designated --> > RBridges (DRs), because --> > two links were merged. --> > --> > The DRs will notice this when they start seeing each other's --> > IS-IS Hello --> > messages, and that --> > will break the loop. --> > --> > I don't think this case is that much of a problem, and --> > certainly would --> > not be helped by trying to run a big --> > global spanning tree. The big global spanning tree would --> > converge much --> > slower than the RBridge --> > DR election protocol would. So attempting to avoid a --> > temporary loop when --> > two bridged domains --> > are merged, by running a big global instance --> > of the spanning tree algorithm, will not solve the --> problem, and will --> > actually --> > make things worse. --> > --> > Radia --> > --> > --> > --> > --> > Saikat Ray wrote: --> > --> > >It is probably a standard scenario in IS-IS protocol (and --> > consequently --> > >a standard solution is known), but I was thinking that if --> > the RBridges --> > >disregards BPDUs entirely, then in some situations loops may --> > form for --> > >some period. For example, suppose $T_1$ and $T_2$ are --> disjoint trees --> > >formed entirely by legacy elements. $R_1$ and $R_2$ are the --> > designated --> > >RBridges for the "links" $T_1$ and $T_2$, respectively. At --> > this point, --> > >there is no loop in the system. Now suppose that a physical --> > link (or a --> > >legacy bridge) is added that connects a legacy bridge of --> $T_1$ to a --> > >legacy bridge of $T_2$. This addition will trigger a new --> > Spanning tree --> > >computation, which will result into a single spanning tree --> > that spans --> > >the nodes of $T_1$ and $T_2$. At this point, effectively the --> > RBridges --> > >$R_1$ and $R_2$ are connected by a single "link" and until --> > one of the --> > >RBridge gets "de-designated", there would exist a loop. Two --> > questions --> > >arise in my mind: (i) how fast would that "de-designation" --> > process be? --> > >And (ii) would it be useful (i.e. would it accelerate the --> > convergence) --> > >if RBridges "listen" to the BPDUs? --> > > --> > >-----Original Message----- --> > >From: rbridge-bounces@postel.org --> > [mailto:rbridge-bounces@postel.org] On --> > >Behalf Of Radia Perlman --> > >Sent: Sunday, October 16, 2005 7:12 PM --> > >To: Developing a hybrid router/bridge. --> > >Subject: [rbridge] Time to summarize "forward or block" --> BPDU thread --> > > --> > >It looks like this thread was discussed with two --> different subject --> > >lines, and it's also --> > >gone on long enough it's time for someone to summarize it. --> > > --> > >I strongly believe that things will be more stable if --> RBridges do NOT --> > >forward BPDUs...that --> > >we decouple the protocols. --> > > --> > >That TRILL is kind of like a layer between bridging and routing. --> > > --> > >If RBridges do not forward BPDUs, then whether or not --> the TRILL link --> > >state protocol is --> > >converged, it won't affect the little spanning tree inside a --> > particular --> > >bridged segment. --> > > --> > >That way, the little spanning trees will converge as quickly as --> > >possible --> > >(because it's small), --> > >and cannot possibly be disrupted by RBridges wormholing BPDUs. --> > > --> > >I do not understand the reasons why people want to --> forward BPDUs. I --> > >think the arguments (which --> > >I may not be presenting fairly because I don't --> understand them) are: --> > >a) you'll get a more optimal combined spanning tree on which --> > >unknown/broadcast frames will --> > >be sent if it is one global spanning tree, rather than little --> > >independent spanning trees hooked together --> > >by the independently computed spanning tree calculated by IS-IS. --> > >b) forwarding BPDUs, and having a global spanning tree, will --> > prevent loops. --> > > --> > >I strongly disagree with both those arguments. For a) --> What do people --> > >think is more optimal about a tree --> > >computed that way vs having independent trees inside --> each bridged --> > >island? And besides, there isn't --> > >a single spanning tree...it's a spanning tree per --> ingress RBridge. --> > >For b) no...I believe that having both the RBridge --> algorithm and the --> > >bridge algorithm feeding into --> > >each other will create much slower convergence. --> > > --> > >If I haven't summarized correctly, then someone else can try --> > to capture --> > >the arguments, but I do --> > >think we should merge discussion under one subject line, --> and restart --> > >with a summary. --> > > --> > >Radia --> > > --> > >_______________________________________________ --> > >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 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 j9IJilL18125 for <rbridge@postel.org>; Tue, 18 Oct 2005 12:44:47 -0700 (PDT) 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 j9IJifrP000377 for <rbridge@postel.org>; Tue, 18 Oct 2005 15:44:41 -0400 (EDT) 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 PAA09525 for <rbridge@postel.org>; Tue, 18 Oct 2005 15:44:41 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXXXKN>; Tue, 18 Oct 2005 16:44:40 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FA8@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, 18 Oct 2005 16:44:40 -0300 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 j9IJilL18125 Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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, 18 Oct 2005 19:45:42 -0000 Status: RO Content-Length: 4629 Joe, There are two ways to look at what we are doing. One is to start with the conclusion that we don't want an RBridge to do any thing different than a bridge. The other is that we do want the RBridge to do something different than a bridge but we want it to be compatible in a "drop-in" mode with bridges. I doubt that the former is the correct perspective, as the immediate question that comes to my mind (at least) is why are we doing anything at all then? For the latter, we have to work from a better understanding than "[STP] is there for a reason." STP is there to establish a _single_ path for full network connectivity among devices that do not have any other protection against forwarding loops. If we plan to design RBridges with the specific intent of A) having more than one path for full connectivity and B) provide appropriate additional protection against forwarding loops, then we have to analyze how this impacts STP and vice versa. We do not have to blindly accept STP as the only answer - nor should we, at least among RBridges, as the intent of STP works directly against the intention of developing RBridges. The answers given already show that it is straight-forward for a RBridge to determine it has a loop through the bridges in the network - via, for example, a hello protocol. That takes care of the case where a connected set of bridges, hubs and lower-level layer two devices are all that is between one port and another of the same RBridge. The case where the path between two ports of an RBridge also includes another (one or more) RBridge(s), only makes this slightly harder. In order to solve the slightly harder case, it is sufficient - for example - to simply say that the only RBridge that does not forward "Hello" message is the one that originated it. What this would mean is that all of the RBridges have to forward some type of "Hello" message unless they originated it (meaining - obviously - that we need to come up with an essentially fool proof way to allow them to determine which messages they originated), rather than simply receiving and consuming it. It may be the case that there is more than one type of "hello" message in the "hello protocol" - loop detection hello messages and peer discovery hello messages. I don't know that it will be necessary to make this distinction, but it will be simpler. There may be other approaches that work just as well, but - as I said earlier - it is sufficient to show that at least one solution exists. Note that this approach relies on exactly the same thing as you're concerned about - the fact that broadcast messages will be broadcast throughout a broadcast domain, irrespective of what equipment is used and what cheats each equipment uses. If that is not true, then the network is already broken and we're not making it worse. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Sunday, October 16, 2005 3:33 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstract for problem and --> applicabi lity statement --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier, you wrote: Harald Tveit Alvestrand wrote: > > --On s?ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <touch@ISI.EDU> > wrote: > > >>>What we should be thinking of (to my mind) is "how do we discover that >>>we're up the creek" - for this particular disaster, sending out a >>>broadcast packet and watching it come back should be quite sufficient >>>for the "detect" part.... >> >>What if you send a packet and it creates a broadcast storm? Sure, you >>know you're up the creek, but how do you paddle back? > > if I have an one-packet answer to "how to take down a network", that > network is certainly in trouble without me..... but others have certainly > suggested forms of probing (hello packets?) that might be more gentle. My concern is that every reason for allowing BLOCK for rbridges is a reason to allow them for bridges as well. SPT is there for a reason - to avoid the possibility of loops, and thus such one-packet problems (deliberate or otherwise). I don't understand why that's the required default for bridges (AFACT - regardless of vendor offerings) but can be relaxed here. > I'd very much like to design a network that is stable in the presence of a > person with a laptop, an ordinary bridge port and no conscience.... Agreed. Joe 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 j9IJ2dL06090 for <rbridge@postel.org>; Tue, 18 Oct 2005 12:02:39 -0700 (PDT) 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 j9IJ2UrP029226 for <rbridge@postel.org>; Tue, 18 Oct 2005 15:02:30 -0400 (EDT) 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 PAA04201 for <rbridge@postel.org>; Tue, 18 Oct 2005 15:02:30 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXXVXL>; Tue, 18 Oct 2005 16:02:29 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FA6@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, 18 Oct 2005 16:02:26 -0300 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] seeking input on abstract for problem and applicabi lity statement 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, 18 Oct 2005 19:03:39 -0000 Status: RO Content-Length: 1051 Joe, Typically, a broadcast storm that is a "real problem" is one in which the broadcast message goes around and around. As we are positing that a "hello" message seen on a different interface than the one it was sent on is an indication of a loop, we are also assuming (I hope) that this is the only broadcast that should be handled by RBridges until loop-free forwarding has been determined. It would be a fairly lame RBridge that 1) saw a "hello" message that it originated and reforwarded it irrespective of what interface it receives it on. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Sunday, October 16, 2005 12:22 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstract for problem and --> applicabi lity statement --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IIpwL02677 for <rbridge@postel.org>; Tue, 18 Oct 2005 11:51:58 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9IInEF09863 for <rbridge@postel.org>; Tue, 18 Oct 2005 14:49:14 -0400 (EDT) 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: Tue, 18 Oct 2005 14:51:50 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D26@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXUEw1LJZY9i7LeScOdYS8xa+dnTQAAF9eg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9IIpwL02677 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 18:53:08 -0000 Status: RO Content-Length: 3657 > > Hopefully nobody will interpret "out of ideas" as "giving in and > accepting that we have > to have a single huge merged spanning tree because we've been > convinced > that BLOCK > won't work". Lets hope not, clearly I meant "out of ideas" as to how to convince folks that block really does work. At least not without a white board and colored markers... > I'm assuming Peter is saying the same thing I am. But without > speaking > for him, Close enough ... yes. However I do feel it is worth enumerating the different approaches (even if we strongly disagree with them) so that they have names and there is a place to attach the conclusions regarding their desirability/correctness or lack thereof etc. Otherwise 3 months from now we'll get the same set of questions. If they are already answered /debated it saves time down the road. Peter > let me say > a) RBridges have to block. That's a nice simple clean thing > to do. It works > b) I don't understand why people think there is a problem, > and I don't > think they've > stated what they are worried about clearly enough, at least for me to > understand it > c) It's really hard to argue when I don't understand what the > issue is. > d) forwarding BPDUs is a really really bad, scary idea, and > will have no > advantages. > > I'm guessing the anti-BLOCK folk are confused about where a packet > enters a bridged island, and where it > leaves the bridged island. Perhaps there's no way to explain it in > email, and perhaps it could be > all cleared up with a little off-list telephone conversation. > If anyone > wants to talk to me by phone, let me know, > since hopefully it will clear things up and we can get on to other > issues, if there are any. > > But I'll try to explain it yet another way. > > Within the bridged island there is just a single tree. > Traffic can enter > that tree anywhere, and leave it > anywhere. The only job of bridges within that island is to make that > happen....to accept traffic anywhere, > and let it leave anywhere. Just as if the link were a token > ring, or token bus. The magic inside the link is irrelevant > to anything working on top of the link. Just so long as the > link creates > a fully connected, broadcast domain. > > So the bridged island can be thought of, to RBridges, as a single > physical link. > > Now try to imagine RBridges in a world without bridges, since the > bridges are inside the links, > and successfully doing their job of creating a fully > connected broadcast > domain within the > bridged island. As long as BPDUs are blocked, and the island > really is > isolated from the rest > of the world except for devices that act as stations on that island > (like RBridges or routers or endnodes), > any of the following are equivalent models of the link: a > single wire, a > bridged Ethernet, a token ring, > a bridged token ring, a token bus, .... > > If there's a problem with providing service on top of a link > which is a > fully > connected broadcast domain, then IP routers have the same problem. > > Radia > > > > > > Peter Ashwood-Smith wrote: > > > > > > > Hopefully some of this or the previous explanation is enough to > >convince folks that BLOCK does indeed work. .. if not ... well I'm > >out of ideas too. > > > > Peter > > > > > > > > > > > >_______________________________________________ > >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 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 j9IIWkL27342 for <rbridge@postel.org>; Tue, 18 Oct 2005 11:32:46 -0700 (PDT) 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 <0IOK00MWQJIHZK00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 18 Oct 2005 11:32:41 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOK0000WJIGU200@mail.sunlabs.com> for rbridge@postel.org; Tue, 18 Oct 2005 11:32:41 -0700 (PDT) Date: Tue, 18 Oct 2005 11:32:47 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B405213D23@zcarhxm2.corp.nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43553FCF.1010202@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: <713043CE8B8E1348AF3C546DBE02C1B405213D23@zcarhxm2.corp.nortel.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] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 18:33:41 -0000 Status: RO Content-Length: 2731 Hopefully nobody will interpret "out of ideas" as "giving in and accepting that we have to have a single huge merged spanning tree because we've been convinced that BLOCK won't work". I'm assuming Peter is saying the same thing I am. But without speaking for him, let me say a) RBridges have to block. That's a nice simple clean thing to do. It works b) I don't understand why people think there is a problem, and I don't think they've stated what they are worried about clearly enough, at least for me to understand it c) It's really hard to argue when I don't understand what the issue is. d) forwarding BPDUs is a really really bad, scary idea, and will have no advantages. I'm guessing the anti-BLOCK folk are confused about where a packet enters a bridged island, and where it leaves the bridged island. Perhaps there's no way to explain it in email, and perhaps it could be all cleared up with a little off-list telephone conversation. If anyone wants to talk to me by phone, let me know, since hopefully it will clear things up and we can get on to other issues, if there are any. But I'll try to explain it yet another way. Within the bridged island there is just a single tree. Traffic can enter that tree anywhere, and leave it anywhere. The only job of bridges within that island is to make that happen....to accept traffic anywhere, and let it leave anywhere. Just as if the link were a token ring, or token bus. The magic inside the link is irrelevant to anything working on top of the link. Just so long as the link creates a fully connected, broadcast domain. So the bridged island can be thought of, to RBridges, as a single physical link. Now try to imagine RBridges in a world without bridges, since the bridges are inside the links, and successfully doing their job of creating a fully connected broadcast domain within the bridged island. As long as BPDUs are blocked, and the island really is isolated from the rest of the world except for devices that act as stations on that island (like RBridges or routers or endnodes), any of the following are equivalent models of the link: a single wire, a bridged Ethernet, a token ring, a bridged token ring, a token bus, .... If there's a problem with providing service on top of a link which is a fully connected broadcast domain, then IP routers have the same problem. Radia Peter Ashwood-Smith wrote: > > > Hopefully some of this or the previous explanation is enough to >convince folks that BLOCK does indeed work. .. if not ... well I'm >out of ideas too. > > Peter > > > > > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IIUtL26866 for <rbridge@postel.org>; Tue, 18 Oct 2005 11:30:55 -0700 (PDT) Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel11.hp.com (Postfix) with ESMTP id B817C10411 for <rbridge@postel.org>; Tue, 18 Oct 2005 11:29:08 -0700 (PDT) Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 11:29:08 -0700 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: Tue, 18 Oct 2005 11:29:07 -0700 Message-ID: <83AB0942FD087D499DF2DD5CEE1B6133028370AE@cacexc06.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXUEWX6+i++kmT4SNycZqHIgCsXFQAACjhw From: "Ghanwani, Anoop" <anoop.ghanwani@hp.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 18 Oct 2005 18:29:08.0389 (UTC) FILETIME=[D3DC4D50:01C5D411] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop.ghanwani@hp.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9IIUtL26866 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 18:31:38 -0000 Status: RO Content-Length: 534 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, October 18, 2005 11:17 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Time to summarize "forward or block" > BPDU thread > [..] > But per-ingress trees is pretty close to optimal anyway. It will be a > tree of shortest paths from the sender to each receiver. This is exactly what IEEE 802.1 is trying to do with the project on Shortest Path Bridging. Anoop 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 j9IIH0L22568 for <rbridge@postel.org>; Tue, 18 Oct 2005 11:17:00 -0700 (PDT) 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 <0IOK00MVZIS7ZK00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 18 Oct 2005 11:16:55 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOK00M0LIS6YW20@mail.sunlabs.com> for rbridge@postel.org; Tue, 18 Oct 2005 11:16:55 -0700 (PDT) Date: Tue, 18 Oct 2005 11:17:01 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <83AB0942FD087D499DF2DD5CEE1B613302837053@cacexc06.americas.cpqcorp.net> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43553C1D.10102@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: <83AB0942FD087D499DF2DD5CEE1B613302837053@cacexc06.americas.cpqcorp.net> 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] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 18:17:38 -0000 Status: RO Content-Length: 922 Right. I wasn't saying something other than that. What I'm saying is that if there's just a single shared tree, and multiple transmitters, then it's not clear what the optimal tree would be...probably one would have to know the volume of traffic between each pair of speakers. So at any rate, I don't think we should be trying for "optimal", even if we knew what we were optimizing, since it would be really expensive to try to get the extra tiny bit of possible performance by going from simple, easy, and pretty good, to optimal. But per-ingress trees is pretty close to optimal anyway. It will be a tree of shortest paths from the sender to each receiver. Radia Ghanwani, Anoop wrote: >This is not necessarily true. Depending on which ports >block, traffic sourced from some nodes will have to >travel more hops to get to all of the links. The tree >is optimal only for the root node. > >Anoop > > > Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IHlDL15024 for <rbridge@postel.org>; Tue, 18 Oct 2005 10:47:13 -0700 (PDT) Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel13.hp.com (Postfix) with ESMTP id 835871C07F5A; Tue, 18 Oct 2005 10:47:13 -0700 (PDT) Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 10:47:13 -0700 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: Tue, 18 Oct 2005 10:47:11 -0700 Message-ID: <83AB0942FD087D499DF2DD5CEE1B613302837053@cacexc06.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXUBQwfIipvDtdOQQOTpZvC9N00TAABmcrg From: "Ghanwani, Anoop" <anoop.ghanwani@hp.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org>, <saikat@seas.upenn.edu> X-OriginalArrivalTime: 18 Oct 2005 17:47:13.0379 (UTC) FILETIME=[F8CC3B30:01C5D40B] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop.ghanwani@hp.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9IHlDL15024 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 17:47:38 -0000 Status: RO Content-Length: 610 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, October 18, 2005 9:46 AM > To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Time to summarize "forward or block" > BPDU thread > > If a broadcast goes to all links, then one spanning tree is > as good as another. This is not necessarily true. Depending on which ports block, traffic sourced from some nodes will have to travel more hops to get to all of the links. The tree is optimal only for the root node. Anoop Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IHcML12008 for <rbridge@postel.org>; Tue, 18 Oct 2005 10:38:22 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9IHcLqO028890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Oct 2005 13:38:21 -0400 Message-Id: <200510181738.j9IHcLqO028890@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Radia Perlman'" <Radia.Perlman@sun.com>, "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Tue, 18 Oct 2005 13:38:30 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <435526BF.5050103@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUA2mB/PGq/iOjQdGHBlguzOobFAABxfqA X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 18 Oct 2005 17:38:37 -0000 Status: RO Content-Length: 463 But what is optimized by STP (and Dijkstra) is the cost from each node to the Root. If the Root were the only sender (which of course it isn't), then one could consider the spanning tree "optimal" in distribution time (though not in total cost of delivery, which would require a minimum weight spanning tree). [Saikat] So you are considering additive per-link static (i.e. independent of the load on the link) cost, right? That is what I wanted to confirm. Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IHEdL04123 for <rbridge@postel.org>; Tue, 18 Oct 2005 10:14:40 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9IHBZF18115 for <rbridge@postel.org>; Tue, 18 Oct 2005 13:11:35 -0400 (EDT) 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: Tue, 18 Oct 2005 13:14:11 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D23@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTrHACg9Pl/pHhSr2ImdOjZ7VRQQAWMIcA From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9IHEdL04123 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 17:16:26 -0000 Status: RO Content-Length: 1454 > One nit, on terminology... > > Just making sure that someone who has recently studied > "minimum spanning > trees" > doesn't get confused by your explanation, Peter. > You're not wrong, but the terminology "minimum spanning tree" usually > refers to something different > than what you're talking about... > something where the total cost of all the links in the tree > is minimum. Yes, sorry, you are too kind, its technically wrong without a macro substitution of the term "minimum spanning tree". That's what I get for trying to think past midnight ;) What I was trying to explain to Joe was that if he simply adopted the DR mechanism from Rbridge in bridges and did away with BPDUS then no form of optimization of the tree is possible since knowledge about what goes on further away is lost. In particular you could not produce a shortest path first tree to a preferred root. This I believe is what he was alluding too in his example. In particular he was asserting that if the DR mechanism can work without looking at BPDUS then why can't it work in a regular bridge without BPDUS. The answer I believe to that question is that it could but you would lose the ability to compute a shortest path first tree to a preferred root. You'd just converge on some tree. Hopefully some of this or the previous explanation is enough to convince folks that BLOCK does indeed work. .. if not ... well I'm out of ideas too. Peter 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 j9IGjoL26124 for <rbridge@postel.org>; Tue, 18 Oct 2005 09:45:50 -0700 (PDT) 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 <0IOK00MOWEK9ZK00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 18 Oct 2005 09:45:45 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOK00MNREK8YW10@mail.sunlabs.com> for rbridge@postel.org; Tue, 18 Oct 2005 09:45:45 -0700 (PDT) Date: Tue, 18 Oct 2005 09:45:51 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <200510181606.j9IG6PoN017879@lion.seas.upenn.edu> To: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435526BF.5050103@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: <200510181606.j9IG6PoN017879@lion.seas.upenn.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: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 16:46:39 -0000 Status: RO Content-Length: 2107 I don't think we should strive for "optimal", but rather "simple, robust, and pretty good". But what is optimized by STP (and Dijkstra) is the cost from each node to the Root. If the Root were the only sender (which of course it isn't), then one could consider the spanning tree "optimal" in distribution time (though not in total cost of delivery, which would require a minimum weight spanning tree). With link state routing, we can get optimal pt-to-pt paths. It's only for multicast that which spanning tree is chosen may matter. If a broadcast goes to all links, then one spanning tree is as good as another. In an earlier email I mentioned several reasons why per-ingress trees are worth the effort: Imagine the actual topology being a big circle, 20 hops around. If it were a single spanning tree, one of the links in the circle would be broken. If a packet originates from the left side of the break, it has to go completely around the circle to get to someone on the right side of the break, even though in the physical topology it's only a single hop. So, for instance, if those two links were the only VLAN A links, then the broadcast domain of VLAN A requires 20 hops to deliver each packet, rather than a single hop, if it were a per-ingress RBridge tree. Basically, with a per-ingress tree, then each packet gets delivered to each link optimally. In the case of VLAN broadcast domains (e.g., for ARPs within VLAN A), and for IP multicast (assuming RBridges snoop on IGMP so they know which subset of links have receivers), per-ingress trees can wind up much less expensive to deliver traffic. Radia Saikat Ray wrote: >[Saikat] I think it is a good opportunity to clarify one thing since the >concept of optimality rose. What cost-function are you considering >optimizing? If you use additive per-link static cost, then for the broadcast >case, under the assumption of symmetrical link costs, any given minimum >weight spanning tree is optimum regardless of the source of the packet. Then >why should there be multiple (per ingress) trees for broadcast? > > > > > Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IG6QL14818 for <rbridge@postel.org>; Tue, 18 Oct 2005 09:06:26 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9IG6PoN017879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Tue, 18 Oct 2005 12:06:25 -0400 Message-Id: <200510181606.j9IG6PoN017879@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Tue, 18 Oct 2005 12:06:34 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <435493C8.1050807@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXTrExtz3XcL8qSQzSW1fuiVsNGQAAUJvGw X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 18 Oct 2005 16:06:42 -0000 Status: RO Content-Length: 5283 And now for more explanation...there's really nothing optimal about the tree computed by STP. Any single shared tree will be good for some S-D pairs, and bad for others. [Saikat] I think it is a good opportunity to clarify one thing since the concept of optimality rose. What cost-function are you considering optimizing? If you use additive per-link static cost, then for the broadcast case, under the assumption of symmetrical link costs, any given minimum weight spanning tree is optimum regardless of the source of the packet. Then why should there be multiple (per ingress) trees for broadcast? The tree created by hopping across bridged islands won't be any more or less optimal than if there were a giant spanning tree across the entire campus, where we went to some effort to ensure the combination of RBridges and bridges computed the same tree as they would have if everyone were bridges. Plus...RBridges aren't computing a single tree anyway...they are computing per-ingress-RBridge trees. As I've said before, we really want to terminate the bridged islands, and then have RBridges just see each bridged island as a single link. Radia Peter Ashwood-Smith wrote: >>Here's the counterexample: >> >>Have existing bridges BLOCK. >> >> > > Thats not really a counter example but let me try to explain >where you are getting confused below. > > > >>Assume each bridge computes its own spanning tree internally >>(i.e., between its own ports on its own device), and sends >>coded 'hellos' that it it recognizes if they loop, i.e., all >>the thinks a campus would do. >> >> > > Because it would not be a MINIMUM spanning tree. However, yes, if you >repeatedly connect a set of node disjoint trees together with a single >link, reducing the number of trees by one each time, the result is a >tree. This I think is what you are suggesting and yes, I believe >an algorithm like this does actually make a tree. The catch is that it >is NOT a minimum spanning tree and you cannot easily select a root. >STP produces a minimum spanning tree rooted where you want it so >you get much more with the STP protocol than just the hello/detect/block >idea. STP requires its BPDUs to flood through the network to elect >the root and compute paths to it and rbridge requires link state to >flood link information so it can compute the minium spanning tree. >Both protocols need to know about ALL the possible paths in their >domains to minimize the resulting tree. >The DR mechanism is only used to prevent a loop between these two >domains but it does not by itself guarantee that the combination of >the two trees is still minimum. Therefore, the DR mechanism if applied >by itself as you suggest does produce a tree but it is not minimum and >you >have no control over the root that is selected. > > Rbridge of course only uses this DR mechanism at the interface between >itself and some other domain (STP or manually configured), and so >you end up with a minimum spanning tree in STP and a minimum spanning >tree in the rbridge >domain but the combination of the two is not necessarily the best >possible >since neither minimization was done over the complete set of links/nodes >available. This makes sense because if you take two minimum solutions >over disjoint sets you cannot simply add them together to produce a >global minimum solution. For example, I cannot take a shortest path from >some node S to an intermediate E and a shortest path from E to D, add >them together and >get the shortest path from S to D because there may be a much better E! > > > >>Now if that works, let's do it for bridges and then we >>wouldn't have a spanning tree convergence problem at all, right? >> >> > > It produces a tree but not a minimum spanning tree with no control >over >the root. So its not quite the 'work' you had in mind and this in a nut >shell is I believe your mistake. > > > >>If that does NOT work, then why does it work for rbridge >>campuses and not bridges? >> >> > > It does work its just that we want minimum spanning trees and >to do that we need information about all the nodes we can reach. >STP gets this by flooding BPDUSs and Rbridges by link state updates. >Take away the BPUDS and you can't get minimum. Rbridges can take >the BPDU away [BLOCk] because it does its own minimum and combines the >results with DR to produce a possibly non global minimum solution but >that is the price you pay for neither side seeing all the data. > > > >>My general test is "an rbridge campus needs to look like a >>bridge" or "look like a link". If it does, then I know I >>understand it. When it doesn't, it would be useful to >>understand whether this is really a 'new animal' and exactly >>why it's newness is unique to rbridges (i.e., why it can't be >>applied as well to bridges). >> >> > > I think you need to think of this as a new animal as Radia suggested. > > Hope this helps. > > Peter > > > > > >>Joe >> >> >> >_______________________________________________ >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 lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IFvTL12107 for <rbridge@postel.org>; Tue, 18 Oct 2005 08:57:29 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9IFvPog016032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Oct 2005 11:57:25 -0400 Message-Id: <200510181557.j9IFvPog016032@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Joe Touch'" <touch@ISI.EDU>, "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Tue, 18 Oct 2005 11:57:34 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <43546A07.1010703@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXTku3nkgZhiU+XSR62FTcUcndwIAAZ+bYg X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 18 Oct 2005 15:57:36 -0000 Status: RO Content-Length: 2567 Saikat Ray wrote: > Now you can have an rbridge and an sbridge in the same L2 (how do you > know you don't?). They form an undetectable, uncorrectable loop. > > > [Saikat] I do not see how this happens. First I am assuming that if > "sbridges" are connected by physical links, then they know how to avoid > packet loops by some mechanism they choose to implement. Now, as far as > "sbridges" are concerned, the network consisting of RBridges, STP-running > bridges, physical links etc., is simply a "link". In other words, the entire > network (consisting of RBridges, STP-running bridges, physical links etc.) > could be replaced by a physical link. Thus even in this case, there would be > no packet loop in the steady state. > > Another way of looking at this argument is the following. Suppose you remove > all the RBridges from the network. sBridges and legacy bridges are left, and > the assumption is that in that case, at least, a loop-free network results. > Then when you add RBridges (in their original position), the rest of the > network is simply one or more "link"s, and RBridges would ensure that there > would be no loops. Except that the rbridges add a 'link' between themselves - that's the extra 'link' that can cause the loop. Joe [Saikat] We discussed this possibility before (Radia and I exchanged a couple of emails). When RBbridges add a "link" between themselves (actually you need to consider only the scenario when "designated" RBridges add a "link" between themselves), there will be a temporary loop. Then the designated RBridges will start seeing each others' hello messages, and they will know that there is a loop. In that case, all but one designated RBridges (who are connected to themselves by a single "link") will "de-designate" themselves. Thus in the steady state there would be no loop. Thinking more about the problem of "Lateral compatibility"---i.e. when there is a third protocol (the one your imaginary "sBridge" implements) that do not know about RBridges and vice versa---I am quite convinced that *if* all the protocols jointly converge to a steady state, there will be no loop in the system. This basically follows from the fact that in the steady state, each given protocol can view the rest of the network as one or more "links". However, in the presence of 3 or more protocols, it is not clear to me whether joint convergence to a steady state is guaranteed in all cases (I posted a message regarding this before). I tend to believe that in "ordinary" cases it should, but there may exist special cases... Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9IC8mL04619 for <rbridge@postel.org>; Tue, 18 Oct 2005 05:08:48 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id i7so24790wra for <rbridge@postel.org>; Tue, 18 Oct 2005 05:08:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d5y4sIggpEDU5Brp2r/62tYV9IMZj6VBktZtSuWX1kc1WUhSN+vS1Ym8plqaXRcrKZBfwS20FlhV6UfjDoyI1N8UofZEHQQ2CzgsYAoXkHYBk5uJARhDy4BIo1m0HfrKBWqIL2Cq7+VExMLh2udocyfkfUr7CIkv+h1eMHis404= Received: by 10.54.157.6 with SMTP id f6mr95144wre; Tue, 18 Oct 2005 05:08:47 -0700 (PDT) Received: by 10.54.124.9 with HTTP; Tue, 18 Oct 2005 05:08:46 -0700 (PDT) Message-ID: <582968a0510180508j21f59ef1v6b73f6b58ebd5259@mail.gmail.com> Date: Tue, 18 Oct 2005 08:08:46 -0400 From: Stephen Suryaputra <ssuryaputra@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <43546833.8090301@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <28f32dda66a3.435355f5@sunlabs.com> <43546833.8090301@isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ssuryaputra@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9IC8mL04619 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ssurya@ieee.org, "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, 18 Oct 2005 12:10:05 -0000 Status: RO Content-Length: 2638 Joe, To me, Rbridge is changing the assumption that there is no router in the L2 network. It fits well with the way L2 network view of routers, they are nodes. From a directly connected L2 network, the Rbridge is sourcing/sinking packets, and blocking (but accepting) broadcast. But instead of terminating them (like nodes), Rbridge is tunneling them. Another point why I think they are nodes, tunneling (i.e. the shim) is using the unicast address of the ingress and egress Rbridges in the L2 header (no?). Since the goal is to reduce the size of spanning tree protocol network, the Rbridge chose not to tunnel BPDU. Tunneling is an option, but that will make a cloud of Rbridges to be a virtual single bridge, which IMHO can create more complex control for Rbridges. Tunnelling BPDU however makes Rbridges look link links, very clean architecturally. So, now there are 4 devices in the L2 network: nodes, links, bridges and Rbridges. Cheers, Stephen. On 10/17/05, Joe Touch <touch@isi.edu> wrote: > > > Radia.Perlman@sun.com wrote: > > It works perfectly well if RBridges block. It isolates the bridge islands. > > > > Routers also block bridge spanning tree, and to exactly the same > > effect as if RBridges block BPDUs. > > This isn't the same at all; I keep hearing the analogy, but it fails > under all tests: > > first, there are NO routers on an L2 net > > all sources/sinks are the same (called nodes AFAICT) > and hosts and routers are just nodes, > identical as far as L2 is concerned > > nodes block all BPDUs (we agree), but > nodes also block broadcast (rbridges don't) > > Near as I can tell, L2 has exactly three devices currently: > > nodes > > links > > bridges (participate in SPT, interpret BPDUs) > > Bridges don't 'block' BPDUs, but they don't forward them to all ports > either. > > Now, an rbridge can be "like" a node, a link, or a bridge and still play > in the existing L2 specs. If it isn't 'like' any of those, then we're > changing the definition of 802, and I didn't think that was the goal here. > > rbridges - at least to nodes on the L2 - are NOT 'like' hosts, since > they don't source or sink L2 traffic to existing nodes > > rbridges could be 'like' links if they are TRANSPARENT > > rbridges could be 'like' bridges if the PARTICIPATE > > What exactly are rbridges 'like' if they BLOCK? > > They can't be 'like' routers - there are no routers in L2. > > ?? > > Joe > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > > > > 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 j9IAZeL11406 for <rbridge@postel.org>; Tue, 18 Oct 2005 03:35:40 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9IAZVjW015824 for <rbridge@postel.org>; Tue, 18 Oct 2005 12:35:31 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9IAZUV3014521 for <rbridge@postel.org>; Tue, 18 Oct 2005 12:35:31 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Oct 2005 12:35:30 +0200 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="iso-8859-1" Date: Tue, 18 Oct 2005 12:35:29 +0200 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CEBA9@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] MAN scale and future uses of Rbridge Thread-Index: AcXTq/dr8uOTWj9HS7WfqystiTNV8gAI1J8w From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 18 Oct 2005 10:35:30.0508 (UTC) FILETIME=[A97BC8C0:01C5D3CF] 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 j9IAZeL11406 Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 18 Oct 2005 10:37:02 -0000 Status: RO Content-Length: 1370 Guillermo, > > -Regarding scalability problem of high number of flat MAC > addresses in > the MAN, > There is no such problem, provided each campus network > uses routers > to participate in the MAN. In this case the only MAC addresses to be > handled by the > Rbridges are the MACs of the routers used to accesss the > MAN.(See Link > State Over MAC, Garc?a and Duato 2003 proposal for such an example) > - Another aspect to analyze consider in the MAN environment is the > interoperability with provider bridges (.1ad .1ah) and their > encapsulations. > Guillermo There is no such problem, if you consider that the operators will configure things properly. In other words, if the proper traffic-engineering solutions apply. In any case. We are not here (I believe) discussing such operator issues...the fact is that if Rbridges are to be applied within a campus then the simplest (but non-optimal) solution applies. However, if this is to be scaled to the MAN (and here I am considering the aggregation area) then there are other implications that must be considered from the mechanism perspective. In other words, the flooding provided by IS-IS is a great idea and gives plenty of flexibility to develop new, better than ST ideas. If this is to be extended, my 2cents on this is that the issues mentioned before are worth checking. Regards, Rute 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 j9I6InL13673 for <rbridge@postel.org>; Mon, 17 Oct 2005 23:18:49 -0700 (PDT) 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 <0IOJ00MCZLJ8ZK00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 23:18:44 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOJ00MV4LJ6YW00@mail.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 23:18:44 -0700 (PDT) Date: Mon, 17 Oct 2005 23:18:48 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B405213D1A@zcarhxm2.corp.nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435493C8.1050807@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: <713043CE8B8E1348AF3C546DBE02C1B405213D1A@zcarhxm2.corp.nortel.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] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 06:19:42 -0000 Status: RO Content-Length: 5861 One nit, on terminology... Just making sure that someone who has recently studied "minimum spanning trees" doesn't get confused by your explanation, Peter. You're not wrong, but the terminology "minimum spanning tree" usually refers to something different than what you're talking about... something where the total cost of all the links in the tree is minimum. STP (and Dijkstra) do not compute minimum spanning trees. For instance, if you had a Root R, with 3 links coming off it, attached to R1, R2, and R3, respectively, with the cost of all those links being 10, and a link between R1 and R2 of cost 1, then STP and Disjkstra would compute the tree consisting of R and its attached links. That tree would have a total weight (add the link costs) of 30. The minimum spanning tree would instead connect R2 to R1, so the total weight would be 21. STP (and Disjkstra) instead compute a tree of shortest paths from the root. They wouldn't attach R2 to R1 because then the path from root to R2 would be 11 rather than 10 if R2 was attached to the Root. Anyway...just for future reference on the term "minimum spanning tree"... ****** And now for more explanation...there's really nothing optimal about the tree computed by STP. Any single shared tree will be good for some S-D pairs, and bad for others. The tree created by hopping across bridged islands won't be any more or less optimal than if there were a giant spanning tree across the entire campus, where we went to some effort to ensure the combination of RBridges and bridges computed the same tree as they would have if everyone were bridges. Plus...RBridges aren't computing a single tree anyway...they are computing per-ingress-RBridge trees. As I've said before, we really want to terminate the bridged islands, and then have RBridges just see each bridged island as a single link. Radia Peter Ashwood-Smith wrote: >>Here's the counterexample: >> >>Have existing bridges BLOCK. >> >> > > Thats not really a counter example but let me try to explain >where you are getting confused below. > > > >>Assume each bridge computes its own spanning tree internally >>(i.e., between its own ports on its own device), and sends >>coded 'hellos' that it it recognizes if they loop, i.e., all >>the thinks a campus would do. >> >> > > Because it would not be a MINIMUM spanning tree. However, yes, if you >repeatedly connect a set of node disjoint trees together with a single >link, reducing the number of trees by one each time, the result is a >tree. This I think is what you are suggesting and yes, I believe >an algorithm like this does actually make a tree. The catch is that it >is NOT a minimum spanning tree and you cannot easily select a root. >STP produces a minimum spanning tree rooted where you want it so >you get much more with the STP protocol than just the hello/detect/block >idea. STP requires its BPDUs to flood through the network to elect >the root and compute paths to it and rbridge requires link state to >flood link information so it can compute the minium spanning tree. >Both protocols need to know about ALL the possible paths in their >domains to minimize the resulting tree. >The DR mechanism is only used to prevent a loop between these two >domains but it does not by itself guarantee that the combination of >the two trees is still minimum. Therefore, the DR mechanism if applied >by itself as you suggest does produce a tree but it is not minimum and >you >have no control over the root that is selected. > > Rbridge of course only uses this DR mechanism at the interface between >itself and some other domain (STP or manually configured), and so >you end up with a minimum spanning tree in STP and a minimum spanning >tree in the rbridge >domain but the combination of the two is not necessarily the best >possible >since neither minimization was done over the complete set of links/nodes >available. This makes sense because if you take two minimum solutions >over disjoint sets you cannot simply add them together to produce a >global minimum solution. For example, I cannot take a shortest path from >some node S to an intermediate E and a shortest path from E to D, add >them together and >get the shortest path from S to D because there may be a much better E! > > > >>Now if that works, let's do it for bridges and then we >>wouldn't have a spanning tree convergence problem at all, right? >> >> > > It produces a tree but not a minimum spanning tree with no control >over >the root. So its not quite the 'work' you had in mind and this in a nut >shell is I believe your mistake. > > > >>If that does NOT work, then why does it work for rbridge >>campuses and not bridges? >> >> > > It does work its just that we want minimum spanning trees and >to do that we need information about all the nodes we can reach. >STP gets this by flooding BPDUSs and Rbridges by link state updates. >Take away the BPUDS and you can't get minimum. Rbridges can take >the BPDU away [BLOCk] because it does its own minimum and combines the >results with DR to produce a possibly non global minimum solution but >that is the price you pay for neither side seeing all the data. > > > >>My general test is "an rbridge campus needs to look like a >>bridge" or "look like a link". If it does, then I know I >>understand it. When it doesn't, it would be useful to >>understand whether this is really a 'new animal' and exactly >>why it's newness is unique to rbridges (i.e., why it can't be >>applied as well to bridges). >> >> > > I think you need to think of this as a new animal as Radia suggested. > > Hope this helps. > > Peter > > > > > >>Joe >> >> >> >_______________________________________________ >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 j9I68HL11258 for <rbridge@postel.org>; Mon, 17 Oct 2005 23:08:18 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5320B9D255 for <rbridge@postel.org>; Tue, 18 Oct 2005 08:08:10 +0200 (CEST) Received: from [163.117.203.234] (unknown [163.117.203.234]) by smtp01.uc3m.es (Postfix) with ESMTP id DB3679D27E for <rbridge@postel.org>; Tue, 18 Oct 2005 08:08:08 +0200 (CEST) Message-ID: <43549149.5090100@it.uc3m.es> Date: Tue, 18 Oct 2005 08:08:09 +0200 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: <ECDC9C7BC7809340842C0E7FCF48C3937CEBA2@MCHP7IEA.ww002.siemens.net> In-Reply-To: <ECDC9C7BC7809340842C0E7FCF48C3937CEBA2@MCHP7IEA.ww002.siemens.net> 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] MAN scale and future uses of Rbridge 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, 18 Oct 2005 06:08:29 -0000 Status: RO Content-Length: 3315 -Regarding scalability problem of high number of flat MAC addresses in the MAN, There is no such problem, provided each campus network uses routers to participate in the MAN. In this case the only MAC addresses to be handled by the Rbridges are the MACs of the routers used to accesss the MAN.(See Link State Over MAC, Garc?a and Duato 2003 proposal for such an example) - Another aspect to analyze consider in the MAN environment is the interoperability with provider bridges (.1ad .1ah) and their encapsulations. Guillermo Sofia, Rute wrote: >> This is one reason for the dominance of OSPF over RIP at L3. >> >> Shortest paths are of course of interest in the MAN but >>other reasons >>why Rbridge is attractive in the MAN consist of future uses >>of its link >>state topology. In particular as Alia pointed out, RAPID >>style rerouting >>(loop free alternates) is possible. Also the link state topology is >>useful for constraint based routing. So let's not rule out >>larger scale >>in the future, especially since this is where Rbridge will >>really shine. >> >> >> >Besides the fact that having "all" the topology at hand provides greater >flexibility to decide on how to forward information, scalability issues >concerning Rbridges imply more than just the forwarding algorithm of >choice. > > Considering Rbridges application from a MAN scope, other scalability >issues relate to: >- storage cost (the price of flat addressing and of having every >Rbridge learning both requested and unrequested MAC destination >addresses) may be decreased, but is something that has not be considered >up until now, given that the scope is limited to a campus... > >- backward compatibility issues currently being discussed (i.e., whether >to have Rbridges as termination of STs). If the use of Rbridges within >the MAN is not to be disregarded, then there is a cost related to having >Rbridges interworking with legacy bridges. By not allowing Rbridges to >intervene in the ST (using BLOCK) then the Rbridge placement must be >carefully chosen, or performance will degrade. > >- scalability due to broadcasts. As Saikat stated, there are better >approaches to treat broadcasts and not really requiring much more >computational power (given that all the information is local) > >- scalability related to the IS-IS tuning. On this point, (I am not >completely sure about the price but...), there is a price to pay to tune >IS-IS in order to achieve convergence in the order of hundreds of >seconds. This is another issue to be checked. > >Summing up, these are issues to be considered *if* Rbridges is to be >extended to something larger than a campus. But going back to the >participate vs. non-participate in the ST issue, then the scope is >something that may help in deciding this issue. As I said, I do not see >that Rbridges need to intervene *if* the scope is limited to a campus. >Why? Because as stated in Radia's paper, Rbridges can simply terminate >STs, which makes all the sense given that a Rbridge is a hybrid router. >But this scenario does not seem to make the same sense, if a MAN scope >is considered... > > > > >Regards, >Rute >_______________________________________________ >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 j9I5xHL08815 for <rbridge@postel.org>; Mon, 17 Oct 2005 22:59:17 -0700 (PDT) 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 <0IOJ00MCLKMLZK00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 22:59:09 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOJ00MUMKM6YW00@mail.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 22:59:07 -0700 (PDT) Date: Mon, 17 Oct 2005 22:58:59 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <43546833.8090301@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43548F23.3040909@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <28f32dda66a3.435355f5@sunlabs.com> <43546833.8090301@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: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 05:59:34 -0000 Status: RO Content-Length: 2149 I'm sorry, but I don't understand your example (in a different email), and don't understand why you think isolating bridges into islands that create the illusion, to RBridges, of a single link can be a problem. And I don't see why having RBridges as a layer above the bridges isn't the same as routers being a layer above bridges. And I can't think of a way of explaining it any differently. Perhaps somoene else can try, or perhaps I can talk to you by phone sometime. But I'm travelling again. Radia Joe Touch wrote: >Radia.Perlman@sun.com wrote: > > >>It works perfectly well if RBridges block. It isolates the bridge islands. >> >>Routers also block bridge spanning tree, and to exactly the same >>effect as if RBridges block BPDUs. >> >> > >This isn't the same at all; I keep hearing the analogy, but it fails >under all tests: > > first, there are NO routers on an L2 net > > all sources/sinks are the same (called nodes AFAICT) > and hosts and routers are just nodes, > identical as far as L2 is concerned > > nodes block all BPDUs (we agree), but > nodes also block broadcast (rbridges don't) > >Near as I can tell, L2 has exactly three devices currently: > > nodes > > links > > bridges (participate in SPT, interpret BPDUs) > >Bridges don't 'block' BPDUs, but they don't forward them to all ports >either. > >Now, an rbridge can be "like" a node, a link, or a bridge and still play >in the existing L2 specs. If it isn't 'like' any of those, then we're >changing the definition of 802, and I didn't think that was the goal here. > >rbridges - at least to nodes on the L2 - are NOT 'like' hosts, since >they don't source or sink L2 traffic to existing nodes > >rbridges could be 'like' links if they are TRANSPARENT > >rbridges could be 'like' bridges if the PARTICIPATE > >What exactly are rbridges 'like' if they BLOCK? > >They can't be 'like' routers - there are no routers in L2. > >?? > >Joe > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9I5eRL04771 for <rbridge@postel.org>; Mon, 17 Oct 2005 22:40:28 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9I5bfF07844 for <rbridge@postel.org>; Tue, 18 Oct 2005 01:37:42 -0400 (EDT) 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: Tue, 18 Oct 2005 01:40:17 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D1A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTk7AufKaB1RmLTiqXKCrVe8tTnQAC6dGg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9I5eRL04771 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 05:41:27 -0000 Status: RO Content-Length: 3664 > Here's the counterexample: > > Have existing bridges BLOCK. Thats not really a counter example but let me try to explain where you are getting confused below. > Assume each bridge computes its own spanning tree internally > (i.e., between its own ports on its own device), and sends > coded 'hellos' that it it recognizes if they loop, i.e., all > the thinks a campus would do. Because it would not be a MINIMUM spanning tree. However, yes, if you repeatedly connect a set of node disjoint trees together with a single link, reducing the number of trees by one each time, the result is a tree. This I think is what you are suggesting and yes, I believe an algorithm like this does actually make a tree. The catch is that it is NOT a minimum spanning tree and you cannot easily select a root. STP produces a minimum spanning tree rooted where you want it so you get much more with the STP protocol than just the hello/detect/block idea. STP requires its BPDUs to flood through the network to elect the root and compute paths to it and rbridge requires link state to flood link information so it can compute the minium spanning tree. Both protocols need to know about ALL the possible paths in their domains to minimize the resulting tree. The DR mechanism is only used to prevent a loop between these two domains but it does not by itself guarantee that the combination of the two trees is still minimum. Therefore, the DR mechanism if applied by itself as you suggest does produce a tree but it is not minimum and you have no control over the root that is selected. Rbridge of course only uses this DR mechanism at the interface between itself and some other domain (STP or manually configured), and so you end up with a minimum spanning tree in STP and a minimum spanning tree in the rbridge domain but the combination of the two is not necessarily the best possible since neither minimization was done over the complete set of links/nodes available. This makes sense because if you take two minimum solutions over disjoint sets you cannot simply add them together to produce a global minimum solution. For example, I cannot take a shortest path from some node S to an intermediate E and a shortest path from E to D, add them together and get the shortest path from S to D because there may be a much better E! > Now if that works, let's do it for bridges and then we > wouldn't have a spanning tree convergence problem at all, right? It produces a tree but not a minimum spanning tree with no control over the root. So its not quite the 'work' you had in mind and this in a nut shell is I believe your mistake. > If that does NOT work, then why does it work for rbridge > campuses and not bridges? It does work its just that we want minimum spanning trees and to do that we need information about all the nodes we can reach. STP gets this by flooding BPDUSs and Rbridges by link state updates. Take away the BPUDS and you can't get minimum. Rbridges can take the BPDU away [BLOCk] because it does its own minimum and combines the results with DR to produce a possibly non global minimum solution but that is the price you pay for neither side seeing all the data. > My general test is "an rbridge campus needs to look like a > bridge" or "look like a link". If it does, then I know I > understand it. When it doesn't, it would be useful to > understand whether this is really a 'new animal' and exactly > why it's newness is unique to rbridges (i.e., why it can't be > applied as well to bridges). I think you need to think of this as a new animal as Radia suggested. Hope this helps. Peter > > Joe > Received: from localhost ([141.150.193.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j9I3KqL01347 for <rbridge@postel.org>; Mon, 17 Oct 2005 20:20:52 -0700 (PDT) Received: from [10.71.9.70] ([10.71.9.70]) by localhost 0.5.5 with ESMTP id 0CFC43546A070000 Mon Oct 17 22:20:39 2005 Message-ID: <43546A07.1010703@isi.edu> Date: Mon, 17 Oct 2005 20:20:39 -0700 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: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <200510171521.j9HFLgLZ010230@lion.seas.upenn.edu> In-Reply-To: <200510171521.j9HFLgLZ010230@lion.seas.upenn.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2BCAA69D061094D597EE81B5" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 03:21:30 -0000 Status: RO Content-Length: 1951 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2BCAA69D061094D597EE81B5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > Now you can have an rbridge and an sbridge in the same L2 (how do you > know you don't?). They form an undetectable, uncorrectable loop. > > > [Saikat] I do not see how this happens. First I am assuming that if > "sbridges" are connected by physical links, then they know how to avoid > packet loops by some mechanism they choose to implement. Now, as far as > "sbridges" are concerned, the network consisting of RBridges, STP-running > bridges, physical links etc., is simply a "link". In other words, the entire > network (consisting of RBridges, STP-running bridges, physical links etc.) > could be replaced by a physical link. Thus even in this case, there would be > no packet loop in the steady state. > > Another way of looking at this argument is the following. Suppose you remove > all the RBridges from the network. sBridges and legacy bridges are left, and > the assumption is that in that case, at least, a loop-free network results. > Then when you add RBridges (in their original position), the rest of the > network is simply one or more "link"s, and RBridges would ensure that there > would be no loops. Except that the rbridges add a 'link' between themselves - that's the extra 'link' that can cause the loop. Joe --------------enig2BCAA69D061094D597EE81B5 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDVGoHE5f5cImnZrsRApnhAJ9SVSD4bJ6z9aGzZnkE3zhb8eyHiACeOCwj 5mNdnIvxDNGPo631TqHzgQk= =EjWx -----END PGP SIGNATURE----- --------------enig2BCAA69D061094D597EE81B5-- Received: from localhost ([141.150.193.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j9I3IeL00863 for <rbridge@postel.org>; Mon, 17 Oct 2005 20:18:40 -0700 (PDT) Received: from [10.71.9.70] ([10.71.9.70]) by localhost 0.5.5 with ESMTP id 0BE94354698A0000 Mon Oct 17 22:18:34 2005 Message-ID: <4354698B.1010503@isi.edu> Date: Mon, 17 Oct 2005 20:18:35 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213D08@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213D08@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig72C05E9D880157C133FFA156" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 03:19:28 -0000 Status: RO Content-Length: 2913 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig72C05E9D880157C133FFA156 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: >>> Also, the 'problems' that people are attributing to >> >>blocking and not >> >>>processing BPDUs [BLOCK] are also 'problems' when no STP is running. >> >>'problems'? (why the quotes?) > > > Because I don't see them and did not want people to think I did. > > >>OK, let's just shut off spanning tree in bridges and it all >>works just fine now? >> >>Now I'm *really* confused. > > > Sorry, my explaination was not very clear. I was simply pointing out > that > the Rbridge DR mechanism avoids loops independently of the STP protocol. > Therefore, if there are no loops PRIOR to the introduction of the > rbridges > and their interconnections, but there is a loop AFTER their introduction > the > rbridges will detect and prevent it. In otherwords they detect and > prevent > loops for which they are responsible. > > >>If we want to say "BLOCK *MAY* work, but *MAY* silently >>fail", and "PARTICIPATE and TRANSPARENT will always work with >>current standards", that's fine (and, AFAICT, true), but I >>also don't see how we pick BLOCK as a default in that case. > > > I'd like to see the example of BLOCK failing and by failing I > mean a permanent loop uncorrected by either STP or Rbridge. Personally > I don't think this exists because the simple 'proof' of interconnecting > two > trees with a single link still being a tree seems pretty air tight to > me! Here's the counterexample: Have existing bridges BLOCK. Assume each bridge computes its own spanning tree internally (i.e., between its own ports on its own device), and sends coded 'hellos' that it it recognizes if they loop, i.e., all the thinks a campus would do. Now if that works, let's do it for bridges and then we wouldn't have a spanning tree convergence problem at all, right? If that does NOT work, then why does it work for rbridge campuses and not bridges? My general test is "an rbridge campus needs to look like a bridge" or "look like a link". If it does, then I know I understand it. When it doesn't, it would be useful to understand whether this is really a 'new animal' and exactly why it's newness is unique to rbridges (i.e., why it can't be applied as well to bridges). Joe --------------enig72C05E9D880157C133FFA156 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDVGmLE5f5cImnZrsRAp7XAKDtcimZ8U/1unz3ww6YULbFz/U18QCgk4sc NYWKHwn8DkBQY/RjbivLYFI= =40fZ -----END PGP SIGNATURE----- --------------enig72C05E9D880157C133FFA156-- Received: from localhost ([141.150.193.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j9I3D0L29427 for <rbridge@postel.org>; Mon, 17 Oct 2005 20:13:00 -0700 (PDT) Received: from [10.71.9.70] ([10.71.9.70]) by localhost 0.5.5 with ESMTP id 07FD435468360000 Mon Oct 17 22:12:55 2005 Message-ID: <43546833.8090301@isi.edu> Date: Mon, 17 Oct 2005 20:12:51 -0700 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> References: <28f32dda66a3.435355f5@sunlabs.com> In-Reply-To: <28f32dda66a3.435355f5@sunlabs.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig127E5339470D5D364382FE92" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 18 Oct 2005 03:13:57 -0000 Status: RO Content-Length: 2028 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig127E5339470D5D364382FE92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Radia.Perlman@sun.com wrote: > It works perfectly well if RBridges block. It isolates the bridge islands. > > Routers also block bridge spanning tree, and to exactly the same > effect as if RBridges block BPDUs. This isn't the same at all; I keep hearing the analogy, but it fails under all tests: first, there are NO routers on an L2 net all sources/sinks are the same (called nodes AFAICT) and hosts and routers are just nodes, identical as far as L2 is concerned nodes block all BPDUs (we agree), but nodes also block broadcast (rbridges don't) Near as I can tell, L2 has exactly three devices currently: nodes links bridges (participate in SPT, interpret BPDUs) Bridges don't 'block' BPDUs, but they don't forward them to all ports either. Now, an rbridge can be "like" a node, a link, or a bridge and still play in the existing L2 specs. If it isn't 'like' any of those, then we're changing the definition of 802, and I didn't think that was the goal here. rbridges - at least to nodes on the L2 - are NOT 'like' hosts, since they don't source or sink L2 traffic to existing nodes rbridges could be 'like' links if they are TRANSPARENT rbridges could be 'like' bridges if the PARTICIPATE What exactly are rbridges 'like' if they BLOCK? They can't be 'like' routers - there are no routers in L2. ?? Joe --------------enig127E5339470D5D364382FE92 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDVGg3E5f5cImnZrsRAj+WAKCCxAUiAu1HzBNTo2Qxychh1XTKDQCfWWfK xDv56iELyRL3nI+dN7OjRXs= =HSgy -----END PGP SIGNATURE----- --------------enig127E5339470D5D364382FE92-- 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 j9HKxiL17806 for <rbridge@postel.org>; Mon, 17 Oct 2005 13:59:44 -0700 (PDT) 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 <0IOI00M2SVNFZL00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 13:59:39 -0700 (PDT) Received: from sun.com ([129.150.27.68]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOI00MBCVNFYT00@mail.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 13:59:39 -0700 (PDT) Date: Mon, 17 Oct 2005 13:59:45 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <200510171227.j9HCRbtc002747@lion.seas.upenn.edu> To: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435410C1.6090105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <200510171227.j9HCRbtc002747@lion.seas.upenn.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: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 21:00:31 -0000 Status: RO Content-Length: 3528 And actually, people seemed to want to compute a per-ingress RBridge spanning tree. The ingress RBridge will be in the shim header. So there is no problem with the root of the tree changing, since they are not calculating a single tree. The reasons for computing different trees (using the link state database) for each ingress RBridge are, if I recall: a) more optimized VLAN broadcast domain (if only a few links are in VLAN A, might as well have shortest paths between those links, rather than a single spanning tree, which might cause a very long path between two VLAN A links b) more optimized IP multicast paths, when there are not receivers on many links (if there are receivers on most of the links, having a per-ingress tree isn't that useful) c) avoiding getting packets out of order when S starts talking to D, and ingress RBridge R1 does not yet know the location of D. Using a per-ingress RBridge tree, the packets will take the same path whether R1 knows where D is or not. Radia Saikat Ray wrote: >You do not even need a ?root? really! Each RBridge has the *global* >topology. They can simply each run Kruskal's algorithm and compute the (nee >*a*) minimum weight spanning tree (which is probably the right thing to do >anyway for broadcast purposes). > >________________________________________ >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Vishwas Manral >Sent: Monday, October 17, 2005 7:27 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] Treating broadcast addresses > >Hi Rute, > >Would this also mean Root-Election? What about convergence of this tree? > >Thanks, >Vishwas >________________________________________ >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Sofia, Rute >Sent: Monday, October 17, 2005 4:36 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] Treating broadcast addresses > >Vishwas, > >based on the information exchanged by LSPs you can simply compute the ST >locally. The key here is the choice of the root. This can also be passed >along by IS-IS... > >Regards, >Rute > >Hi, > >My question is more like, how would we build a spanning tree for broadcast >using IS-IS? > >We need a globally coordinated tree like STP and not like the way IS-IS >computes it. Would we require, changes to the spanning tree computation >itself? > >Thanks, >Vishwas >________________________________________ >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Vishwas Manral >Sent: Monday, October 17, 2005 11:41 AM >To: Developing a hybrid router/bridge. >Subject: [rbridge] Treating broadcast addresses > >Hi, > >I had a doubt about treatment of broadcast addresses. > >Currently using STP we have one tree and ports are blocked/ forwarding, so >packets cannot loop irrespective of destination addresses. In IS-IS >protocol, we use ports based on destination address and no ports are blocked >or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could >end in a forwarding loop. How would we get over it? > >Would we still allow broadcast destination address packets to be forwarded? >It is like preventing flooding loops in a case where we have a global >broadcast IP address, which is forwarded to all attached routers. Am I >missing the point all together? > >Thanks, >Vishwas > > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HJoXL25909 for <rbridge@postel.org>; Mon, 17 Oct 2005 12:50:33 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9HJoPa18667 for <rbridge@postel.org>; Mon, 17 Oct 2005 15:50:25 -0400 (EDT) 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_01C5D353.FFE37CC6" Date: Mon, 17 Oct 2005 15:50:17 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D16@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] MAN scale and future uses of Rbridge Thread-Index: AcXTTi5bgDteH7yKRqSPGxayMlBomQAAQ9Qg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 17 Oct 2005 19:52:08 -0000 Status: RO Content-Length: 14653 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D353.FFE37CC6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is perhaps hope for higher rates of change and/or large scale for flat addresses spaces. The query routing stuff (P2P networking) in particular looks promising. Who knows perhaps it can be applied at L2 in the future. =20 What is 'large enough'? Well increased scale is not necessarily to be used for larger deployments. An increase in scalability has other more important (IMHO) benefits. In particular if something can scale well beyond the deployment scenarios it will be much more stable at the sizes more commonly deployed. In other words you are not at the edge of your operating envelope .. you are safely somewhere in the middle with lots of head room. You can safely change/grow and shrink without worrying about stability (and can survive spikes such as earthquakes, hurricanes and ice storms). Anyway, once you increase the possible scale, the next question of how many routers v.s rbridges is more one of functionality. The rbridge won't be able to move further out until it has enough features to take a bite out of its attached routers .. hopefully it can do that while staying cheaper but at the moment its going to run out of features before it runs out of scaling oompf. Anyway that's a long winded way of saying ... beats me ;) =20 =20 Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Alia Atlas Sent: Monday, October 17, 2005 3:02 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] MAN scale and future uses of Rbridge =09 =09 On 10/17/05, Peter Ashwood-Smith <petera@nortel.com> wrote:=20 =09 I think the main impediment to very large scale is the large flat address space and its rate of change. Not the number or Rbridge nodes and networks/links. While use of IS-IS or OSPF areas can help when addressing is hierarchical, they are not going to help much when you cannot aggregate the addresses into specific areas. There are environments where the rate of change could be reasonably bounded, so that brings it back to the flat address space... =09 Then again I don't think that Rbridge needs to scale that large to be enormously useful. If it pushes the attainable size out a bit, gives better routes, is more stable and allows future innovations based on the topology it is going to be very useful. After that .. well its routers all the way down ;) What do you think is large enough? (I remember the discussion earlier, but not specific numbers.) =09 Alia=20 =09 =09 Peter=20 =09 -----Original Message----- From: rbridge-bounces@postel.org [mailto: rbridge-bounces@postel.org <mailto:rbridge-bounces@postel.org> ] On Behalf Of Alia Atlas Sent: Monday, October 17, 2005 2:37 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] MAN scale and future uses of Rbridge =09 =09 On 10/17/05, Sofia, Rute <rute.sofia@siemens.com> wrote:=20 Considering Rbridges application from a MAN scope, other scalability issues relate to: - storage cost (the price of flat addressing and of having every Rbridge learning both requested and unrequested MAC destination=20 addresses) may be decreased, but is something that has not be considered up until now, given that the scope is limited to a campus... What number of MAC addresses is the target for the rbridge campus? Do you think the constraints are on the memory or on the notifications required due to changes?=20 =09 =09 - scalability related to the IS-IS tuning. On this point, (I am not completely sure about the price but...), there is a price to pay to tune=20 IS-IS in order to achieve convergence in the order of hundreds of seconds. This is another issue to be checked. Is there a reason that different areas couldn't be used in the IS-IS instance for rbridges? Do you think this would be adequate? Are the topological restrictions (i.e. hub and spoke) acceptable? Could we work around that? =09 Summing up, these are issues to be considered *if* Rbridges is to be extended to something larger than a campus. But going back to the=20 participate vs. non-participate in the ST issue, then the scope is something that may help in deciding this issue. As I said, I do not see that Rbridges need to intervene *if* the scope is limited to a campus. Why? Because as stated in Radia's paper, Rbridges can simply terminate STs, which makes all the sense given that a Rbridge is a hybrid router. But this scenario does not seem to make the same sense, if a MAN scope is considered... =09 While improving the scalability may not be immediately in scope, I think it is worthwhile to consider where the restrictions are coming from. =09 Alia =09 _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge =09 =09 =09 =09 ------_=_NextPart_001_01C5D353.FFE37CC6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN><SPAN class=3D058141619-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>There is perhaps hope for higher rates of = change and/or=20 large scale for flat addresses spaces. The query routing stuff (P2P = networking)=20 in particular looks promising. Who knows perhaps it can be applied at L2 = in the=20 future.</FONT></SPAN></DIV> <DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff = size=3D2>What=20 is 'large enough'? Well increased scale is not necessarily to be used = for larger=20 deployments. An increase in scalability has other more important (IMHO)=20 benefits. In particular if something can scale well beyond the = deployment=20 scenarios it will be much more stable at the sizes more commonly = deployed. In=20 other words you are not at the edge of your operating = envelope .. you=20 are safely somewhere in the middle with lots of head room. You can = safely=20 change/grow and shrink without worrying about stability (and can survive = spikes=20 such as earthquakes, hurricanes and ice storms). Anyway, once you = increase the=20 possible scale, the next question of how many routers v.s rbridges is = more one=20 of functionality. The rbridge won't be able to move further out until it = has=20 enough features to take a bite out of its attached routers .. hopefully = it can=20 do that while staying cheaper but at the moment its going to run out of = features=20 before it runs out of scaling oompf. Anyway that's a long winded way of = saying=20 ... beats me ;)</FONT></SPAN></DIV> <DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff = size=3D2>Peter</FONT></SPAN></DIV> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20 rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <B>On = Behalf Of=20 </B>Alia Atlas<BR><B>Sent:</B> Monday, October 17, 2005 3:02 = PM<BR><B>To:</B>=20 Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] = MAN scale=20 and future uses of Rbridge<BR><BR></FONT></DIV>On 10/17/05, <B=20 class=3Dgmail_sendername>Peter Ashwood-Smith</B> <<A=20 href=3D"mailto:petera@nortel.com">petera@nortel.com</A>> wrote: <DIV><SPAN class=3Dgmail_quote></SPAN> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid"> <DIV><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>I think the = main impediment=20 to very large scale is the large flat address space and its rate of = change.=20 Not the number or Rbridge nodes and networks/links. While use = of IS-IS=20 or OSPF areas can help when addressing is hierarchical, they are not = going=20 to help much when you cannot aggregate the addresses into specific=20 areas.</FONT></SPAN></DIV></BLOCKQUOTE> <DIV><BR>There are environments where the rate of change could be = reasonably=20 bounded, so that brings it back to the flat address = space...<BR></DIV><BR> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid"> <DIV><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>Then again I = don't think=20 that Rbridge needs to scale that large to be enormously useful. If = it pushes=20 the attainable size out a bit, gives better routes, is more = stable and=20 allows future innovations based on the topology it is going to be = very=20 useful. After that .. well its routers all the way down=20 ;)</FONT></SPAN></DIV></BLOCKQUOTE> <DIV><BR>What do you think is large enough? (I remember the = discussion=20 earlier, but not specific numbers.)<BR><BR>Alia <BR></DIV><BR> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid"><SPAN=20 class=3Dsg> <DIV><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>Peter</FONT>=20 </SPAN></DIV></SPAN> <DIV><SPAN class=3De id=3Dq_106ffefd56937552_2> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: = rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV lang=3Den-us dir=3Dltr align=3Dleft><FONT face=3DTahoma = size=3D2>-----Original=20 Message-----<BR><B>From:</B> <A=20 onclick=3D"return top.js.OpenExtLink(window,event,this)"=20 href=3D"mailto:rbridge-bounces@postel.org"=20 target=3D_blank>rbridge-bounces@postel.org</A> [mailto:<A=20 onclick=3D"return top.js.OpenExtLink(window,event,this)"=20 href=3D"mailto:rbridge-bounces@postel.org" target=3D_blank>=20 rbridge-bounces@postel.org</A>] <B>On Behalf Of </B>Alia=20 Atlas<BR><B>Sent:</B> Monday, October 17, 2005 2:37 = PM<BR><B>To:</B>=20 Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: = [rbridge] MAN=20 scale and future uses of Rbridge<BR><BR></FONT></DIV><BR><BR> <DIV><SPAN class=3Dgmail_quote>On 10/17/05, <B = class=3Dgmail_sendername>Sofia,=20 Rute</B> <<A onclick=3D"return = top.js.OpenExtLink(window,event,this)"=20 href=3D"mailto:rute.sofia@siemens.com"=20 target=3D_blank>rute.sofia@siemens.com</A>> wrote:</SPAN>=20 <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; = BORDER-LEFT: rgb(204,204,204) 1px solid">Considering=20 Rbridges application from a MAN scope, other = scalability<BR>issues=20 relate to:<BR>- storage cost (the price of flat = addressing=20 and of having every<BR>Rbridge learning both requested and = unrequested=20 MAC destination <BR>addresses) may be decreased, but is = something that=20 has not be considered<BR>up until now, given that the scope is = limited=20 to a campus...</BLOCKQUOTE> <DIV><BR> What number of MAC addresses is the target for the = rbridge=20 campus? Do you<BR>think the constraints are on the = memory or=20 on the notifications required due to changes? <BR><BR></DIV> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; = BORDER-LEFT: rgb(204,204,204) 1px solid">-=20 scalability related to the IS-IS tuning. On this point, (I am=20 not<BR>completely sure about the price but...), there is a price = to pay=20 to tune <BR>IS-IS in order to achieve convergence in the order = of=20 hundreds of<BR>seconds. This is another issue to be = checked.</BLOCKQUOTE> <DIV><BR>Is there a reason that different areas couldn't be used = in the=20 IS-IS instance for rbridges?<BR>Do you think this would be = adequate? =20 Are the topological restrictions (i.e. hub and = spoke)<BR>acceptable? =20 Could we work around that?<BR></DIV><BR> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; = BORDER-LEFT: rgb(204,204,204) 1px solid">Summing=20 up, these are issues to be considered *if* Rbridges is to = be<BR>extended=20 to something larger than a campus. But going back to the = <BR>participate=20 vs. non-participate in the ST issue, then the scope = is<BR>something that=20 may help in deciding this issue. As I said, I do not see<BR>that = Rbridges need to intervene *if* the scope is limited to a=20 campus.<BR>Why? Because as stated in Radia's paper, Rbridges can = simply=20 terminate<BR>STs, which makes all the sense given that a Rbridge = is a=20 hybrid router.<BR>But this scenario does not seem to make the = same=20 sense, if a MAN scope<BR>is = considered...<BR></BLOCKQUOTE></DIV><BR>While=20 improving the scalability may not be immediately in scope, I think = it=20 is<BR>worthwhile to consider where the restrictions are coming=20 = from.<BR><BR>Alia<BR></BLOCKQUOTE></SPAN></DIV><BR>______________________= _________________________<BR>rbridge=20 mailing list<BR><A onclick=3D"return = top.js.OpenExtLink(window,event,this)"=20 href=3D"mailto:rbridge@postel.org">rbridge@postel.org</A><BR><A=20 onclick=3D"return top.js.OpenExtLink(window,event,this)"=20 href=3D"http://www.postel.org/mailman/listinfo/rbridge"=20 = target=3D_blank>http://www.postel.org/mailman/listinfo/rbridge</A><BR><BR= ><BR><BR=20 clear=3Dall></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML> =00 ------_=_NextPart_001_01C5D353.FFE37CC6-- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HJ1oL11012 for <rbridge@postel.org>; Mon, 17 Oct 2005 12:01:50 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 36so464269wra for <rbridge@postel.org>; Mon, 17 Oct 2005 12:01:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=qoDhuax+2lyefgKJjhKL5X5QanYJIgHxyXIlrFqoi86M7cr4Xk6gRCD1UB8Snnuyu1aetBZ+U23nBru2dY1oFCNtRqfLMLEptA3PElh+hDyybgeLHFWuUIZrXjeJRR2dknHfCdu51ykfYdxW/M1gKOtN6CJ6q8FYNHNn9qkEHaY= Received: by 10.54.139.18 with SMTP id m18mr1954195wrd; Mon, 17 Oct 2005 12:01:49 -0700 (PDT) Received: by 10.54.148.1 with HTTP; Mon, 17 Oct 2005 12:01:49 -0700 (PDT) Message-ID: <6280db520510171201g78df2840i342ce86ff8f5fc65@mail.gmail.com> Date: Mon, 17 Oct 2005 12:01:49 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213D14@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20407_136698.1129575709588" References: <713043CE8B8E1348AF3C546DBE02C1B405213D14@zcarhxm2.corp.nortel.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 17 Oct 2005 19:02:43 -0000 Status: RO Content-Length: 9728 ------=_Part_20407_136698.1129575709588 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/17/05, Peter Ashwood-Smith <petera@nortel.com> wrote: > > I think the main impediment to very large scale is the large flat address > space and its rate of change. Not the number or Rbridge nodes and > networks/links. While use of IS-IS or OSPF areas can help when addressing= is > hierarchical, they are not going to help much when you cannot aggregate t= he > addresses into specific areas. > There are environments where the rate of change could be reasonably bounded= , so that brings it back to the flat address space... Then again I don't think that Rbridge needs to scale that large to be > enormously useful. If it pushes the attainable size out a bit, gives bett= er > routes, is more stable and allows future innovations based on the topolog= y > it is going to be very useful. After that .. well its routers all the way > down ;) > What do you think is large enough? (I remember the discussion earlier, but not specific numbers.) Alia Peter > > -----Original Message----- > *From:* rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] *O= n > Behalf Of *Alia Atlas > *Sent:* Monday, October 17, 2005 2:37 PM > *To:* Developing a hybrid router/bridge. > *Subject:* Re: [rbridge] MAN scale and future uses of Rbridge > > > > On 10/17/05, Sofia, Rute <rute.sofia@siemens.com> wrote: > > > > Considering Rbridges application from a MAN scope, other scalability > > issues relate to: > > - storage cost (the price of flat addressing and of having every > > Rbridge learning both requested and unrequested MAC destination > > addresses) may be decreased, but is something that has not be considere= d > > up until now, given that the scope is limited to a campus... > > > What number of MAC addresses is the target for the rbridge campus? Do you > think the constraints are on the memory or on the notifications required > due to changes? > > - scalability related to the IS-IS tuning. On this point, (I am not > > completely sure about the price but...), there is a price to pay to tun= e > > > > IS-IS in order to achieve convergence in the order of hundreds of > > seconds. This is another issue to be checked. > > > Is there a reason that different areas couldn't be used in the IS-IS > instance for rbridges? > Do you think this would be adequate? Are the topological restrictions (i.= e. > hub and spoke) > acceptable? Could we work around that? > > Summing up, these are issues to be considered *if* Rbridges is to be > > extended to something larger than a campus. But going back to the > > participate vs. non-participate in the ST issue, then the scope is > > something that may help in deciding this issue. As I said, I do not see > > that Rbridges need to intervene *if* the scope is limited to a campus. > > Why? Because as stated in Radia's paper, Rbridges can simply terminate > > STs, which makes all the sense given that a Rbridge is a hybrid router. > > But this scenario does not seem to make the same sense, if a MAN scope > > is considered... > > > > While improving the scalability may not be immediately in scope, I think > it is > worthwhile to consider where the restrictions are coming from. > > Alia > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > > > > ------=_Part_20407_136698.1129575709588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/17/05, <b class=3D"gmail_sendername">Peter Ashwood-Smith</b> <<a h= ref=3D"mailto:petera@nortel.com">petera@nortel.com</a>> wrote:<div><span= class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote" style=3D"bo= rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding= -left: 1ex;"> <div><span><font color=3D"#0000ff" face=3D"Arial" size=3D"2">I=20 think the main impediment to very large scale is the large flat address spa= ce=20 and its rate of change. Not the number or Rbridge nodes and=20 networks/links. While use of IS-IS or OSPF areas can help when address= ing=20 is hierarchical, they are not going to help much when you cannot aggregate = the=20 addresses into specific areas.</font></span></div></blockquote><div><br> There are environments where the rate of change could be reasonably bounded= , so that brings it back to the flat address space...<br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><s= pan><font color=3D"#0000ff" face=3D"Arial" size=3D"2">Then=20 again I don't think that Rbridge needs to scale that large to be enormously= =20 useful. If it pushes the attainable size out a bit, gives better routes, is= more=20 stable and allows future innovations based on the topology it is going= to=20 be very useful. After that .. well its routers all the way down=20 ;)</font></span></div></blockquote><div><br> What do you think is large enough? (I remember the discussion earlier= , but not specific numbers.)<br> <br> Alia <br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span c= lass=3D"sg"><div><span><font color=3D"#0000ff" face=3D"Arial" size=3D"2">Pe= ter</font> </span></div></span><div><span class=3D"e" id=3D"q_106ffefd56937552_2"> <blockquote style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5= px; margin-left: 5px; margin-right: 0px;"> <div></div> <div align=3D"left" dir=3D"ltr" lang=3D"en-us"><font face=3D"Tahoma" size= =3D"2">-----Original Message-----<br><b>From:</b>=20 <a href=3D"mailto:rbridge-bounces@postel.org" target=3D"_blank" onclick= =3D"return top.js.OpenExtLink(window,event,this)">rbridge-bounces@postel.or= g</a> [mailto:<a href=3D"mailto:rbridge-bounces@postel.org" target=3D"_blan= k" onclick=3D"return top.js.OpenExtLink(window,event,this)"> rbridge-bounces@postel.org</a>] <b>On Behalf Of=20 </b>Alia Atlas<br><b>Sent:</b> Monday, October 17, 2005 2:37 PM<br><b>To:= </b>=20 Developing a hybrid router/bridge.<br><b>Subject:</b> Re: [rbridge] MAN s= cale=20 and future uses of Rbridge<br><br></font></div><br><br> <div><span class=3D"gmail_quote">On 10/17/05, <b class=3D"gmail_sendernam= e">Sofia,=20 Rute</b> <<a href=3D"mailto:rute.sofia@siemens.com" target=3D"_blank" = onclick=3D"return top.js.OpenExtLink(window,event,this)">rute.sofia@siemens= .com</a>>=20 wrote:</span> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204= , 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Considering=20 Rbridges application from a MAN scope, other scalability<br>issues rela= te=20 to:<br>- storage cost (the price of flat addressing and of h= aving=20 every<br>Rbridge learning both requested and unrequested MAC destinatio= n=20 <br>addresses) may be decreased, but is something that has not be=20 considered<br>up until now, given that the scope is limited to a=20 campus...</blockquote> <div><br> What number of MAC addresses is the target for the rbridge= =20 campus? Do you<br>think the constraints are on the memory or = on=20 the notifications required due to changes? <br><br></div> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204= , 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-=20 scalability related to the IS-IS tuning. On this point, (I am=20 not<br>completely sure about the price but...), there is a price to pay= to=20 tune <br>IS-IS in order to achieve convergence in the order of hundreds= =20 of<br>seconds. This is another issue to be checked.</blockquote> <div><br>Is there a reason that different areas couldn't be used in the I= S-IS=20 instance for rbridges?<br>Do you think this would be adequate? Are = the=20 topological restrictions (i.e. hub and spoke)<br>acceptable? Could = we=20 work around that?<br></div><br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204= , 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Summing=20 up, these are issues to be considered *if* Rbridges is to be<br>extende= d to=20 something larger than a campus. But going back to the <br>participate v= s.=20 non-participate in the ST issue, then the scope is<br>something that ma= y=20 help in deciding this issue. As I said, I do not see<br>that Rbridges n= eed=20 to intervene *if* the scope is limited to a campus.<br>Why? Because as= =20 stated in Radia's paper, Rbridges can simply terminate<br>STs, which ma= kes=20 all the sense given that a Rbridge is a hybrid router.<br>But this scen= ario=20 does not seem to make the same sense, if a MAN scope<br>is=20 considered...<br></blockquote></div><br>While improving the scalability m= ay=20 not be immediately in scope, I think it is<br>worthwhile to consider wher= e the=20 restrictions are coming from.<br><br>Alia<br></blockquote> </span></div><br>_______________________________________________<br>rbridge= mailing list<br><a onclick=3D"return top.js.OpenExtLink(window,event,this)= " href=3D"mailto:rbridge@postel.org">rbridge@postel.org</a><br><a onclick= =3D"return top.js.OpenExtLink(window,event,this)" href=3D"http://www.postel= .org/mailman/listinfo/rbridge" target=3D"_blank"> http://www.postel.org/mailman/listinfo/rbridge</a><br><br><br><br clear=3D"= all"></blockquote></div><br> ------=_Part_20407_136698.1129575709588-- Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HIn0L07021 for <rbridge@postel.org>; Mon, 17 Oct 2005 11:49:00 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9HImo125563 for <rbridge@postel.org>; Mon, 17 Oct 2005 14:48:50 -0400 (EDT) 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_01C5D34B.68C2DCA6" Date: Mon, 17 Oct 2005 14:48:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D14@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] MAN scale and future uses of Rbridge Thread-Index: AcXTSjHD1I1oSjuJRVyOdIQH6/KrKQAADaUw From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 17 Oct 2005 18:49:29 -0000 Status: RO Content-Length: 7976 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D34B.68C2DCA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the main impediment to very large scale is the large flat address space and its rate of change. Not the number or Rbridge nodes and networks/links. While use of IS-IS or OSPF areas can help when addressing is hierarchical, they are not going to help much when you cannot aggregate the addresses into specific areas. =20 Then again I don't think that Rbridge needs to scale that large to be enormously useful. If it pushes the attainable size out a bit, gives better routes, is more stable and allows future innovations based on the topology it is going to be very useful. After that .. well its routers all the way down ;) =20 Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Alia Atlas Sent: Monday, October 17, 2005 2:37 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] MAN scale and future uses of Rbridge =09 =09 On 10/17/05, Sofia, Rute <rute.sofia@siemens.com> wrote:=20 Considering Rbridges application from a MAN scope, other scalability issues relate to: - storage cost (the price of flat addressing and of having every Rbridge learning both requested and unrequested MAC destination=20 addresses) may be decreased, but is something that has not be considered up until now, given that the scope is limited to a campus... What number of MAC addresses is the target for the rbridge campus? Do you think the constraints are on the memory or on the notifications required due to changes?=20 =09 =09 - scalability related to the IS-IS tuning. On this point, (I am not completely sure about the price but...), there is a price to pay to tune=20 IS-IS in order to achieve convergence in the order of hundreds of seconds. This is another issue to be checked. Is there a reason that different areas couldn't be used in the IS-IS instance for rbridges? Do you think this would be adequate? Are the topological restrictions (i.e. hub and spoke) acceptable? Could we work around that? =09 Summing up, these are issues to be considered *if* Rbridges is to be extended to something larger than a campus. But going back to the=20 participate vs. non-participate in the ST issue, then the scope is something that may help in deciding this issue. As I said, I do not see that Rbridges need to intervene *if* the scope is limited to a campus. Why? Because as stated in Radia's paper, Rbridges can simply terminate STs, which makes all the sense given that a Rbridge is a hybrid router. But this scenario does not seem to make the same sense, if a MAN scope is considered... =09 While improving the scalability may not be immediately in scope, I think it is worthwhile to consider where the restrictions are coming from. =09 Alia =09 ------_=_NextPart_001_01C5D34B.68C2DCA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff = size=3D2>I=20 think the main impediment to very large scale is the large flat address = space=20 and its rate of change. Not the number or Rbridge nodes and=20 networks/links. While use of IS-IS or OSPF areas can help when = addressing=20 is hierarchical, they are not going to help much when you cannot = aggregate the=20 addresses into specific areas.</FONT></SPAN></DIV> <DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff = size=3D2>Then=20 again I don't think that Rbridge needs to scale that large to be = enormously=20 useful. If it pushes the attainable size out a bit, gives better routes, = is more=20 stable and allows future innovations based on the topology it is = going to=20 be very useful. After that .. well its routers all the way down=20 ;)</FONT></SPAN></DIV> <DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff = size=3D2>Peter</FONT></SPAN></DIV> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20 rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <B>On = Behalf Of=20 </B>Alia Atlas<BR><B>Sent:</B> Monday, October 17, 2005 2:37 = PM<BR><B>To:</B>=20 Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] = MAN scale=20 and future uses of Rbridge<BR><BR></FONT></DIV><BR><BR> <DIV><SPAN class=3Dgmail_quote>On 10/17/05, <B = class=3Dgmail_sendername>Sofia,=20 Rute</B> <<A=20 href=3D"mailto:rute.sofia@siemens.com">rute.sofia@siemens.com</A>>=20 wrote:</SPAN> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid">Considering=20 Rbridges application from a MAN scope, other scalability<BR>issues = relate=20 to:<BR>- storage cost (the price of flat addressing and = of having=20 every<BR>Rbridge learning both requested and unrequested MAC = destination=20 <BR>addresses) may be decreased, but is something that has not be=20 considered<BR>up until now, given that the scope is limited to a=20 campus...</BLOCKQUOTE> <DIV><BR> What number of MAC addresses is the target for the = rbridge=20 campus? Do you<BR>think the constraints are on the memory = or on=20 the notifications required due to changes? <BR><BR></DIV> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid">-=20 scalability related to the IS-IS tuning. On this point, (I am=20 not<BR>completely sure about the price but...), there is a price to = pay to=20 tune <BR>IS-IS in order to achieve convergence in the order of = hundreds=20 of<BR>seconds. This is another issue to be checked.</BLOCKQUOTE> <DIV><BR>Is there a reason that different areas couldn't be used in = the IS-IS=20 instance for rbridges?<BR>Do you think this would be adequate? = Are the=20 topological restrictions (i.e. hub and spoke)<BR>acceptable? = Could we=20 work around that?<BR></DIV><BR> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid">Summing=20 up, these are issues to be considered *if* Rbridges is to = be<BR>extended to=20 something larger than a campus. But going back to the = <BR>participate vs.=20 non-participate in the ST issue, then the scope is<BR>something that = may=20 help in deciding this issue. As I said, I do not see<BR>that = Rbridges need=20 to intervene *if* the scope is limited to a campus.<BR>Why? Because = as=20 stated in Radia's paper, Rbridges can simply terminate<BR>STs, which = makes=20 all the sense given that a Rbridge is a hybrid router.<BR>But this = scenario=20 does not seem to make the same sense, if a MAN scope<BR>is=20 considered...<BR></BLOCKQUOTE></DIV><BR>While improving the = scalability may=20 not be immediately in scope, I think it is<BR>worthwhile to consider = where the=20 restrictions are coming = from.<BR><BR>Alia<BR></BLOCKQUOTE></BODY></HTML> =00 ------_=_NextPart_001_01C5D34B.68C2DCA6-- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HIb8L03895 for <rbridge@postel.org>; Mon, 17 Oct 2005 11:37:08 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 36so461934wra for <rbridge@postel.org>; Mon, 17 Oct 2005 11:37:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=roW9D4Q1xL0PbXSDObEpR4BFAWG8nKculEW65YDnSIiJuBwrBBVSmr57DYqG0IMCwe2wvvgazNLjKPmIFK03JoPpk92wBWmtCVq65UfndZPsDAy6Pf4Fb/fFjhZIrCs8mRhJNe/pGyKzfVnw0GY0OUQODnPKrhj+N4CfS9Audwk= Received: by 10.54.94.11 with SMTP id r11mr606144wrb; Mon, 17 Oct 2005 11:35:28 -0700 (PDT) Received: by 10.54.148.1 with HTTP; Mon, 17 Oct 2005 11:37:03 -0700 (PDT) Message-ID: <6280db520510171137u18936523he4226bc6a4213790@mail.gmail.com> Date: Mon, 17 Oct 2005 11:37:03 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <ECDC9C7BC7809340842C0E7FCF48C3937CEBA2@MCHP7IEA.ww002.siemens.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20127_24578989.1129574223832" References: <ECDC9C7BC7809340842C0E7FCF48C3937CEBA2@MCHP7IEA.ww002.siemens.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 17 Oct 2005 18:37:30 -0000 Status: RO Content-Length: 4757 ------=_Part_20127_24578989.1129574223832 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/17/05, Sofia, Rute <rute.sofia@siemens.com> wrote: > > Considering Rbridges application from a MAN scope, other scalability > issues relate to: > - storage cost (the price of flat addressing and of having every > Rbridge learning both requested and unrequested MAC destination > addresses) may be decreased, but is something that has not be considered > up until now, given that the scope is limited to a campus... What number of MAC addresses is the target for the rbridge campus? Do you think the constraints are on the memory or on the notifications required du= e to changes? - scalability related to the IS-IS tuning. On this point, (I am not > completely sure about the price but...), there is a price to pay to tune > IS-IS in order to achieve convergence in the order of hundreds of > seconds. This is another issue to be checked. Is there a reason that different areas couldn't be used in the IS-IS instance for rbridges? Do you think this would be adequate? Are the topological restrictions (i.e. hub and spoke) acceptable? Could we work around that? Summing up, these are issues to be considered *if* Rbridges is to be > extended to something larger than a campus. But going back to the > participate vs. non-participate in the ST issue, then the scope is > something that may help in deciding this issue. As I said, I do not see > that Rbridges need to intervene *if* the scope is limited to a campus. > Why? Because as stated in Radia's paper, Rbridges can simply terminate > STs, which makes all the sense given that a Rbridge is a hybrid router. > But this scenario does not seem to make the same sense, if a MAN scope > is considered... > While improving the scalability may not be immediately in scope, I think it is worthwhile to consider where the restrictions are coming from. Alia ------=_Part_20127_24578989.1129574223832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <br><br><div><span class=3D"gmail_quote">On 10/17/05, <b class=3D"gmail_sen= dername">Sofia, Rute</b> <<a href=3D"mailto:rute.sofia@siemens.com">rute= .sofia@siemens.com</a>> wrote:</span><blockquote class=3D"gmail_quote" s= tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e= x; padding-left: 1ex;"> Considering Rbridges application from a MAN scope, other scalability<br>iss= ues relate to:<br>- storage cost (the price of flat addressing a= nd of having every<br>Rbridge learning both requested and unrequested MAC d= estination <br>addresses) may be decreased, but is something that has not be considere= d<br>up until now, given that the scope is limited to a campus...</blockquo= te><div><br> What number of MAC addresses is the target for the rbridge campus?&nb= sp; Do you<br> think the constraints are on the memory or on the notifications required du= e to changes? <br> <br> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb= (204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- scalabili= ty related to the IS-IS tuning. On this point, (I am not<br>completely sure= about the price but...), there is a price to pay to tune <br>IS-IS in order to achieve convergence in the order of hundreds of<br>se= conds. This is another issue to be checked.</blockquote><div><br> Is there a reason that different areas couldn't be used in the IS-IS instan= ce for rbridges?<br> Do you think this would be adequate? Are the topological restrictions= (i.e. hub and spoke)<br> acceptable? Could we work around that?<br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Summing= up, these are issues to be considered *if* Rbridges is to be<br>extended t= o something larger than a campus. But going back to the <br>participate vs. non-participate in the ST issue, then the scope is<br>s= omething that may help in deciding this issue. As I said, I do not see<br>t= hat Rbridges need to intervene *if* the scope is limited to a campus.<br> Why? Because as stated in Radia's paper, Rbridges can simply terminate<br>S= Ts, which makes all the sense given that a Rbridge is a hybrid router.<br>B= ut this scenario does not seem to make the same sense, if a MAN scope<br> is considered...<br> </blockquote></div><br> While improving the scalability may not be immediately in scope, I think it= is<br> worthwhile to consider where the restrictions are coming from.<br> <br> Alia<br> ------=_Part_20127_24578989.1129574223832-- Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HIPDL29419 for <rbridge@postel.org>; Mon, 17 Oct 2005 11:25:13 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 11:24:36 -0700 X-IronPort-AV: i="3.97,222,1125903600"; d="scan'208"; a="353189325:sNHT26745292" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9HIO0KD021823 for <rbridge@postel.org>; Mon, 17 Oct 2005 11:24:34 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 11:24:33 -0700 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: Mon, 17 Oct 2005 11:24:32 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8DCDDD9@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/QAADEakAAA7E1wA== From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 17 Oct 2005 18:24:33.0956 (UTC) FILETIME=[05DF6640:01C5D348] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HIPDL29419 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 18:25:31 -0000 Status: RO Content-Length: 1969 > -----Original Message----- > From: rbridge-bounces@postel.org > Subject: Re: [rbridge] Time to summarize "forward or block" > BPDU thread > > > > b) there are scary dependencies between bridge spanning tree and > > > RBridges algorithms > > > > Yeah no kidding. > > > > > c) no advantage as far as I can see. I don't know why we are > > > discussing this. > > > > Well there are still a few folks on this list that are > not convinced > > of a) or b). There are probably 100 more on the list that are just > > quietly listening that also don't understand. > > We are very likely to encounter these opinions over and > over again and > > the best approach is to discuss and counter them and capture it for > > future reference. Otherwise we are going to see these same > arguments > > over and over again and used as 'reasons' why Rbridge is > 'not as good > > as X or Y'. > > > > My 2cents: if Rbridges scope is indeed a campus, then Radia's > claims hold...there is no advantage in having Rbridges > meddling with legacy stuff. While rbridges may not have to "meddle with legacy stuff", at a minimum, we should list the all of the 802.1 and 802.3 protocols and indicate the applicable action(s). (Similar to that done for the UNI in the Metro Ethernet Forum (MEF) and ITU 8011 series specifications.) For example, blocking BPDUs is valid but simply blocking GVRP will cause connectivity issues. Michael > Now, if Rbridges is intended to > be applied to other fields, e.g., MAN scope, then yes, legacy > is an issue. > > I do not see the second case happening particularly because > there are other issues (besides the legacy interworking) that > would require additional work in Rbridges. So I quite frankly > do not see the point in prolonging this discussion either. > > So, > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > 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 j9HHI7L09859 for <rbridge@postel.org>; Mon, 17 Oct 2005 10:18:08 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9HHHu0e028068 for <rbridge@postel.org>; Mon, 17 Oct 2005 19:17:56 +0200 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 j9HHHupj012899 for <rbridge@postel.org>; Mon, 17 Oct 2005 19:17:56 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 19:17:56 +0200 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: Mon, 17 Oct 2005 19:17:55 +0200 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CEBA2@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] MAN scale and future uses of Rbridge Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/QAADEakAAAKFTQAABkWDAAABLjnAAAXRR0A== From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 17 Oct 2005 17:17:56.0311 (UTC) FILETIME=[B7172E70:01C5D33E] 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 j9HHI7L09859 Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 17 Oct 2005 17:18:26 -0000 Status: RO Content-Length: 2560 > > This is one reason for the dominance of OSPF over RIP at L3. > > Shortest paths are of course of interest in the MAN but > other reasons > why Rbridge is attractive in the MAN consist of future uses > of its link > state topology. In particular as Alia pointed out, RAPID > style rerouting > (loop free alternates) is possible. Also the link state topology is > useful for constraint based routing. So let's not rule out > larger scale > in the future, especially since this is where Rbridge will > really shine. > Besides the fact that having "all" the topology at hand provides greater flexibility to decide on how to forward information, scalability issues concerning Rbridges imply more than just the forwarding algorithm of choice. Considering Rbridges application from a MAN scope, other scalability issues relate to: - storage cost (the price of flat addressing and of having every Rbridge learning both requested and unrequested MAC destination addresses) may be decreased, but is something that has not be considered up until now, given that the scope is limited to a campus... - backward compatibility issues currently being discussed (i.e., whether to have Rbridges as termination of STs). If the use of Rbridges within the MAN is not to be disregarded, then there is a cost related to having Rbridges interworking with legacy bridges. By not allowing Rbridges to intervene in the ST (using BLOCK) then the Rbridge placement must be carefully chosen, or performance will degrade. - scalability due to broadcasts. As Saikat stated, there are better approaches to treat broadcasts and not really requiring much more computational power (given that all the information is local) - scalability related to the IS-IS tuning. On this point, (I am not completely sure about the price but...), there is a price to pay to tune IS-IS in order to achieve convergence in the order of hundreds of seconds. This is another issue to be checked. Summing up, these are issues to be considered *if* Rbridges is to be extended to something larger than a campus. But going back to the participate vs. non-participate in the ST issue, then the scope is something that may help in deciding this issue. As I said, I do not see that Rbridges need to intervene *if* the scope is limited to a campus. Why? Because as stated in Radia's paper, Rbridges can simply terminate STs, which makes all the sense given that a Rbridge is a hybrid router. But this scenario does not seem to make the same sense, if a MAN scope is considered... Regards, Rute Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HGXQL25004 for <rbridge@postel.org>; Mon, 17 Oct 2005 09:33:26 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9HGXIa03096 for <rbridge@postel.org>; Mon, 17 Oct 2005 12:33:18 -0400 (EDT) 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: Mon, 17 Oct 2005 12:33:18 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D0E@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] MAN scale and future uses of Rbridge Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/QAADEakAAAKFTQAABkWDAAABLjnA= From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HGXQL25004 Subject: Re: [rbridge] MAN scale and future uses of Rbridge 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, 17 Oct 2005 16:34:26 -0000 Status: RO Content-Length: 913 > > The protocols do not know how they are being applied. They > > are either > > mathematically correct or not so I assume you are either > talking about > > scale or migration? > > About scalability, yes. > > Regards, > Rute In general link state type procotols of which IS-IS and therefore Rbridge is an example scale better than distance vector style protocols, of which STP is a varient. This is one reason for the dominance of OSPF over RIP at L3. Shortest paths are of course of interest in the MAN but other reasons why Rbridge is attractive in the MAN consist of future uses of its link state topology. In particular as Alia pointed out, RAPID style rerouting (loop free alternates) is possible. Also the link state topology is useful for constraint based routing. So let's not rule out larger scale in the future, especially since this is where Rbridge will really shine. Peter Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HGACL16861 for <rbridge@postel.org>; Mon, 17 Oct 2005 09:10:12 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9HG9wTt009494 for <rbridge@postel.org>; Mon, 17 Oct 2005 18:09:58 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9HG9wNQ028445 for <rbridge@postel.org>; Mon, 17 Oct 2005 18:09:58 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 18:09:57 +0200 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: Mon, 17 Oct 2005 18:09:57 +0200 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CEB9F@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/QAADEakAAAKFTQAABkWDA From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 17 Oct 2005 16:09:57.0878 (UTC) FILETIME=[3827B160:01C5D335] 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 j9HGACL16861 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 16:10:27 -0000 Status: RO Content-Length: 492 > > > My 2cents: if Rbridges scope is indeed a campus, then Radia's claims > > hold...there is no advantage in having Rbridges meddling with legacy > > stuff. Now, if Rbridges is intended to be applied to other > > fields, e.g., > > MAN scope, then yes, legacy is an issue. > > The protocols do not know how they are being applied. They > are either > mathematically correct or not so I assume you are either talking about > scale or migration? About scalability, yes. Regards, Rute Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HFaFL07049 for <rbridge@postel.org>; Mon, 17 Oct 2005 08:36:15 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9HFaECD011890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Mon, 17 Oct 2005 11:36:14 -0400 Message-Id: <200510171536.j9HFaECD011890@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 17 Oct 2005 11:36:23 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXTJmEHFBzQhhPyTye8LOFUl6H+NgABVhEgAACvASAAACwFgA== X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 17 Oct 2005 15:36:28 -0000 Status: RO Content-Length: 2519 There is a *theoretical* possibility of oscillatory behavior if an unknown third protocol is present in the network (the one that our imaginary "sbridges" implement). Basically suppose that the protocol sBridges implement interacts with the STP. Then the following sequence of events may occur (under the assumption that sBridge control messages look like data packets to RBridges). First the sBridges and the legacy bridges together converge to some topology, most likely a disjoint one. During this time, RBridges are invisible; in particular, sBridges do not see them. Then the RBridge topology converges. However, now potentially the connectivity that sBridges see has changed (due to packet forwarding by RBridges). Thus, sBridges try to recomputed their states, which in turn trigger an STP recomputation (because we are assuming that sBridge protocol and STP interacts), and we are back to square one (i.e. an oscillation starts)! I cannot off the top of my head think of a dumb enough sBridge protocol that would result into this scenario, but one cannot rule out the possibility! -----Original Message----- From: Saikat Ray [mailto:saikat@seas.upenn.edu] Sent: Monday, October 17, 2005 11:22 AM To: 'Developing a hybrid router/bridge.' Subject: FW: [rbridge] Time to summarize "forward or block" BPDU thread Now you can have an rbridge and an sbridge in the same L2 (how do you know you don't?). They form an undetectable, uncorrectable loop. [Saikat] I do not see how this happens. First I am assuming that if "sbridges" are connected by physical links, then they know how to avoid packet loops by some mechanism they choose to implement. Now, as far as "sbridges" are concerned, the network consisting of RBridges, STP-running bridges, physical links etc., is simply a "link". In other words, the entire network (consisting of RBridges, STP-running bridges, physical links etc.) could be replaced by a physical link. Thus even in this case, there would be no packet loop in the steady state. Another way of looking at this argument is the following. Suppose you remove all the RBridges from the network. sBridges and legacy bridges are left, and the assumption is that in that case, at least, a loop-free network results. Then when you add RBridges (in their original position), the rest of the network is simply one or more "link"s, and RBridges would ensure that there would be no loops. Do you have an example in mind where the previous scenario (sbridges+rBridges) may end up in creating a loop? Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HFYaL06681 for <rbridge@postel.org>; Mon, 17 Oct 2005 08:34:37 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9HFYSa28607 for <rbridge@postel.org>; Mon, 17 Oct 2005 11:34:29 -0400 (EDT) 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: Mon, 17 Oct 2005 11:34:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D0B@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/QAADEakAAAKFTQA== From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HFYaL06681 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 15:35:27 -0000 Status: RO Content-Length: 974 > My 2cents: if Rbridges scope is indeed a campus, then Radia's claims > hold...there is no advantage in having Rbridges meddling with legacy > stuff. Now, if Rbridges is intended to be applied to other > fields, e.g., > MAN scope, then yes, legacy is an issue. The protocols do not know how they are being applied. They are either mathematically correct or not so I assume you are either talking about scale or migration? > I do not see the second case happening particularly because there are > other issues (besides the legacy interworking) that would require > additional work in Rbridges. So I quite frankly do not see > the point in > prolonging this discussion either. The point in discussing these issues is to find answers to them in this forum before the same issues make their way into a much larger audience. It is very hard to stop negative opinions or incorrect ones concerning technology once they reach a larger less informed audience. Peter Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HFLhL02370 for <rbridge@postel.org>; Mon, 17 Oct 2005 08:21:43 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9HFLgLZ010230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Mon, 17 Oct 2005 11:21:42 -0400 Message-Id: <200510171521.j9HFLgLZ010230@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 17 Oct 2005 11:21:51 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXTJmEHFBzQhhPyTye8LOFUl6H+NgABVhEgAACvASA= X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: [rbridge] FW: Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 17 Oct 2005 15:22:26 -0000 Status: RO Content-Length: 1199 Now you can have an rbridge and an sbridge in the same L2 (how do you know you don't?). They form an undetectable, uncorrectable loop. [Saikat] I do not see how this happens. First I am assuming that if "sbridges" are connected by physical links, then they know how to avoid packet loops by some mechanism they choose to implement. Now, as far as "sbridges" are concerned, the network consisting of RBridges, STP-running bridges, physical links etc., is simply a "link". In other words, the entire network (consisting of RBridges, STP-running bridges, physical links etc.) could be replaced by a physical link. Thus even in this case, there would be no packet loop in the steady state. Another way of looking at this argument is the following. Suppose you remove all the RBridges from the network. sBridges and legacy bridges are left, and the assumption is that in that case, at least, a loop-free network results. Then when you add RBridges (in their original position), the rest of the network is simply one or more "link"s, and RBridges would ensure that there would be no loops. Do you have an example in mind where the previous scenario (sbridges+rBridges) may end up in creating a loop? Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HFCbL29547 for <rbridge@postel.org>; Mon, 17 Oct 2005 08:12:38 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9HF9s422800 for <rbridge@postel.org>; Mon, 17 Oct 2005 11:09:55 -0400 (EDT) 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: Mon, 17 Oct 2005 11:12:29 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D08@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTFUPJ0N3GbrvqS06jv9ow/3HJ2QAFQC7Q From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HFCbL29547 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 15:13:26 -0000 Status: RO Content-Length: 1338 > > Also, the 'problems' that people are attributing to > blocking and not > > processing BPDUs [BLOCK] are also 'problems' when no STP is running. > > 'problems'? (why the quotes?) Because I don't see them and did not want people to think I did. > OK, let's just shut off spanning tree in bridges and it all > works just fine now? > > Now I'm *really* confused. Sorry, my explaination was not very clear. I was simply pointing out that the Rbridge DR mechanism avoids loops independently of the STP protocol. Therefore, if there are no loops PRIOR to the introduction of the rbridges and their interconnections, but there is a loop AFTER their introduction the rbridges will detect and prevent it. In otherwords they detect and prevent loops for which they are responsible. > If we want to say "BLOCK *MAY* work, but *MAY* silently > fail", and "PARTICIPATE and TRANSPARENT will always work with > current standards", that's fine (and, AFAICT, true), but I > also don't see how we pick BLOCK as a default in that case. I'd like to see the example of BLOCK failing and by failing I mean a permanent loop uncorrected by either STP or Rbridge. Personally I don't think this exists because the simple 'proof' of interconnecting two trees with a single link still being a tree seems pretty air tight to me! Peter 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 j9HF9ML28449 for <rbridge@postel.org>; Mon, 17 Oct 2005 08:09:22 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9HF9GZv021063 for <rbridge@postel.org>; Mon, 17 Oct 2005 17:09:16 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9HF9F7D010303 for <rbridge@postel.org>; Mon, 17 Oct 2005 17:09:15 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 17:09:14 +0200 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: Mon, 17 Oct 2005 17:09:14 +0200 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CEB9E@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/QAADEakA= From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 17 Oct 2005 15:09:14.0889 (UTC) FILETIME=[BCC3AF90:01C5D32C] 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 j9HF9ML28449 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 15:10:29 -0000 Status: RO Content-Length: 1213 > > b) there are scary dependencies between bridge spanning tree > > and RBridges algorithms > > Yeah no kidding. > > > c) no advantage as far as I can see. I don't know why we are > > discussing this. > > Well there are still a few folks on this list that are not > convinced of a) or b). There are probably 100 more on the list > that are just quietly listening that also don't understand. > We are very likely to encounter these opinions over and over > again and the best approach is to discuss and counter them > and capture it for future reference. Otherwise we are going > to see these same arguments over and over again and used as > 'reasons' why Rbridge is 'not as good as X or Y'. > My 2cents: if Rbridges scope is indeed a campus, then Radia's claims hold...there is no advantage in having Rbridges meddling with legacy stuff. Now, if Rbridges is intended to be applied to other fields, e.g., MAN scope, then yes, legacy is an issue. I do not see the second case happening particularly because there are other issues (besides the legacy interworking) that would require additional work in Rbridges. So I quite frankly do not see the point in prolonging this discussion either. So, Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HF1KL25874 for <rbridge@postel.org>; Mon, 17 Oct 2005 08:01:21 -0700 (PDT) Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 17 Oct 2005 20:43:59 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HF0xYq023013 for <rbridge@postel.org>; Mon, 17 Oct 2005 15:01:07 GMT Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 20:30:03 +0530 Received: from [10.77.203.69] ([10.77.203.69]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 20:30:02 +0530 Message-ID: <4353BC71.5010309@cisco.com> Date: Mon, 17 Oct 2005 20:30:01 +0530 From: Ganesh CS <gsankara@cisco.com> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <28e2abaf5cf9.4353524d@sunlabs.com> In-Reply-To: <28e2abaf5cf9.4353524d@sunlabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2005 15:00:02.0963 (UTC) FILETIME=[73CA7630:01C5D32B] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gsankara@cisco.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 15:01:26 -0000 Status: RO Content-Length: 5733 Hi Radia, Radia.Perlman@sun.com wrote: >Yes, the intention is to do optimized distribution of IP-based multicast >by using >a) per-ingress Rbridge tree, and > > Do you mean (ingress Rbridge, group) instead of (source, group) ? >b) filtering of that tree based on snooping on IGMP > > IGMP snooping is not applicable for IP subnet based broadcasts. Alternately will be based on host information ? -Ganesh >Radia > >----- Original Message ----- >From: Ganesh CS <gsankara@cisco.com> >Date: Monday, October 17, 2005 6:14 am >Subject: Re: [rbridge] Treating broadcast addresses > > > >>What about IP subnet based broadcasts, how will they be supported >>by >>rbridges ? >>Will it be more on lines of subnet based multicast instead of >>broadcast >>in rbridge network ? >> >>-Ganesh >> >>Vishwas Manral wrote: >> >> >> >>>Hi Rute, >>> >>> >>> >>>Thanks for the reply. I am clearer now. >>> >>> >>> >>>If the root election is done at run time (like DR election in IS- >>> >>> >>IS), >> >> >>>it could mean that the Root could change often. If we had a >>> >>> >>sticky >> >> >>>Root election (like a DR election in OSPF) it could mean that the >>> >>> >>root >> >> >>>selection would take time to converge. >>> >>> >>> >>>Thanks again, >>> >>>Vishwas >>> >>>------------------------------------------------------------------ >>> >>> >>------ >> >> >>>*From:* rbridge-bounces@postel.org [rbridge-bounces@postel.org] >>>*On Behalf Of *Sofia, Rute >>>*Sent:* Monday, October 17, 2005 5:23 PM >>>*To:* Developing a hybrid router/bridge. >>>*Subject:* Re: [rbridge] Treating broadcast addresses >>> >>> >>> >>>Vishwas, >>> >>> >>> >>>Suppose you are speaking about the ST that Rbridges use to >>> >>> >>perform >> >> >>>broadcast. You don't need root election: the info provided by >>> >>> >>LSPs is >> >> >>>enough to build the ST. >>> >>> >>> >>>Regards, >>> >>>Rute >>> >>> >>> >>> >>> >>> -------------------------------------------------------------- >>> >>> >>---------- >> >> >>> *From:* rbridge-bounces@postel.org >>> [rbridge-bounces@postel.org] *On Behalf Of *Vishwas Manral >>> *Sent:* Monday, October 17, 2005 1:27 PM >>> *To:* Developing a hybrid router/bridge. >>> *Subject:* Re: [rbridge] Treating broadcast addresses >>> >>> Hi Rute, >>> >>> >>> >>> Would this also mean Root-Election? What about convergence of >>> >>> >>this> tree? >> >> >>> >>> >>> Thanks, >>> >>> Vishwas >>> >>> -------------------------------------------------------------- >>> >>> >>---------- >> >> >>> *From:* rbridge-bounces@postel.org >>> [rbridge-bounces@postel.org] *On Behalf Of *Sofia, Rute >>> *Sent:* Monday, October 17, 2005 4:36 PM >>> *To:* Developing a hybrid router/bridge. >>> *Subject:* Re: [rbridge] Treating broadcast addresses >>> >>> >>> >>> Vishwas, >>> >>> >>> >>> based on the information exchanged by LSPs you can simply >>> >>> >>compute> the ST locally. The key here is the choice of the >>root. This can >> >> >>> also be passed along by IS-IS... >>> >>> >>> >>> Regards, >>> >>> Rute >>> >>> >>> >>> Hi, >>> >>> >>> >>> My question is more like, how would we build a spanning tree >>> for broadcast using IS-IS? >>> >>> >>> >>> We need a globally coordinated tree like STP and not like >>> >>> >>the> way IS-IS computes it. Would we require, changes to the >> >> >>> spanning tree computation itself? >>> >>> >>> >>> Thanks, >>> >>> Vishwas >>> >>> ---------------------------------------------------------- >>> >>> >>-------------- >> >> >>> *From:* rbridge-bounces@postel.org >>> [rbridge-bounces@postel.org] *On Behalf Of *Vishwas Manral >>> *Sent:* Monday, October 17, 2005 11:41 AM >>> *To:* Developing a hybrid router/bridge. >>> *Subject:* [rbridge] Treating broadcast addresses >>> >>> >>> >>> Hi, >>> >>> >>> >>> I had a doubt about treatment of broadcast addresses. >>> >>> >>> >>> Currently using STP we have one tree and ports are blocked/ >>> forwarding, so packets cannot loop irrespective of >>> >>> >>destination> addresses. In IS-IS protocol, we use ports >>based on >> >> >>> destination address and no ports are blocked or >>> >>> >>unblocked. But >> >> >>> if the destination address is FF-FF-FF-FF-FF-FF we could end >>> in a forwarding loop. How would we get over it? >>> >>> >>> >>> Would we still allow broadcast destination address >>> >>> >>packets to >> >> >>> be forwarded? It is like preventing flooding loops in a case >>> where we have a global broadcast IP address, which is >>> forwarded to all attached routers. Am I missing the point >>> >>> >>all> together? >> >> >>> >>> >>> Thanks, >>> >>> Vishwas >>> >>> >>> >>>------------------------------------------------------------------- >>> >>> >>----- >> >> >>>_______________________________________________ >>>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 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 j9HEp6L22432 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:51:06 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00MFJEL16T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:51:01 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00D1MEL1U110@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:51:01 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [24.19.161.186]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 17 Oct 2005 07:51:01 -0700 Date: Mon, 17 Oct 2005 07:51:01 -0700 From: Radia.Perlman@sun.com To: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <28f53dec3b1e.435357e5@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:51:35 -0000 Status: RO Content-Length: 6490 The simplest thing would just be to have RBridges send hellos fairly often all the time. It would be a parameter, so people could set it. One could use hints like topology change flags, but I'm not sure how helpful that would be. It wouldn't hurt, but I don't think there would be that much overhead to having hellos every, say, second. Radia ----- Original Message ----- From: Saikat Ray <saikat@seas.upenn.edu> Date: Monday, October 17, 2005 6:46 am Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread > First of all, I totally agree with you that there should be > multiple small > spanning trees glued by RBridge networks instead of a global huge > spanningtree. My point was slightly different, though. In the > mechanism you pointed > out (hearing hallos from other RBridges), the amount of time a > temporaryloop persists would depend on the time interval between > hallo messages sent > by RBridges (what is the default value?). If two RBridges are > connected by a > physical link, then this is probably the only way the RBridges can > detectthe loop. However, if the underlying "link" is actually a > bridged network > (spanning tree), then the RBridges would have more information. For > example,when RBridges see topology change BPDU's (or something > similar), then they > may deduct the possibility of a loop formation and they may > increase the > sending rate of hallo messages. In short, the RBridges are > privileged to be > in a position to make additional observations (BPDUs) and, in my > humbleopinion, they ought to use it. > > -----Original Message----- > From: Radia Perlman [Radia.Perlman@sun.com] > Sent: Sunday, October 16, 2005 8:46 PM > To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Time to summarize "forward or block" BPDU > thread > The scenario you mention is where there is temporarily two > Designated > RBridges (DRs), because > two links were merged. > > The DRs will notice this when they start seeing each other's IS-IS > Hello > messages, and that > will break the loop. > > I don't think this case is that much of a problem, and certainly > would > not be helped by trying to run a big > global spanning tree. The big global spanning tree would converge > much > slower than the RBridge > DR election protocol would. So attempting to avoid a temporary loop > when > two bridged domains > are merged, by running a big global instance > of the spanning tree algorithm, will not solve the problem, and > will > actually > make things worse. > > Radia > > > > > Saikat Ray wrote: > > >It is probably a standard scenario in IS-IS protocol (and > consequently a > >standard solution is known), but I was thinking that if the RBridges > >disregards BPDUs entirely, then in some situations loops may form > for some > >period. For example, suppose $T_1$ and $T_2$ are disjoint trees > formed>entirely by legacy elements. $R_1$ and $R_2$ are the > designated RBridges > for > >the "links" $T_1$ and $T_2$, respectively. At this point, there is > no loop > >in the system. Now suppose that a physical link (or a legacy > bridge) is > >added that connects a legacy bridge of $T_1$ to a legacy bridge of > $T_2$.>This addition will trigger a new Spanning tree computation, > which will > >result into a single spanning tree that spans the nodes of $T_1$ > and $T_2$. > >At this point, effectively the RBridges $R_1$ and $R_2$ are > connected by a > >single "link" and until one of the RBridge gets "de-designated", > therewould > >exist a loop. Two questions arise in my mind: (i) how fast would that > >"de-designation" process be? And (ii) would it be useful (i.e. > would it > >accelerate the convergence) if RBridges "listen" to the BPDUs? > > > >-----Original Message----- > >From: rbridge-bounces@postel.org [rbridge-bounces@postel.org] On > >Behalf Of Radia Perlman > >Sent: Sunday, October 16, 2005 7:12 PM > >To: Developing a hybrid router/bridge. > >Subject: [rbridge] Time to summarize "forward or block" BPDU thread > > > >It looks like this thread was discussed with two different subject > >lines, and it's also > >gone on long enough it's time for someone to summarize it. > > > >I strongly believe that things will be more stable if RBridges do > NOT > >forward BPDUs...that > >we decouple the protocols. > > > >That TRILL is kind of like a layer between bridging and routing. > > > >If RBridges do not forward BPDUs, then whether or not the TRILL > link > >state protocol is > >converged, it won't affect the little spanning tree inside a > particular > >bridged segment. > > > >That way, the little spanning trees will converge as quickly as > possible > >(because it's small), > >and cannot possibly be disrupted by RBridges wormholing BPDUs. > > > >I do not understand the reasons why people want to forward BPDUs. > I > >think the arguments (which > >I may not be presenting fairly because I don't understand them) are: > >a) you'll get a more optimal combined spanning tree on which > >unknown/broadcast frames will > >be sent if it is one global spanning tree, rather than little > >independent spanning trees hooked together > >by the independently computed spanning tree calculated by IS-IS. > >b) forwarding BPDUs, and having a global spanning tree, will > prevent loops. > > > >I strongly disagree with both those arguments. For a) What do > people > >think is more optimal about a tree > >computed that way vs having independent trees inside each bridged > >island? And besides, there isn't > >a single spanning tree...it's a spanning tree per ingress RBridge. > >For b) no...I believe that having both the RBridge algorithm and > the > >bridge algorithm feeding into > >each other will create much slower convergence. > > > >If I haven't summarized correctly, then someone else can try to > capture > >the arguments, but I do > >think we should merge discussion under one subject line, and > restart > >with a summary. > > > >Radia > > > >_______________________________________________ > >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 zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HEoUL22206 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:50:30 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9HEoMa14996 for <rbridge@postel.org>; Mon, 17 Oct 2005 10:50:22 -0400 (EDT) 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: Mon, 17 Oct 2005 10:50:11 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D07@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTKChgLU+wZmBVTICqnt6qnS/PzgAARM/Q From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HEoUL22206 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:51:25 -0000 Status: RO Content-Length: 870 > With forwarding, or sometimes forwarding based on > configuration (I'm not sure what people are > proposing: > > a) things will converge much more slowly Agreed. > > b) there are scary dependencies between bridge spanning tree > and RBridges algorithms Yeah no kidding. > c) no advantage as far as I can see. I don't know why we are > discussing this. Well there are still a few folks on this list that are not convinced of a) or b). There are probably 100 more on the list that are just quietly listening that also don't understand. We are very likely to encounter these opinions over and over again and the best approach is to discuss and counter them and capture it for future reference. Otherwise we are going to see these same arguments over and over again and used as 'reasons' why Rbridge is 'not as good as X or Y'. Peter > > Radia 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 j9HEkaL21050 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:46:36 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00MFBEDJ6T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:46:31 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00D0TEDJU010@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:46:31 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [24.19.161.186]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 17 Oct 2005 07:46:31 -0700 Date: Mon, 17 Oct 2005 07:46:31 -0700 From: Radia.Perlman@sun.com To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <28f3dde73fd9.435356d7@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_qwWvcjcclrlXyJhYW77pvw)" Content-language: en X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:47:36 -0000 Status: RO Content-Length: 2365 This is a multi-part message in MIME format. --Boundary_(ID_qwWvcjcclrlXyJhYW77pvw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Actually, the explanation of how RBridges would work on a technical level was in the original draft. I thought it was just being broken into "architecture" and "technical", which would mean things wouldn't change. RBridges detect each other the same way routers detect each other. Through Hello messages, which get sent on a "link", which can be formed by whatever technology. One possible technology is bridged Ethernet. RBridges assume that the underlying link works the way it always did...to create a cloud on which any other RBridges connected to the cloud are fully connected. RBridges do not require changes on the underlying link. If people would think of it as a layer above, just like routers are, perhaps it would be less confusing. And RBridges also form a layer BELOW routers, so they are transparent to routers, and make no demands on IP nodes to change the way they work. Radia --Boundary_(ID_qwWvcjcclrlXyJhYW77pvw) Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========AD867A26ABED09D99B9B==========" --==========AD867A26ABED09D99B9B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 17. oktober 2005 05:17 -0700 Joe Touch <touch@ISI.EDU> wrote: > WHEN (note the use of 'when', not 'if', since there's *nothing* that can > be done to enforce this) this isn't the case, the following problems > arise: > > a) there is no way to detect the error > > b) loops *will* occur You know, I really can't tell whether this is true or not without looking=20 at the protocol specification that says how the RBridges detect each other. Should this discussion wait for the drafts to come out? Harald --==========AD867A26ABED09D99B9B==========-- --Boundary_(ID_qwWvcjcclrlXyJhYW77pvw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge --Boundary_(ID_qwWvcjcclrlXyJhYW77pvw)-- 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 j9HEgrL19401 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:42:53 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00MF4E796T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:42:45 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00D04E79U110@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:42:45 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [24.19.161.186]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 17 Oct 2005 07:42:45 -0700 Date: Mon, 17 Oct 2005 07:42:45 -0700 From: Radia.Perlman@sun.com To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <28f32dda66a3.435355f5@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng)" Content-language: en X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:43:27 -0000 Status: RO Content-Length: 2106 This is a multi-part message in MIME format. --Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline It works perfectly well if RBridges block. It isolates the bridge islands. Routers also block bridge spanning tree, and to exactly the same effect as if RBridges block BPDUs. There is no interdependency if they block. THere IS interdependency if RBridges forward BPDUs. Radia --Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng) Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enig81AB87D6717B80F53ED954EF --------------enig81AB87D6717B80F53ED954EF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > AFAICT, this all works when there is at most one rbridge campus in an L2. > > [Saikat] I think that the assumption (definition) is that if two RBridges > are connected directly (i.e. no IP router in between), then they are parts > of a single campus, thus must talk to each other. If that is true, then how > would you have more than one campuses that are not separated by an IP > router? You won't - the rbridge campuses will merge. But we're the IETF, and we're making 'rbridges', which will BLOCK. Let's say the IEEE decides to allow another group to make 'sbridges', which also decide to BLOCK. Now you can have an rbridge and an sbridge in the same L2 (how do you know you don't?). They form an undetectable, uncorrectable loop. -- I.e. - this all works only if everyone plays by OUR rules. Since we're NOT the IEEE, how is it that we can decide to create a protocol that relies on us being the ONLY exception? Joe --------------enig81AB87D6717B80F53ED954EF-- --Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge --Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng)-- Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HEgeL19382 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:42:40 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9HEdv405908 for <rbridge@postel.org>; Mon, 17 Oct 2005 10:39:57 -0400 (EDT) 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: Mon, 17 Oct 2005 10:42:30 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D06@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXTJ9BbLZUOdPFLTCmP7VTdJ9YzOgAAFWyQ From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HEgeL19382 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:43:25 -0000 Status: RO Content-Length: 632 > As someone trying to write the drafts, I'm trying to > understand the terminology that will determine this. > > I have a MUCH better idea of how to explain things now - > whether I agree with them at all levels or not, so this > discussion IS helping, FWIW. It is worthwhile to include alternatives you don't agree with in the very early drafts. Give them a paragraph, describe them briefly etc. This forces either solutions, demonstrations of incorrectness, demonstrations of correctness etc. all of which can also be incorporated to avoid repeatedly revisiting those things that either work or don't work. Peter 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 j9HEdYL18090 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:39:35 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2989B8371E for <rbridge@postel.org>; Mon, 17 Oct 2005 16:39:28 +0200 (CEST) Received: from [163.117.55.166] (unknown [163.117.55.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 9C19E83705 for <rbridge@postel.org>; Mon, 17 Oct 2005 16:39:27 +0200 (CEST) Message-ID: <4353B7A0.3080206@it.uc3m.es> Date: Mon, 17 Oct 2005 16:39:28 +0200 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: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> <435081B0.2040200@isi.edu> <4352DE39.4040305@sun.com> <43537C62.2040900@it.uc3m.es> <4353B2C2.7040009@isi.edu> In-Reply-To: <4353B2C2.7040009@isi.edu> 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] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:40:32 -0000 Status: RO Content-Length: 3090 Joe Touch wrote: >Guillermo Ib??ez wrote: > > >>I agree completely with Radia and I would add three more arguments in >>favour of Rbridge protocol separation from spanning tree protocols: >>- If Rbridges are succesful, the bridges spanning trees will be legacy >>in the long term, or will tend to be excluded from the core of the >>campus network due to its much lower performance in terms of congestion, >>path length and infrastructure usage. >> >> > >rbridges still rely on spanning trees at the edge; otherwise, we're >limited to 'make sure you don't wire things in a ring' like we are with >hubs. > >further, rbridges still rely on bridges as transits in the core. > > > Sorry, I agree on both sentences, but I do not understand the argument. >>- Coordination of the Rbridges protocol is not with one ST protocol but >>with TWO spanning tree protocols: STP (legacy, and slow) and RSTP >>(standard, faster). They have different mechanisms for convergence: wait >>a timer long enough to converge and "wavefront" enabling of ports >>downstream from the root bridge respectively. There is also a limit on >>the maximum diameter of spanning trees (related with the timer use) that >>should be taken into account by those in favour of big size spanning trees. >> >> > > > >>-Rbridges will be standardized by IETF, RSTP is under IEEE control. The >>risk of separate evolution exists. Although coordination IEEE-IETF >>works, it is better not to create interdependencies if they can be avoided. >>Guillermo >> >> > >That's a good reason NOT to assume the IETF can force only one system on >an L2 to be privileged and be allowed to BLOCK. > > (I copy here my previous message on the PARTICIPATE ROLE) Sorry, I did not follow the whole discussion on the BLOCK / TRANSPARENT / PARTICIPATE. My understanding is that rbridges can participate in the spanning tree they are attached to but do not forward BPDUs. Each port emits BPDUs based solely on its port information, opposite to the standard stp operation , where the bridge builds the BPDUs to be transmitted based on information collected from all bridge ports and selecting the best BPDU, thus containing the distance to root bridge. I would call this mode PARTICIPATE PER PORT. Rbridge ports should announce themselves as designated ports of Rbridge (IS-IS Designated Bridge acting as STP root bridge). The Rbridge ports will be in role Designated if they win the competition for the link or in Back-Up or Alternate role (that means blocked) if they lost the competition of best BPDU heard in the local link. They would never be in Root port role. Regarding BLOCK, it seems to be a decision of the network administrator, like when deciding not to enable spanning tree protocol ( I did not follow the discussion, may be I miss the point). Guillermo >Joe > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 j9HEWAL15450 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:32:10 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00MEVDPG6T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:32:04 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00DX5DPGU100@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:32:04 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [24.19.161.186]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 17 Oct 2005 07:32:04 -0700 Date: Mon, 17 Oct 2005 07:32:04 -0700 From: Radia.Perlman@sun.com To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <28ec46276960.43535374@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA)" Content-language: en X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:32:26 -0000 Status: RO Content-Length: 2588 This is a multi-part message in MIME format. --Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline We pick block because things will converge much more quickly. With blocking: The spanning tree domains are smaller, and therefore will converge more quickly. There is no feedback between the RBridge algorithm wormholing BPDUs into random places within a spanning tree, confusing the spanning tree convergence. ******* With forwarding, or sometimes forwarding based on configuration (I'm not sure what people are proposing: a) things will converge much more slowly b) there are scary dependencies between bridge spanning tree and RBridges algorithms c) no advantage as far as I can see. I don't know why we are discussing this. Radia --Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA) Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enig6DDB1E9D7A4186DB999B949C --------------enig6DDB1E9D7A4186DB999B949C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: > This lack of understanding of the DRs seems to be the cause of a lot > of this debate. IMO, it's the belief that there will only ever be one DR or DR-like (BLOCKing) device. I agree that this all works when it works. > Also, the 'problems' that people are attributing to blocking and not > processing BPDUs [BLOCK] are also 'problems' when no STP is running. 'problems'? (why the quotes?) OK, let's just shut off spanning tree in bridges and it all works just fine now? Now I'm *really* confused. AFAICT, this all works when there is at most one rbridge campus in an L2. WHEN (note the use of 'when', not 'if', since there's *nothing* that can be done to enforce this) this isn't the case, the following problems arise: a) there is no way to detect the error b) loops *will* occur If we want to say "BLOCK *MAY* work, but *MAY* silently fail", and "PARTICIPATE and TRANSPARENT will always work with current standards", that's fine (and, AFAICT, true), but I also don't see how we pick BLOCK as a default in that case. Joe --------------enig6DDB1E9D7A4186DB999B949C-- --Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge --Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA)-- 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 j9HEREL13634 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:27:14 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00MELDH96T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:27:09 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IOI00DW5DH9U000@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 17 Oct 2005 07:27:09 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [24.19.161.186]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 17 Oct 2005 07:27:09 -0700 Date: Mon, 17 Oct 2005 07:27:09 -0700 From: Radia.Perlman@sun.com To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <28e2abaf5cf9.4353524d@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 14:27:27 -0000 Status: RO Content-Length: 5003 Yes, the intention is to do optimized distribution of IP-based multicast by using a) per-ingress Rbridge tree, and b) filtering of that tree based on snooping on IGMP Radia ----- Original Message ----- From: Ganesh CS <gsankara@cisco.com> Date: Monday, October 17, 2005 6:14 am Subject: Re: [rbridge] Treating broadcast addresses > What about IP subnet based broadcasts, how will they be supported > by > rbridges ? > Will it be more on lines of subnet based multicast instead of > broadcast > in rbridge network ? > > -Ganesh > > Vishwas Manral wrote: > > > Hi Rute, > > > > > > > > Thanks for the reply. I am clearer now. > > > > > > > > If the root election is done at run time (like DR election in IS- > IS), > > it could mean that the Root could change often. If we had a > sticky > > Root election (like a DR election in OSPF) it could mean that the > root > > selection would take time to converge. > > > > > > > > Thanks again, > > > > Vishwas > > > > ------------------------------------------------------------------ > ------ > > > > *From:* rbridge-bounces@postel.org [rbridge-bounces@postel.org] > > *On Behalf Of *Sofia, Rute > > *Sent:* Monday, October 17, 2005 5:23 PM > > *To:* Developing a hybrid router/bridge. > > *Subject:* Re: [rbridge] Treating broadcast addresses > > > > > > > > Vishwas, > > > > > > > > Suppose you are speaking about the ST that Rbridges use to > perform > > broadcast. You don't need root election: the info provided by > LSPs is > > enough to build the ST. > > > > > > > > Regards, > > > > Rute > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > *From:* rbridge-bounces@postel.org > > [rbridge-bounces@postel.org] *On Behalf Of *Vishwas Manral > > *Sent:* Monday, October 17, 2005 1:27 PM > > *To:* Developing a hybrid router/bridge. > > *Subject:* Re: [rbridge] Treating broadcast addresses > > > > Hi Rute, > > > > > > > > Would this also mean Root-Election? What about convergence of > this> tree? > > > > > > > > Thanks, > > > > Vishwas > > > > -------------------------------------------------------------- > ---------- > > > > *From:* rbridge-bounces@postel.org > > [rbridge-bounces@postel.org] *On Behalf Of *Sofia, Rute > > *Sent:* Monday, October 17, 2005 4:36 PM > > *To:* Developing a hybrid router/bridge. > > *Subject:* Re: [rbridge] Treating broadcast addresses > > > > > > > > Vishwas, > > > > > > > > based on the information exchanged by LSPs you can simply > compute> the ST locally. The key here is the choice of the > root. This can > > also be passed along by IS-IS... > > > > > > > > Regards, > > > > Rute > > > > > > > > Hi, > > > > > > > > My question is more like, how would we build a spanning tree > > for broadcast using IS-IS? > > > > > > > > We need a globally coordinated tree like STP and not like > the> way IS-IS computes it. Would we require, changes to the > > spanning tree computation itself? > > > > > > > > Thanks, > > > > Vishwas > > > > ---------------------------------------------------------- > -------------- > > > > *From:* rbridge-bounces@postel.org > > [rbridge-bounces@postel.org] *On Behalf Of *Vishwas Manral > > *Sent:* Monday, October 17, 2005 11:41 AM > > *To:* Developing a hybrid router/bridge. > > *Subject:* [rbridge] Treating broadcast addresses > > > > > > > > Hi, > > > > > > > > I had a doubt about treatment of broadcast addresses. > > > > > > > > Currently using STP we have one tree and ports are blocked/ > > forwarding, so packets cannot loop irrespective of > destination> addresses. In IS-IS protocol, we use ports > based on > > destination address and no ports are blocked or > unblocked. But > > if the destination address is FF-FF-FF-FF-FF-FF we could end > > in a forwarding loop. How would we get over it? > > > > > > > > Would we still allow broadcast destination address > packets to > > be forwarded? It is like preventing flooding loops in a case > > where we have a global broadcast IP address, which is > > forwarded to all attached routers. Am I missing the point > all> together? > > > > > > > > Thanks, > > > > Vishwas > > > > > > > >------------------------------------------------------------------- > ----- > > > >_______________________________________________ > >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 [70.193.77.160] (160.sub-70-193-77.myvzw.com [70.193.77.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HEQkL13522; Mon, 17 Oct 2005 07:26:46 -0700 (PDT) Message-ID: <4353B4A0.1000309@isi.edu> Date: Mon, 17 Oct 2005 07:26:40 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213D00@zcarhxm2.corp.nortel.co m> <4353966C.6020105@isi.edu> <B92758A146683CE118088CC3@B50854F0A9192E8EC6CDA126> In-Reply-To: <B92758A146683CE118088CC3@B50854F0A9192E8EC6CDA126> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65AC83E92982DC8888EE3ACC" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:27:28 -0000 Status: RO Content-Length: 1520 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig65AC83E92982DC8888EE3ACC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > > --On 17. oktober 2005 05:17 -0700 Joe Touch <touch@ISI.EDU> wrote: > >> WHEN (note the use of 'when', not 'if', since there's *nothing* that can >> be done to enforce this) this isn't the case, the following problems >> arise: >> >> a) there is no way to detect the error >> >> b) loops *will* occur > > > You know, I really can't tell whether this is true or not without > looking at the protocol specification that says how the RBridges detect > each other. > > Should this discussion wait for the drafts to come out? As someone trying to write the drafts, I'm trying to understand the terminology that will determine this. I have a MUCH better idea of how to explain things now - whether I agree with them at all levels or not, so this discussion IS helping, FWIW. Joe --------------enig65AC83E92982DC8888EE3ACC 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDU7SgE5f5cImnZrsRAkHyAJwJcfU3HMfv0Y+PhldPgEYeIUZKrgCfWd51 /FXzvWx7qusoIr4cAwktcQM= =x+GH -----END PGP SIGNATURE----- --------------enig65AC83E92982DC8888EE3ACC-- Received: from [70.193.77.160] (160.sub-70-193-77.myvzw.com [70.193.77.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HEMNL11928; Mon, 17 Oct 2005 07:22:24 -0700 (PDT) Message-ID: <4353B399.70306@isi.edu> Date: Mon, 17 Oct 2005 07:22:17 -0700 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: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <200510171231.j9HCVF3W002877@lion.seas.upenn.edu> In-Reply-To: <200510171231.j9HCVF3W002877@lion.seas.upenn.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81AB87D6717B80F53ED954EF" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:23:44 -0000 Status: RO Content-Length: 1642 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81AB87D6717B80F53ED954EF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > AFAICT, this all works when there is at most one rbridge campus in an L2. > > [Saikat] I think that the assumption (definition) is that if two RBridges > are connected directly (i.e. no IP router in between), then they are parts > of a single campus, thus must talk to each other. If that is true, then how > would you have more than one campuses that are not separated by an IP > router? You won't - the rbridge campuses will merge. But we're the IETF, and we're making 'rbridges', which will BLOCK. Let's say the IEEE decides to allow another group to make 'sbridges', which also decide to BLOCK. Now you can have an rbridge and an sbridge in the same L2 (how do you know you don't?). They form an undetectable, uncorrectable loop. -- I.e. - this all works only if everyone plays by OUR rules. Since we're NOT the IEEE, how is it that we can decide to create a protocol that relies on us being the ONLY exception? Joe --------------enig81AB87D6717B80F53ED954EF 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDU7OZE5f5cImnZrsRAjsKAJ9fUt8xJ4gvB9joAVfCuR9VU1MVcwCg2U4Y OaVyY+PYgr7cdaqBNnSj3Gk= =//2g -----END PGP SIGNATURE----- --------------enig81AB87D6717B80F53ED954EF-- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HEJgL11419 for <rbridge@postel.org>; Mon, 17 Oct 2005 07:19:43 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 227A525808E for <rbridge@postel.org>; Mon, 17 Oct 2005 16:18:33 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22845-02 for <rbridge@postel.org>; Mon, 17 Oct 2005 16:18:25 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 291B1258080 for <rbridge@postel.org>; Mon, 17 Oct 2005 16:18:24 +0200 (CEST) Date: Mon, 17 Oct 2005 16:05:08 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <B92758A146683CE118088CC3@B50854F0A9192E8EC6CDA126> In-Reply-To: <4353966C.6020105@isi.edu> References: <713043CE8B8E1348AF3C546DBE02C1B405213D00@zcarhxm2.corp.nortel.co m> <4353966C.6020105@isi.edu> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========AD867A26ABED09D99B9B==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:20:25 -0000 Status: RO Content-Length: 1060 --==========AD867A26ABED09D99B9B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 17. oktober 2005 05:17 -0700 Joe Touch <touch@ISI.EDU> wrote: > WHEN (note the use of 'when', not 'if', since there's *nothing* that can > be done to enforce this) this isn't the case, the following problems > arise: > > a) there is no way to detect the error > > b) loops *will* occur You know, I really can't tell whether this is true or not without looking=20 at the protocol specification that says how the RBridges detect each other. Should this discussion wait for the drafts to come out? Harald --==========AD867A26ABED09D99B9B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDU6+UOMj+2+WY0F4RAkEMAJ4ov4AHO7j8XcSTnOc5ufHnQJwi7ACgrIMN MV76jFjqRERtusKw0lBrHwQ= =jfPJ -----END PGP SIGNATURE----- --==========AD867A26ABED09D99B9B==========-- Received: from [70.193.77.160] (160.sub-70-193-77.myvzw.com [70.193.77.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HEIlL11335; Mon, 17 Oct 2005 07:18:48 -0700 (PDT) Message-ID: <4353B2C2.7040009@isi.edu> Date: Mon, 17 Oct 2005 07:18:42 -0700 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> References: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> <435081B0.2040200@isi.edu> <4352DE39.4040305@sun.com> <43537C62.2040900@it.uc3m.es> In-Reply-To: <43537C62.2040900@it.uc3m.es> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F276645051F73836010D8E8" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 14:19:55 -0000 Status: RO Content-Length: 2276 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F276645051F73836010D8E8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guillermo Ib=E1=F1ez wrote: > I agree completely with Radia and I would add three more arguments in=20 > favour of Rbridge protocol separation from spanning tree protocols: > - If Rbridges are succesful, the bridges spanning trees will be legacy = > in the long term, or will tend to be excluded from the core of the=20 > campus network due to its much lower performance in terms of congestion= ,=20 > path length and infrastructure usage. rbridges still rely on spanning trees at the edge; otherwise, we're limited to 'make sure you don't wire things in a ring' like we are with hubs. further, rbridges still rely on bridges as transits in the core. > - Coordination of the Rbridges protocol is not with one ST protocol but= =20 > with TWO spanning tree protocols: STP (legacy, and slow) and RSTP=20 > (standard, faster). They have different mechanisms for convergence: wai= t=20 > a timer long enough to converge and "wavefront" enabling of ports=20 > downstream from the root bridge respectively. There is also a limit on= =20 > the maximum diameter of spanning trees (related with the timer use) tha= t=20 > should be taken into account by those in favour of big size spanning tr= ees. > -Rbridges will be standardized by IETF, RSTP is under IEEE control. The= =20 > risk of separate evolution exists. Although coordination IEEE-IETF=20 > works, it is better not to create interdependencies if they can be avo= ided. > Guillermo That's a good reason NOT to assume the IETF can force only one system on an L2 to be privileged and be allowed to BLOCK. Joe --------------enig4F276645051F73836010D8E8 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDU7LCE5f5cImnZrsRAkUKAKDa9nUkbB4kznzUu4DMQQyIQBHsZwCgxEKh WQHCU3ybq6xPFgnLgpI0LA4= =6+7/ -----END PGP SIGNATURE----- --------------enig4F276645051F73836010D8E8-- Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HDk1L02428 for <rbridge@postel.org>; Mon, 17 Oct 2005 06:46:01 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9HDk0Uj004240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Oct 2005 09:46:00 -0400 Message-Id: <200510171346.j9HDk0Uj004240@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Radia Perlman'" <Radia.Perlman@sun.com>, "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 17 Oct 2005 09:46:09 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <4352F43B.3050109@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXStClfuco1w5ITRG20Nmi+oWzX6wAaz5Tg X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 17 Oct 2005 13:46:26 -0000 Status: RO Content-Length: 5471 First of all, I totally agree with you that there should be multiple small spanning trees glued by RBridge networks instead of a global huge spanning tree. My point was slightly different, though. In the mechanism you pointed out (hearing hallos from other RBridges), the amount of time a temporary loop persists would depend on the time interval between hallo messages sent by RBridges (what is the default value?). If two RBridges are connected by a physical link, then this is probably the only way the RBridges can detect the loop. However, if the underlying "link" is actually a bridged network (spanning tree), then the RBridges would have more information. For example, when RBridges see topology change BPDU's (or something similar), then they may deduct the possibility of a loop formation and they may increase the sending rate of hallo messages. In short, the RBridges are privileged to be in a position to make additional observations (BPDUs) and, in my humble opinion, they ought to use it. -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@sun.com] Sent: Sunday, October 16, 2005 8:46 PM To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread The scenario you mention is where there is temporarily two Designated RBridges (DRs), because two links were merged. The DRs will notice this when they start seeing each other's IS-IS Hello messages, and that will break the loop. I don't think this case is that much of a problem, and certainly would not be helped by trying to run a big global spanning tree. The big global spanning tree would converge much slower than the RBridge DR election protocol would. So attempting to avoid a temporary loop when two bridged domains are merged, by running a big global instance of the spanning tree algorithm, will not solve the problem, and will actually make things worse. Radia Saikat Ray wrote: >It is probably a standard scenario in IS-IS protocol (and consequently a >standard solution is known), but I was thinking that if the RBridges >disregards BPDUs entirely, then in some situations loops may form for some >period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed >entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges for >the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop >in the system. Now suppose that a physical link (or a legacy bridge) is >added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$. >This addition will trigger a new Spanning tree computation, which will >result into a single spanning tree that spans the nodes of $T_1$ and $T_2$. >At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a >single "link" and until one of the RBridge gets "de-designated", there would >exist a loop. Two questions arise in my mind: (i) how fast would that >"de-designation" process be? And (ii) would it be useful (i.e. would it >accelerate the convergence) if RBridges "listen" to the BPDUs? > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Radia Perlman >Sent: Sunday, October 16, 2005 7:12 PM >To: Developing a hybrid router/bridge. >Subject: [rbridge] Time to summarize "forward or block" BPDU thread > >It looks like this thread was discussed with two different subject >lines, and it's also >gone on long enough it's time for someone to summarize it. > >I strongly believe that things will be more stable if RBridges do NOT >forward BPDUs...that >we decouple the protocols. > >That TRILL is kind of like a layer between bridging and routing. > >If RBridges do not forward BPDUs, then whether or not the TRILL link >state protocol is >converged, it won't affect the little spanning tree inside a particular >bridged segment. > >That way, the little spanning trees will converge as quickly as possible >(because it's small), >and cannot possibly be disrupted by RBridges wormholing BPDUs. > >I do not understand the reasons why people want to forward BPDUs. I >think the arguments (which >I may not be presenting fairly because I don't understand them) are: >a) you'll get a more optimal combined spanning tree on which >unknown/broadcast frames will >be sent if it is one global spanning tree, rather than little >independent spanning trees hooked together >by the independently computed spanning tree calculated by IS-IS. >b) forwarding BPDUs, and having a global spanning tree, will prevent loops. > >I strongly disagree with both those arguments. For a) What do people >think is more optimal about a tree >computed that way vs having independent trees inside each bridged >island? And besides, there isn't >a single spanning tree...it's a spanning tree per ingress RBridge. >For b) no...I believe that having both the RBridge algorithm and the >bridge algorithm feeding into >each other will create much slower convergence. > >If I haven't summarized correctly, then someone else can try to capture >the arguments, but I do >think we should merge discussion under one subject line, and restart >with a summary. > >Radia > >_______________________________________________ >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 ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HDFaL25042 for <rbridge@postel.org>; Mon, 17 Oct 2005 06:15:36 -0700 (PDT) Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 17 Oct 2005 18:57:46 -0700 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HDEeYu012163 for <rbridge@postel.org>; Mon, 17 Oct 2005 13:14:58 GMT Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 18:44:49 +0530 Received: from [10.77.203.69] ([10.77.203.69]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 18:44:48 +0530 Message-ID: <4353A3C8.9060600@cisco.com> Date: Mon, 17 Oct 2005 18:44:48 +0530 From: Ganesh CS <gsankara@cisco.com> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B2A6E4A9@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B2A6E4A9@sinett-sbs.SiNett.LAN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2005 13:14:48.0869 (UTC) FILETIME=[C04C2D50:01C5D31C] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gsankara@cisco.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 13:16:26 -0000 Status: RO Content-Length: 4161 What about IP subnet based broadcasts, how will they be supported by rbridges ? Will it be more on lines of subnet based multicast instead of broadcast in rbridge network ? -Ganesh Vishwas Manral wrote: > Hi Rute, > > > > Thanks for the reply. I am clearer now. > > > > If the root election is done at run time (like DR election in IS-IS), > it could mean that the Root could change often. If we had a sticky > Root election (like a DR election in OSPF) it could mean that the root > selection would take time to converge. > > > > Thanks again, > > Vishwas > > ------------------------------------------------------------------------ > > *From:* rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > *On Behalf Of *Sofia, Rute > *Sent:* Monday, October 17, 2005 5:23 PM > *To:* Developing a hybrid router/bridge. > *Subject:* Re: [rbridge] Treating broadcast addresses > > > > Vishwas, > > > > Suppose you are speaking about the ST that Rbridges use to perform > broadcast. You don't need root election: the info provided by LSPs is > enough to build the ST. > > > > Regards, > > Rute > > > > > > ------------------------------------------------------------------------ > > *From:* rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] *On Behalf Of *Vishwas Manral > *Sent:* Monday, October 17, 2005 1:27 PM > *To:* Developing a hybrid router/bridge. > *Subject:* Re: [rbridge] Treating broadcast addresses > > Hi Rute, > > > > Would this also mean Root-Election? What about convergence of this > tree? > > > > Thanks, > > Vishwas > > ------------------------------------------------------------------------ > > *From:* rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] *On Behalf Of *Sofia, Rute > *Sent:* Monday, October 17, 2005 4:36 PM > *To:* Developing a hybrid router/bridge. > *Subject:* Re: [rbridge] Treating broadcast addresses > > > > Vishwas, > > > > based on the information exchanged by LSPs you can simply compute > the ST locally. The key here is the choice of the root. This can > also be passed along by IS-IS... > > > > Regards, > > Rute > > > > Hi, > > > > My question is more like, how would we build a spanning tree > for broadcast using IS-IS? > > > > We need a globally coordinated tree like STP and not like the > way IS-IS computes it. Would we require, changes to the > spanning tree computation itself? > > > > Thanks, > > Vishwas > > ------------------------------------------------------------------------ > > *From:* rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] *On Behalf Of *Vishwas Manral > *Sent:* Monday, October 17, 2005 11:41 AM > *To:* Developing a hybrid router/bridge. > *Subject:* [rbridge] Treating broadcast addresses > > > > Hi, > > > > I had a doubt about treatment of broadcast addresses. > > > > Currently using STP we have one tree and ports are blocked/ > forwarding, so packets cannot loop irrespective of destination > addresses. In IS-IS protocol, we use ports based on > destination address and no ports are blocked or unblocked. But > if the destination address is FF-FF-FF-FF-FF-FF we could end > in a forwarding loop. How would we get over it? > > > > Would we still allow broadcast destination address packets to > be forwarded? It is like preventing flooding loops in a case > where we have a global broadcast IP address, which is > forwarded to all attached routers. Am I missing the point all > together? > > > > Thanks, > > Vishwas > > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HCVGL11835 for <rbridge@postel.org>; Mon, 17 Oct 2005 05:31:16 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9HCVF3W002877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Mon, 17 Oct 2005 08:31:15 -0400 Message-Id: <200510171231.j9HCVF3W002877@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 17 Oct 2005 08:31:24 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <4353966C.6020105@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXTFQynEN7JfuMEQ9+zK+o4dhShVgAASSCw X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 17 Oct 2005 12:31:25 -0000 Status: RO Content-Length: 380 AFAICT, this all works when there is at most one rbridge campus in an L2. [Saikat] I think that the assumption (definition) is that if two RBridges are connected directly (i.e. no IP router in between), then they are parts of a single campus, thus must talk to each other. If that is true, then how would you have more than one campuses that are not separated by an IP router? Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HCRcL10847 for <rbridge@postel.org>; Mon, 17 Oct 2005 05:27:38 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9HCRbtc002747 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Mon, 17 Oct 2005 08:27:38 -0400 Message-Id: <200510171227.j9HCRbtc002747@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Mon, 17 Oct 2005 08:27:46 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <BB6D74C75CC76A419B6D6FA7C38317B2A6E4A3@sinett-sbs.SiNett.LAN> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDygAJmWnAAAClQoAAAKY1sAACJ+8g X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9HCRcL10847 Subject: Re: [rbridge] Treating broadcast addresses X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 17 Oct 2005 12:28:34 -0000 Status: RO Content-Length: 2286 You do not even need a ?root? really! Each RBridge has the *global* topology. They can simply each run Kruskal's algorithm and compute the (nee *a*) minimum weight spanning tree (which is probably the right thing to do anyway for broadcast purposes). ________________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 7:27 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses Hi Rute, Would this also mean Root-Election? What about convergence of this tree? Thanks, Vishwas ________________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Sofia, Rute Sent: Monday, October 17, 2005 4:36 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses Vishwas, ? based on the information exchanged by LSPs you can simply compute the ST locally. The key here is the choice of the root. This can also be passed along by IS-IS... ? Regards, Rute ? Hi, My question is more like, how would we build a spanning tree for broadcast using IS-IS? We need a globally coordinated tree like STP and not like the way IS-IS computes it. Would we require, changes to the spanning tree computation itself? Thanks, Vishwas ________________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 11:41 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Treating broadcast addresses Hi, I had a doubt about treatment of broadcast addresses. Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? Thanks, Vishwas Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HCOIL09821 for <rbridge@postel.org>; Mon, 17 Oct 2005 05:24:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D315.AF253BD8" Date: Mon, 17 Oct 2005 05:27:30 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2A6E4A9@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Treating broadcast addresses Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDygAJmWnAAAClQoAAAKY1sAAA/XQwAAEmgaA= From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 12:24:58 -0000 Status: RO Content-Length: 19063 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D315.AF253BD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rute, =20 Thanks for the reply. I am clearer now. =20 If the root election is done at run time (like DR election in IS-IS), it could mean that the Root could change often. If we had a sticky Root election (like a DR election in OSPF) it could mean that the root selection would take time to converge. =20 Thanks again, Vishwas ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Sofia, Rute Sent: Monday, October 17, 2005 5:23 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses =20 Vishwas, =20 Suppose you are speaking about the ST that Rbridges use to perform broadcast. You don't need root election: the info provided by LSPs is enough to build the ST. =20 Regards, Rute =20 =20 =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 1:27 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses Hi Rute, =20 Would this also mean Root-Election? What about convergence of this tree? =20 Thanks, Vishwas =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Sofia, Rute Sent: Monday, October 17, 2005 4:36 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses =20 Vishwas, =20 based on the information exchanged by LSPs you can simply compute the ST locally. The key here is the choice of the root. This can also be passed along by IS-IS... =20 Regards, Rute =20 Hi, =20 My question is more like, how would we build a spanning tree for broadcast using IS-IS?=20 =20 We need a globally coordinated tree like STP and not like the way IS-IS computes it. Would we require, changes to the spanning tree computation itself? =20 Thanks, Vishwas =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 11:41 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Treating broadcast addresses =20 Hi, =20 I had a doubt about treatment of broadcast addresses. =20 Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? =20 Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5D315.AF253BD8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* 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 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle19 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi = Rute,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks for the reply. I am clearer = now.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>If the root election is done at run = time (like DR election in IS-IS), it could mean that the Root could change often. = If we had a sticky Root election (like a DR election in OSPF) it could mean = that the root selection would take time to converge.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks = again,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>= <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Sofia, Rute<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 5:23 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Vishwas,</span></font><o:p></o:p></p= > <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Suppose you are speaking about the = ST that Rbridges use to perform broadcast. You don't need root election: the = info provided by LSPs is enough to build the ST.</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Regards,</span></font><o:p></o:p></p= > <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Rute</span></font><o:p></o:p></p> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <blockquote style=3D'border:none;border-left:solid blue = 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'= > <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1> </span></font></div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 = face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa= n></font></b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt;font-family:Tahoma'> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Vishwas Manral<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 1:27 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi = Rute,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Would this also mean Root-Election? = What about convergence of this tree?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>= <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>= <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Sofia, Rute<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 4:36 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = tabIndex=3D"0" style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x" w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Vishwas,</span></font><o:p></o:p></p= > <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>based on the information exchanged = by LSPs you can simply compute the ST locally. The key here is the choice of the = root. This can also be passed along by IS-IS...</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Regards,</span></font><o:p></o:p></p= > <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Rute</span></font><o:p></o:p></p> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <blockquote style=3D'border:none;border-left:solid blue = 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'= > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>My question is more like, how would = we build a spanning tree for broadcast using IS-IS? = <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>We need a globally coordinated tree = like STP and not like the way IS-IS computes it. Would we require, changes to = the spanning tree computation itself?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>= <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>= <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> = rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span = style=3D'font-weight:bold'>On Behalf Of </span></b>Vishwas Manral<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 11:41 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = tabIndex=3D"0" style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x" w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>I had a doubt about treatment of broadcast = addresses.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Currently using STP we have one tree and ports are = blocked/ forwarding, so packets cannot loop irrespective of destination = addresses. In IS-IS protocol, we use ports based on destination address and no ports = are blocked or unblocked. But if the destination address is = FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over = it?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Would we still allow broadcast destination address = packets to be forwarded? It is like preventing flooding loops in a case where we = have a global broadcast IP address, which is forwarded to all attached routers. = Am I missing the point all together?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Thanks,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Vishwas<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </blockquote> </blockquote> </div> </body> </html> ------_=_NextPart_001_01C5D315.AF253BD8-- Received: from [70.193.49.253] (253.sub-70-193-49.myvzw.com [70.193.49.253]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HCI0L08456; Mon, 17 Oct 2005 05:18:00 -0700 (PDT) Message-ID: <4353966C.6020105@isi.edu> Date: Mon, 17 Oct 2005 05:17:48 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213D00@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213D00@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6DDB1E9D7A4186DB999B949C" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 12:18:28 -0000 Status: RO Content-Length: 1763 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6DDB1E9D7A4186DB999B949C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: > This lack of understanding of the DRs seems to be the cause of a lot > of this debate. IMO, it's the belief that there will only ever be one DR or DR-like (BLOCKing) device. I agree that this all works when it works. > Also, the 'problems' that people are attributing to blocking and not > processing BPDUs [BLOCK] are also 'problems' when no STP is running. 'problems'? (why the quotes?) OK, let's just shut off spanning tree in bridges and it all works just fine now? Now I'm *really* confused. AFAICT, this all works when there is at most one rbridge campus in an L2. WHEN (note the use of 'when', not 'if', since there's *nothing* that can be done to enforce this) this isn't the case, the following problems arise: a) there is no way to detect the error b) loops *will* occur If we want to say "BLOCK *MAY* work, but *MAY* silently fail", and "PARTICIPATE and TRANSPARENT will always work with current standards", that's fine (and, AFAICT, true), but I also don't see how we pick BLOCK as a default in that case. Joe --------------enig6DDB1E9D7A4186DB999B949C 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDU5ZyE5f5cImnZrsRAvzPAJ0YO70TV0J0KYOlr9dTPHAa3ORc2gCfe3/g DyNi9X3Z1iO9CcHvNsbRanI= =ZYyc -----END PGP SIGNATURE----- --------------enig6DDB1E9D7A4186DB999B949C-- Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HBquL02657 for <rbridge@postel.org>; Mon, 17 Oct 2005 04:52:57 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9HBqoZm031850 for <rbridge@postel.org>; Mon, 17 Oct 2005 13:52:50 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9HBqnLZ013605 for <rbridge@postel.org>; Mon, 17 Oct 2005 13:52:50 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 13:52:48 +0200 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_01C5D311.4B954E04" Date: Mon, 17 Oct 2005 13:52:48 +0200 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CEB8E@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Treating broadcast addresses Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDygAJmWnAAAClQoAAAKY1sAAA/XQw From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 17 Oct 2005 11:52:48.0868 (UTC) FILETIME=[4BBF9A40:01C5D311] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rute.sofia@siemens.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 11:53:51 -0000 Status: RO Content-Length: 15429 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D311.4B954E04 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Vishwas, =20 Suppose you are speaking about the ST that Rbridges use to perform broadcast. You don't need root election: the info provided by LSPs is enough to build the ST. =20 Regards, Rute =20 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 1:27 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses =09 =09 Hi Rute, =20 Would this also mean Root-Election? What about convergence of this tree? =20 Thanks, Vishwas =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Sofia, Rute Sent: Monday, October 17, 2005 4:36 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses =20 Vishwas, =20 based on the information exchanged by LSPs you can simply compute the ST locally. The key here is the choice of the root. This can also be passed along by IS-IS... =20 Regards, Rute =20 Hi, =20 My question is more like, how would we build a spanning tree for broadcast using IS-IS?=20 =20 We need a globally coordinated tree like STP and not like the way IS-IS computes it. Would we require, changes to the spanning tree computation itself? =20 Thanks, Vishwas =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 11:41 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Treating broadcast addresses =20 Hi, =20 I had a doubt about treatment of broadcast addresses. =20 Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? =20 Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5D311.4B954E04 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR><!--[if !mso]> <STYLE> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </STYLE> <![endif]--><o:SmartTagType name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><!--[if !mso]> <STYLE> st1\:*{behavior:url(#default#ieooui) } </STYLE> <![endif]--> <STYLE> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* 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 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </STYLE> </HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Vishwas,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Suppose you are speaking about the ST that = Rbridges use to=20 perform broadcast. You don't need root election: the info provided by = LSPs is=20 enough to build the ST.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN = class=3D257455111-17102005></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Rute</FONT></SPAN></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> rbridge-bounces@postel.org=20 [mailto:rbridge-bounces@postel.org] <B>On Behalf Of </B>Vishwas=20 Manral<BR><B>Sent:</B> Monday, October 17, 2005 1:27 PM<BR><B>To:</B>=20 Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] = Treating=20 broadcast addresses<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20 Rute,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Would this = also mean=20 Root-Election? What about convergence of this=20 tree?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Thanks,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Vishwas<o:p></o:p></SPAN></FONT></P> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">From:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">=20 rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] = <B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Sofia, = Rute<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, October 17, 2005 = 4:36=20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> = <st1:PersonName=20 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20 tabIndex=3D0 w:st=3D"on">Developing a hybrid=20 router/bridge.</st1:PersonName><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [rbridge] Treating = broadcast=20 addresses</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial">Vishwas,</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">based on = the=20 information exchanged by LSPs you can simply compute the ST locally. = The key=20 here is the choice of the root. This can also be passed along by=20 IS-IS...</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial">Regards,</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial">Rute</SPAN></FONT><o:p></o:p></P> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt = 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: = medium none"> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Hi,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">My = question is more=20 like, how would we build a spanning tree for broadcast using IS-IS?=20 <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We need a = globally=20 coordinated tree like STP and not like the way IS-IS computes it. = Would we=20 require, changes to the spanning tree computation=20 itself?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Thanks,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Vishwas<o:p></o:p></SPAN></FONT></P> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">From:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">=20 rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] = <B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Vishwas = Manral<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, October 17, = 2005 11:41=20 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> = <st1:PersonName=20 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20 tabIndex=3D0 w:st=3D"on">Developing a hybrid=20 router/bridge.</st1:PersonName><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [rbridge] Treating = broadcast=20 addresses</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Hi,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I had a doubt about = treatment of=20 broadcast addresses.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently using STP we = have one=20 tree and ports are blocked/ forwarding, so packets cannot loop = irrespective=20 of destination addresses. In IS-IS protocol, we use ports based on=20 destination address and no ports are blocked or unblocked. But if = the=20 destination address is FF-FF-FF-FF-FF-FF we could end in a = forwarding loop.=20 How would we get over it?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Would we still allow = broadcast=20 destination address packets to be forwarded? It is like preventing = flooding=20 loops in a case where we have a global broadcast IP address, which = is=20 forwarded to all attached routers. Am I missing the point all=20 together?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Thanks,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Vishwas<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></BLOCKQUOTE= ></BODY></HTML> ------_=_NextPart_001_01C5D311.4B954E04-- Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HBOHL25586 for <rbridge@postel.org>; Mon, 17 Oct 2005 04:24:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D30D.4C5C9A1A" Date: Mon, 17 Oct 2005 04:27:28 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2A6E4A3@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Treating broadcast addresses Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDygAJmWnAAAClQoAAAKY1sA== From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 11:25:51 -0000 Status: RO Content-Length: 12456 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D30D.4C5C9A1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rute, =20 Would this also mean Root-Election? What about convergence of this tree? =20 Thanks, Vishwas ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Sofia, Rute Sent: Monday, October 17, 2005 4:36 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Treating broadcast addresses =20 Vishwas, =20 based on the information exchanged by LSPs you can simply compute the ST locally. The key here is the choice of the root. This can also be passed along by IS-IS... =20 Regards, Rute =20 Hi, =20 My question is more like, how would we build a spanning tree for broadcast using IS-IS?=20 =20 We need a globally coordinated tree like STP and not like the way IS-IS computes it. Would we require, changes to the spanning tree computation itself? =20 Thanks, Vishwas =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 11:41 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Treating broadcast addresses =20 Hi, =20 I had a doubt about treatment of broadcast addresses. =20 Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? =20 Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5D30D.4C5C9A1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* 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 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi = Rute,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Would this also mean Root-Election? = What about convergence of this tree?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>= <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>= <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Sofia, Rute<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 4:36 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Vishwas,</span></font><o:p></o:p></p= > <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>based on the information exchanged = by LSPs you can simply compute the ST locally. The key here is the choice of the = root. This can also be passed along by IS-IS...</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Regards,</span></font><o:p></o:p></p= > <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:blue'>Rute</span></font><o:p></o:p></p> <div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> </div> <blockquote style=3D'border:none;border-left:solid blue = 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'= > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>My question is more like, how would = we build a spanning tree for broadcast using IS-IS? = <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>We need a globally coordinated tree = like STP and not like the way IS-IS computes it. Would we require, changes to = the spanning tree computation itself?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>= <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>= <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> = rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span = style=3D'font-weight:bold'>On Behalf Of </span></b>Vishwas Manral<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 11:41 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = tabIndex=3D"0" style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x" w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>I had a doubt about treatment of broadcast = addresses.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Currently using STP we have one tree and ports are = blocked/ forwarding, so packets cannot loop irrespective of destination = addresses. In IS-IS protocol, we use ports based on destination address and no ports = are blocked or unblocked. But if the destination address is = FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over = it?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Would we still allow broadcast destination address = packets to be forwarded? It is like preventing flooding loops in a case where we = have a global broadcast IP address, which is forwarded to all attached routers. = Am I missing the point all together?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Thanks,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Vishwas<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </blockquote> </div> </body> </html> ------_=_NextPart_001_01C5D30D.4C5C9A1A-- Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HB6GL20794 for <rbridge@postel.org>; Mon, 17 Oct 2005 04:06:16 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9HB6BRR015111 for <rbridge@postel.org>; Mon, 17 Oct 2005 13:06:11 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9HB6AMr001599 for <rbridge@postel.org>; Mon, 17 Oct 2005 13:06:10 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 13:06:10 +0200 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_01C5D30A.C742E1AC" Date: Mon, 17 Oct 2005 13:06:09 +0200 Message-ID: <ECDC9C7BC7809340842C0E7FCF48C3937CEB8C@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Treating broadcast addresses Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDygAJmWnAAAClQoA= From: "Sofia, Rute" <rute.sofia@siemens.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 17 Oct 2005 11:06:10.0256 (UTC) FILETIME=[C7A54D00:01C5D30A] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rute.sofia@siemens.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 11:07:00 -0000 Status: RO Content-Length: 9943 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D30A.C742E1AC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Vishwas, =20 based on the information exchanged by LSPs you can simply compute the ST locally. The key here is the choice of the root. This can also be passed along by IS-IS... =20 Regards, Rute =20 Hi, =20 My question is more like, how would we build a spanning tree for broadcast using IS-IS?=20 =20 We need a globally coordinated tree like STP and not like the way IS-IS computes it. Would we require, changes to the spanning tree computation itself? =20 Thanks, Vishwas =09 ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 11:41 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Treating broadcast addresses =20 Hi, =20 I had a doubt about treatment of broadcast addresses. =20 Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? =20 Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5D30A.C742E1AC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR><!--[if !mso]> <STYLE> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </STYLE> <![endif]--><o:SmartTagType name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><!--[if !mso]> <STYLE> st1\:*{behavior:url(#default#ieooui) } </STYLE> <![endif]--> <STYLE> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* 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 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </STYLE> </HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Vishwas,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>based on the information exchanged by LSPs you = can simply=20 compute the ST locally. The key here is the choice of the root. This can = also be=20 passed along by IS-IS...</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Rute</FONT></SPAN></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Hi,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">My question = is more=20 like, how would we build a spanning tree for broadcast using IS-IS?=20 <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We need a = globally=20 coordinated tree like STP and not like the way IS-IS computes it. = Would we=20 require, changes to the spanning tree computation=20 itself?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Thanks,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: = Arial">Vishwas<o:p></o:p></SPAN></FONT></P> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">From:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">=20 rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] = <B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Vishwas = Manral<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, October 17, 2005 = 11:41=20 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> = <st1:PersonName=20 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20 tabIndex=3D0 w:st=3D"on">Developing a hybrid=20 router/bridge.</st1:PersonName><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [rbridge] Treating = broadcast=20 addresses</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Hi,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I had a doubt about = treatment of=20 broadcast addresses.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently using STP we = have one=20 tree and ports are blocked/ forwarding, so packets cannot loop = irrespective of=20 destination addresses. In IS-IS protocol, we use ports based on = destination=20 address and no ports are blocked or unblocked. But if the destination = address=20 is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we = get over=20 it?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Would we still allow = broadcast=20 destination address packets to be forwarded? It is like preventing = flooding=20 loops in a case where we have a global broadcast IP address, which is=20 forwarded to all attached routers. Am I missing the point all=20 together?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Thanks,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Vishwas<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM= L> ------_=_NextPart_001_01C5D30A.C742E1AC-- Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HAkOL15587 for <rbridge@postel.org>; Mon, 17 Oct 2005 03:46:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D308.017E57CB" Date: Mon, 17 Oct 2005 03:49:36 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2A6E49B@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Treating broadcast addresses Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDygAJmWnA From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 10:47:24 -0000 Status: RO Content-Length: 8031 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D308.017E57CB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 My question is more like, how would we build a spanning tree for broadcast using IS-IS?=20 =20 We need a globally coordinated tree like STP and not like the way IS-IS computes it. Would we require, changes to the spanning tree computation itself? =20 Thanks, Vishwas ________________________________ From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 11:41 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Treating broadcast addresses =20 Hi, =20 I had a doubt about treatment of broadcast addresses. =20 Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? =20 Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5D308.017E57CB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* 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 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>My question is more like, how would = we build a spanning tree for broadcast using IS-IS? <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>We need a globally coordinated tree = like STP and not like the way IS-IS computes it. Would we require, changes to = the spanning tree computation itself?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>= <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>= <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = style=3D'font-size:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Vishwas Manral<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, = 2005 11:41 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName = w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [rbridge] = Treating broadcast addresses</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hi,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>I had a doubt about treatment of broadcast = addresses.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Currently using STP we have one tree and ports are = blocked/ forwarding, so packets cannot loop irrespective of destination = addresses. In IS-IS protocol, we use ports based on destination address and no ports are = blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could = end in a forwarding loop. How would we get over = it?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Would we still allow broadcast destination address = packets to be forwarded? It is like preventing flooding loops in a case where we = have a global broadcast IP address, which is forwarded to all attached routers. = Am I missing the point all together?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Thanks,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Vishwas<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C5D308.017E57CB-- Received: from empathy.seas.upenn.edu (EMPATHY.seas.upenn.edu [158.130.41.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9HAglL14425 for <rbridge@postel.org>; Mon, 17 Oct 2005 03:42:48 -0700 (PDT) Received: from red.seas.upenn.edu (RED.seas.upenn.edu [158.130.64.176]) by empathy.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9HAghf1014818 for <rbridge@postel.org>; Mon, 17 Oct 2005 06:42:43 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.10/8.12.9) with ESMTP id j9HAgh7i000313 for <rbridge@postel.org>; Mon, 17 Oct 2005 06:42:43 -0400 (EDT) Received: from localhost (saikat@localhost) by red.seas.upenn.edu (8.12.10/8.12.9/Submit) with ESMTP id j9HAggGw000310 for <rbridge@postel.org>; Mon, 17 Oct 2005 06:42:43 -0400 (EDT) Date: Mon, 17 Oct 2005 06:42:42 -0400 (EDT) From: Saikat Ray <saikat@seas.upenn.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B2A6E45B@sinett-sbs.SiNett.LAN> Message-ID: <Pine.GSO.4.58.0510170639080.256@red.seas.upenn.edu> References: <BB6D74C75CC76A419B6D6FA7C38317B2A6E45B@sinett-sbs.SiNett.LAN> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: -2.82 ALL_TRUSTED X-Scanned-By: MIMEDefang 2.49 on 158.130.41.8 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 10:43:25 -0000 Status: RO Content-Length: 759 > Currently using STP we have one tree and ports are blocked/ forwarding, > so packets cannot loop irrespective of destination addresses. In IS-IS > protocol, we use ports based on destination address and no ports are > blocked or unblocked. But if the destination address is > FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get > over it? Broadcast packets are sent over a spanning tree (not computed by the STP) that spans the RBridges. > > > > Would we still allow broadcast destination address packets to be > forwarded? It is like preventing flooding loops in a case where we have > a global broadcast IP address, which is forwarded to all attached > routers. Am I missing the point all together? > > > > Thanks, > > Vishwas > > > > 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 j9HAQlL10563 for <rbridge@postel.org>; Mon, 17 Oct 2005 03:26:48 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BDDCD81F0A for <rbridge@postel.org>; Mon, 17 Oct 2005 12:26:41 +0200 (CEST) Received: from [163.117.139.50] (gibanez.it.uc3m.es [163.117.139.50]) by smtp03.uc3m.es (Postfix) with ESMTP id D571681F95 for <rbridge@postel.org>; Mon, 17 Oct 2005 12:26:40 +0200 (CEST) Message-ID: <43537C62.2040900@it.uc3m.es> Date: Mon, 17 Oct 2005 12:26:42 +0200 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: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> <435081B0.2040200@isi.edu> <4352DE39.4040305@sun.com> In-Reply-To: <4352DE39.4040305@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 10:27:25 -0000 Status: RO Content-Length: 3132 I agree completely with Radia and I would add three more arguments in favour of Rbridge protocol separation from spanning tree protocols: - If Rbridges are succesful, the bridges spanning trees will be legacy in the long term, or will tend to be excluded from the core of the campus network due to its much lower performance in terms of congestion, path length and infrastructure usage. - Coordination of the Rbridges protocol is not with one ST protocol but with TWO spanning tree protocols: STP (legacy, and slow) and RSTP (standard, faster). They have different mechanisms for convergence: wait a timer long enough to converge and "wavefront" enabling of ports downstream from the root bridge respectively. There is also a limit on the maximum diameter of spanning trees (related with the timer use) that should be taken into account by those in favour of big size spanning trees. -Rbridges will be standardized by IETF, RSTP is under IEEE control. The risk of separate evolution exists. Although coordination IEEE-IETF works, it is better not to create interdependencies if they can be avoided. Guillermo Radia Perlman wrote: >It looks like this thread was discussed with two different subject >lines, and it's also >gone on long enough it's time for someone to summarize it. > >I strongly believe that things will be more stable if RBridges do NOT >forward BPDUs...that >we decouple the protocols. > >That TRILL is kind of like a layer between bridging and routing. > >If RBridges do not forward BPDUs, then whether or not the TRILL link >state protocol is >converged, it won't affect the little spanning tree inside a particular >bridged segment. > >That way, the little spanning trees will converge as quickly as possible >(because it's small), >and cannot possibly be disrupted by RBridges wormholing BPDUs. > >I do not understand the reasons why people want to forward BPDUs. I >think the arguments (which >I may not be presenting fairly because I don't understand them) are: >a) you'll get a more optimal combined spanning tree on which >unknown/broadcast frames will >be sent if it is one global spanning tree, rather than little >independent spanning trees hooked together >by the independently computed spanning tree calculated by IS-IS. >b) forwarding BPDUs, and having a global spanning tree, will prevent loops. > >I strongly disagree with both those arguments. For a) What do people >think is more optimal about a tree >computed that way vs having independent trees inside each bridged >island? And besides, there isn't >a single spanning tree...it's a spanning tree per ingress RBridge. >For b) no...I believe that having both the RBridge algorithm and the >bridge algorithm feeding into >each other will create much slower convergence. > >If I haven't summarized correctly, then someone else can try to capture >the arguments, but I do >think we should merge discussion under one subject line, and restart >with a summary. > >Radia > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > > Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9H68HL08939 for <rbridge@postel.org>; Sun, 16 Oct 2005 23:08:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D2E1.272B876B" Date: Sun, 16 Oct 2005 23:11:28 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2A6E45B@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Treating broadcast addresses Thread-Index: AcXS4ZyA/579GrWeR9+ecEIzVjmDyg== From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: [rbridge] Treating broadcast addresses 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, 17 Oct 2005 06:08:27 -0000 Status: RO Content-Length: 4189 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D2E1.272B876B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I had a doubt about treatment of broadcast addresses. =20 Currently using STP we have one tree and ports are blocked/ forwarding, so packets cannot loop irrespective of destination addresses. In IS-IS protocol, we use ports based on destination address and no ports are blocked or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over it? =20 Would we still allow broadcast destination address packets to be forwarded? It is like preventing flooding loops in a case where we have a global broadcast IP address, which is forwarded to all attached routers. Am I missing the point all together? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5D2E1.272B876B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <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 {mso-style-type:personal-compose; 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;} --> </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,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>I had a doubt about treatment of broadcast = addresses.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Currently using STP we have one tree and ports are = blocked/ forwarding, so packets cannot loop irrespective of destination = addresses. In IS-IS protocol, we use ports based on destination address and no ports = are blocked or unblocked. But if the destination address is = FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get over = it?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Would we still allow broadcast destination address = packets to be forwarded? It is like preventing flooding loops in a case where we = have a global broadcast IP address, which is forwarded to all attached routers. = Am I missing the point all together?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Thanks,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Vishwas<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C5D2E1.272B876B-- Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9H1ASL07599 for <rbridge@postel.org>; Sun, 16 Oct 2005 18:10:28 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9H17f410398 for <rbridge@postel.org>; Sun, 16 Oct 2005 21:07:42 -0400 (EDT) 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: Sun, 16 Oct 2005 21:10:16 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213D00@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Time to summarize "forward or block" BPDU thread Thread-Index: AcXStIwo1Mam7iIYT0Gpclukgc34MwAASn6A From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9H1ASL07599 Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 01:11:49 -0000 Status: RO Content-Length: 5651 This lack of understanding of the DRs seems to be the cause of a lot of this debate. Also, the 'problems' that people are attributing to blocking and not processing BPDUs [BLOCK] are also 'problems' when no STP is running. In the case where two broadcast domains are rbridged together in such a way as to create a loop, the DR mechanism will detect and prevent it, so it works even when BPDUs are not present. So far the only reason I can think of to allow BPDUs to passively pass is for migration purposes. To keep the tree from changing 'just yet' but it certainly won't speed anything up, fix anything or do more to prevent loops than blocking will. Peter Ashwood-Smith > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Sunday, October 16, 2005 8:46 PM > To: saikat@seas.upenn.edu; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Time to summarize "forward or block" > BPDU thread > > > The scenario you mention is where there is temporarily two Designated > RBridges (DRs), because > two links were merged. > > The DRs will notice this when they start seeing each other's > IS-IS Hello > messages, and that > will break the loop. > > I don't think this case is that much of a problem, and > certainly would > not be helped by trying to run a big > global spanning tree. The big global spanning tree would > converge much > slower than the RBridge > DR election protocol would. So attempting to avoid a > temporary loop when > two bridged domains > are merged, by running a big global instance > of the spanning tree algorithm, will not solve the problem, and will > actually > make things worse. > > Radia > > > > > Saikat Ray wrote: > > >It is probably a standard scenario in IS-IS protocol (and > consequently > >a standard solution is known), but I was thinking that if > the RBridges > >disregards BPDUs entirely, then in some situations loops may > form for > >some period. For example, suppose $T_1$ and $T_2$ are disjoint trees > >formed entirely by legacy elements. $R_1$ and $R_2$ are the > designated > >RBridges for the "links" $T_1$ and $T_2$, respectively. At > this point, > >there is no loop in the system. Now suppose that a physical > link (or a > >legacy bridge) is added that connects a legacy bridge of $T_1$ to a > >legacy bridge of $T_2$. This addition will trigger a new > Spanning tree > >computation, which will result into a single spanning tree > that spans > >the nodes of $T_1$ and $T_2$. At this point, effectively the > RBridges > >$R_1$ and $R_2$ are connected by a single "link" and until > one of the > >RBridge gets "de-designated", there would exist a loop. Two > questions > >arise in my mind: (i) how fast would that "de-designation" > process be? > >And (ii) would it be useful (i.e. would it accelerate the > convergence) > >if RBridges "listen" to the BPDUs? > > > >-----Original Message----- > >From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On > >Behalf Of Radia Perlman > >Sent: Sunday, October 16, 2005 7:12 PM > >To: Developing a hybrid router/bridge. > >Subject: [rbridge] Time to summarize "forward or block" BPDU thread > > > >It looks like this thread was discussed with two different subject > >lines, and it's also > >gone on long enough it's time for someone to summarize it. > > > >I strongly believe that things will be more stable if RBridges do NOT > >forward BPDUs...that > >we decouple the protocols. > > > >That TRILL is kind of like a layer between bridging and routing. > > > >If RBridges do not forward BPDUs, then whether or not the TRILL link > >state protocol is > >converged, it won't affect the little spanning tree inside a > particular > >bridged segment. > > > >That way, the little spanning trees will converge as quickly as > >possible > >(because it's small), > >and cannot possibly be disrupted by RBridges wormholing BPDUs. > > > >I do not understand the reasons why people want to forward BPDUs. I > >think the arguments (which > >I may not be presenting fairly because I don't understand them) are: > >a) you'll get a more optimal combined spanning tree on which > >unknown/broadcast frames will > >be sent if it is one global spanning tree, rather than little > >independent spanning trees hooked together > >by the independently computed spanning tree calculated by IS-IS. > >b) forwarding BPDUs, and having a global spanning tree, will > prevent loops. > > > >I strongly disagree with both those arguments. For a) What do people > >think is more optimal about a tree > >computed that way vs having independent trees inside each bridged > >island? And besides, there isn't > >a single spanning tree...it's a spanning tree per ingress RBridge. > >For b) no...I believe that having both the RBridge algorithm and the > >bridge algorithm feeding into > >each other will create much slower convergence. > > > >If I haven't summarized correctly, then someone else can try > to capture > >the arguments, but I do > >think we should merge discussion under one subject line, and restart > >with a summary. > > > >Radia > > > >_______________________________________________ > >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 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 j9H0jxL02682 for <rbridge@postel.org>; Sun, 16 Oct 2005 17:45:59 -0700 (PDT) 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 <0IOH00M2TBGD6T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sun, 16 Oct 2005 17:45:49 -0700 (PDT) Received: from sun.com ([129.150.25.126]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOH00L57BG5TY00@mail.sunlabs.com> for rbridge@postel.org; Sun, 16 Oct 2005 17:45:47 -0700 (PDT) Date: Sun, 16 Oct 2005 17:45:47 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <200510170009.j9H09b5n025272@stag.seas.upenn.edu> To: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4352F43B.3050109@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: <200510170009.j9H09b5n025272@stag.seas.upenn.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: Re: [rbridge] Time to summarize "forward or block" BPDU thread 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, 17 Oct 2005 00:46:50 -0000 Status: RO Content-Length: 4213 The scenario you mention is where there is temporarily two Designated RBridges (DRs), because two links were merged. The DRs will notice this when they start seeing each other's IS-IS Hello messages, and that will break the loop. I don't think this case is that much of a problem, and certainly would not be helped by trying to run a big global spanning tree. The big global spanning tree would converge much slower than the RBridge DR election protocol would. So attempting to avoid a temporary loop when two bridged domains are merged, by running a big global instance of the spanning tree algorithm, will not solve the problem, and will actually make things worse. Radia Saikat Ray wrote: >It is probably a standard scenario in IS-IS protocol (and consequently a >standard solution is known), but I was thinking that if the RBridges >disregards BPDUs entirely, then in some situations loops may form for some >period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed >entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges for >the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop >in the system. Now suppose that a physical link (or a legacy bridge) is >added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$. >This addition will trigger a new Spanning tree computation, which will >result into a single spanning tree that spans the nodes of $T_1$ and $T_2$. >At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a >single "link" and until one of the RBridge gets "de-designated", there would >exist a loop. Two questions arise in my mind: (i) how fast would that >"de-designation" process be? And (ii) would it be useful (i.e. would it >accelerate the convergence) if RBridges "listen" to the BPDUs? > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Radia Perlman >Sent: Sunday, October 16, 2005 7:12 PM >To: Developing a hybrid router/bridge. >Subject: [rbridge] Time to summarize "forward or block" BPDU thread > >It looks like this thread was discussed with two different subject >lines, and it's also >gone on long enough it's time for someone to summarize it. > >I strongly believe that things will be more stable if RBridges do NOT >forward BPDUs...that >we decouple the protocols. > >That TRILL is kind of like a layer between bridging and routing. > >If RBridges do not forward BPDUs, then whether or not the TRILL link >state protocol is >converged, it won't affect the little spanning tree inside a particular >bridged segment. > >That way, the little spanning trees will converge as quickly as possible >(because it's small), >and cannot possibly be disrupted by RBridges wormholing BPDUs. > >I do not understand the reasons why people want to forward BPDUs. I >think the arguments (which >I may not be presenting fairly because I don't understand them) are: >a) you'll get a more optimal combined spanning tree on which >unknown/broadcast frames will >be sent if it is one global spanning tree, rather than little >independent spanning trees hooked together >by the independently computed spanning tree calculated by IS-IS. >b) forwarding BPDUs, and having a global spanning tree, will prevent loops. > >I strongly disagree with both those arguments. For a) What do people >think is more optimal about a tree >computed that way vs having independent trees inside each bridged >island? And besides, there isn't >a single spanning tree...it's a spanning tree per ingress RBridge. >For b) no...I believe that having both the RBridge algorithm and the >bridge algorithm feeding into >each other will create much slower convergence. > >If I haven't summarized correctly, then someone else can try to capture >the arguments, but I do >think we should merge discussion under one subject line, and restart >with a summary. > >Radia > >_______________________________________________ >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 stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9H09cL25775 for <rbridge@postel.org>; Sun, 16 Oct 2005 17:09:38 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9H09b5n025272 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Sun, 16 Oct 2005 20:09:37 -0400 Message-Id: <200510170009.j9H09b5n025272@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Sun, 16 Oct 2005 20:09:44 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <4352DE39.4040305@sun.com> Thread-Index: AcXSp0BLdI28QRH2S8CnnvPJV1B39QAAnIAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 17 Oct 2005 00:10:22 -0000 Status: RO Content-Length: 3288 It is probably a standard scenario in IS-IS protocol (and consequently a standard solution is known), but I was thinking that if the RBridges disregards BPDUs entirely, then in some situations loops may form for some period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges for the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop in the system. Now suppose that a physical link (or a legacy bridge) is added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$. This addition will trigger a new Spanning tree computation, which will result into a single spanning tree that spans the nodes of $T_1$ and $T_2$. At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a single "link" and until one of the RBridge gets "de-designated", there would exist a loop. Two questions arise in my mind: (i) how fast would that "de-designation" process be? And (ii) would it be useful (i.e. would it accelerate the convergence) if RBridges "listen" to the BPDUs? -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Sunday, October 16, 2005 7:12 PM To: Developing a hybrid router/bridge. Subject: [rbridge] Time to summarize "forward or block" BPDU thread It looks like this thread was discussed with two different subject lines, and it's also gone on long enough it's time for someone to summarize it. I strongly believe that things will be more stable if RBridges do NOT forward BPDUs...that we decouple the protocols. That TRILL is kind of like a layer between bridging and routing. If RBridges do not forward BPDUs, then whether or not the TRILL link state protocol is converged, it won't affect the little spanning tree inside a particular bridged segment. That way, the little spanning trees will converge as quickly as possible (because it's small), and cannot possibly be disrupted by RBridges wormholing BPDUs. I do not understand the reasons why people want to forward BPDUs. I think the arguments (which I may not be presenting fairly because I don't understand them) are: a) you'll get a more optimal combined spanning tree on which unknown/broadcast frames will be sent if it is one global spanning tree, rather than little independent spanning trees hooked together by the independently computed spanning tree calculated by IS-IS. b) forwarding BPDUs, and having a global spanning tree, will prevent loops. I strongly disagree with both those arguments. For a) What do people think is more optimal about a tree computed that way vs having independent trees inside each bridged island? And besides, there isn't a single spanning tree...it's a spanning tree per ingress RBridge. For b) no...I believe that having both the RBridge algorithm and the bridge algorithm feeding into each other will create much slower convergence. If I haven't summarized correctly, then someone else can try to capture the arguments, but I do think we should merge discussion under one subject line, and restart with a summary. 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 j9GNC3L12264 for <rbridge@postel.org>; Sun, 16 Oct 2005 16:12:03 -0700 (PDT) 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 <0IOH00M1R73Q6T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sun, 16 Oct 2005 16:11:50 -0700 (PDT) Received: from sun.com ([129.150.25.126]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOH00L3673NTY00@mail.sunlabs.com> for rbridge@postel.org; Sun, 16 Oct 2005 16:11:48 -0700 (PDT) Date: Sun, 16 Oct 2005 16:11:53 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <435081B0.2040200@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4352DE39.4040305@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: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> <435081B0.2040200@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] Time to summarize "forward or block" BPDU thread 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: Sun, 16 Oct 2005 23:12:24 -0000 Status: RO Content-Length: 1791 It looks like this thread was discussed with two different subject lines, and it's also gone on long enough it's time for someone to summarize it. I strongly believe that things will be more stable if RBridges do NOT forward BPDUs...that we decouple the protocols. That TRILL is kind of like a layer between bridging and routing. If RBridges do not forward BPDUs, then whether or not the TRILL link state protocol is converged, it won't affect the little spanning tree inside a particular bridged segment. That way, the little spanning trees will converge as quickly as possible (because it's small), and cannot possibly be disrupted by RBridges wormholing BPDUs. I do not understand the reasons why people want to forward BPDUs. I think the arguments (which I may not be presenting fairly because I don't understand them) are: a) you'll get a more optimal combined spanning tree on which unknown/broadcast frames will be sent if it is one global spanning tree, rather than little independent spanning trees hooked together by the independently computed spanning tree calculated by IS-IS. b) forwarding BPDUs, and having a global spanning tree, will prevent loops. I strongly disagree with both those arguments. For a) What do people think is more optimal about a tree computed that way vs having independent trees inside each bridged island? And besides, there isn't a single spanning tree...it's a spanning tree per ingress RBridge. For b) no...I believe that having both the RBridge algorithm and the bridge algorithm feeding into each other will create much slower convergence. If I haven't summarized correctly, then someone else can try to capture the arguments, but I do think we should merge discussion under one subject line, and restart with a summary. Radia Received: from [70.193.78.151] (151.sub-70-193-78.myvzw.com [70.193.78.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9GJXVL22539; Sun, 16 Oct 2005 12:33:31 -0700 (PDT) Message-ID: <4352AB04.8070606@isi.edu> Date: Sun, 16 Oct 2005 12:33:24 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.co m> <43511EC5.1060606@isi.edu> <01FA8B0106B35B7775225965@B50854F0A9192E8EC6CDA126> <43527E25.90802@isi.edu> <41385B27C884E5F06B7B0FEB@svartdal.hjemme.alvestrand.no> In-Reply-To: <41385B27C884E5F06B7B0FEB@svartdal.hjemme.alvestrand.no> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01CB02CD89AB2E1B650A8211" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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: Sun, 16 Oct 2005 19:34:50 -0000 Status: RO Content-Length: 1986 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01CB02CD89AB2E1B650A8211 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Harald Tveit Alvestrand wrote: >=20 > --On s=F8ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <touch@ISI.EDU= >=20 > wrote: >=20 >=20 >>>What we should be thinking of (to my mind) is "how do we discover that= >>>we're up the creek" - for this particular disaster, sending out a >>>broadcast packet and watching it come back should be quite sufficient >>>for the "detect" part.... >> >>What if you send a packet and it creates a broadcast storm? Sure, you >>know you're up the creek, but how do you paddle back? >=20 > if I have an one-packet answer to "how to take down a network", that=20 > network is certainly in trouble without me..... but others have certain= ly=20 > suggested forms of probing (hello packets?) that might be more gentle. My concern is that every reason for allowing BLOCK for rbridges is a reason to allow them for bridges as well. SPT is there for a reason - to avoid the possibility of loops, and thus such one-packet problems (deliberate or otherwise). I don't understand why that's the required default for bridges (AFACT - regardless of vendor offerings) but can be relaxed here. > I'd very much like to design a network that is stable in the presence o= f a=20 > person with a laptop, an ordinary bridge port and no conscience.... Agreed. Joe --------------enig01CB02CD89AB2E1B650A8211 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUqsFE5f5cImnZrsRAuo9AKC5ESgZKbuy8YWav6eSr8AbsTkAowCeLFJ1 e9nWMWZCF9RO3tffPGnOeIE= =Oi7L -----END PGP SIGNATURE----- --------------enig01CB02CD89AB2E1B650A8211-- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9GIQAL07322 for <rbridge@postel.org>; Sun, 16 Oct 2005 11:26:10 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43DB0258082 for <rbridge@postel.org>; Sun, 16 Oct 2005 20:25:15 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23128-09 for <rbridge@postel.org>; Sun, 16 Oct 2005 20:25:08 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5387B258077 for <rbridge@postel.org>; Sun, 16 Oct 2005 20:25:08 +0200 (CEST) Date: Sun, 16 Oct 2005 20:25:59 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <41385B27C884E5F06B7B0FEB@svartdal.hjemme.alvestrand.no> In-Reply-To: <43527E25.90802@isi.edu> References: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.co m> <43511EC5.1060606@isi.edu> <01FA8B0106B35B7775225965@B50854F0A9192E8EC6CDA126> <43527E25.90802@isi.edu> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9GIQAL07322 Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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: Sun, 16 Oct 2005 18:26:22 -0000 Status: RO Content-Length: 823 --On s?ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <touch@ISI.EDU> wrote: >> What we should be thinking of (to my mind) is "how do we discover that >> we're up the creek" - for this particular disaster, sending out a >> broadcast packet and watching it come back should be quite sufficient >> for the "detect" part.... > > What if you send a packet and it creates a broadcast storm? Sure, you > know you're up the creek, but how do you paddle back? if I have an one-packet answer to "how to take down a network", that network is certainly in trouble without me..... but others have certainly suggested forms of probing (hello packets?) that might be more gentle. I'd very much like to design a network that is stable in the presence of a person with a laptop, an ordinary bridge port and no conscience.... Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9GHv8L00060 for <rbridge@postel.org>; Sun, 16 Oct 2005 10:57:08 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9GHuxe01833 for <rbridge@postel.org>; Sun, 16 Oct 2005 13:56:59 -0400 (EDT) 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: Sun, 16 Oct 2005 13:56:58 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CFD@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstract for problem and applicabi lity statement Thread-Index: AcXSbomwPYqLx9p4T561jcDQ/65q3gAC/CQg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9GHv8L00060 Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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: Sun, 16 Oct 2005 17:57:21 -0000 Status: RO Content-Length: 399 > What if you send a packet and it creates a broadcast storm? > Sure, you know you're up the creek, but how do you paddle back? If your new device (like rbridge) sends and receives hellos before it unblocks ports this should not happen. You really can't protect against poor design but if each new device type follows this sort of rule the end result should be a tree (i.e. no loops). Peter Received: from [70.193.17.36] (36.sub-70-193-17.myvzw.com [70.193.17.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9GGM8L29415; Sun, 16 Oct 2005 09:22:09 -0700 (PDT) Message-ID: <43527E25.90802@isi.edu> Date: Sun, 16 Oct 2005 09:21:57 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.co m> <43511EC5.1060606@isi.edu> <01FA8B0106B35B7775225965@B50854F0A9192E8EC6CDA126> In-Reply-To: <01FA8B0106B35B7775225965@B50854F0A9192E8EC6CDA126> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7669BE26E62B80051C53E57B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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: Sun, 16 Oct 2005 16:22:23 -0000 Status: RO Content-Length: 1844 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7669BE26E62B80051C53E57B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > > --On 15. oktober 2005 08:22 -0700 Joe Touch <touch@ISI.EDU> wrote: > >> I.e., this works because all rbridges join to make a single campus. >> If there are two or more campuses in the same L2, or if some other >> device or pseudodevice (sbridge ;-) decides to play this game, the >> rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT. >> >> I don't believe it is therefore appropriate to BLOCK; if we break the >> 'all bridges/hubs must play in spanning tree' rule, we can't ensure that >> there won't be any other device that will do this too. > > actually we *can't* ensure that all bridges and hubs play the spanning > tree game no matter what we do, given that spanning tree is a > configuration option on switches. > > What we should be thinking of (to my mind) is "how do we discover that > we're up the creek" - for this particular disaster, sending out a > broadcast packet and watching it come back should be quite sufficient > for the "detect" part.... What if you send a packet and it creates a broadcast storm? Sure, you know you're up the creek, but how do you paddle back? Joe --------------enig7669BE26E62B80051C53E57B 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUn4qE5f5cImnZrsRAljaAKDjo2IzB5pG/x7T0v+bC94/EcC9FQCgmCxd ANshSnMFGXvt4u1CwtB63kY= =Y/v9 -----END PGP SIGNATURE----- --------------enig7669BE26E62B80051C53E57B-- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9GBYiL03888 for <rbridge@postel.org>; Sun, 16 Oct 2005 04:34:44 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1CB5C2596BA for <rbridge@postel.org>; Sun, 16 Oct 2005 13:34:02 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14466-07 for <rbridge@postel.org>; Sun, 16 Oct 2005 13:33:58 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1AAE258079 for <rbridge@postel.org>; Sun, 16 Oct 2005 13:33:58 +0200 (CEST) Date: Sun, 16 Oct 2005 12:15:09 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <01FA8B0106B35B7775225965@B50854F0A9192E8EC6CDA126> In-Reply-To: <43511EC5.1060606@isi.edu> References: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.co m> <43511EC5.1060606@isi.edu> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========88B549C0F2A39A9686C7==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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: Sun, 16 Oct 2005 11:35:20 -0000 Status: RO Content-Length: 1497 --==========88B549C0F2A39A9686C7========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 15. oktober 2005 08:22 -0700 Joe Touch <touch@ISI.EDU> wrote: > I.e., this works because all rbridges join to make a single campus. > If there are two or more campuses in the same L2, or if some other > device or pseudodevice (sbridge ;-) decides to play this game, the > rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT. > > I don't believe it is therefore appropriate to BLOCK; if we break the > 'all bridges/hubs must play in spanning tree' rule, we can't ensure that > there won't be any other device that will do this too. actually we *can't* ensure that all bridges and hubs play the spanning tree = game no matter what we do, given that spanning tree is a configuration=20 option on switches. What we should be thinking of (to my mind) is "how do we discover that=20 we're up the creek" - for this particular disaster, sending out a broadcast = packet and watching it come back should be quite sufficient for the=20 "detect" part.... --==========88B549C0F2A39A9686C7========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDUig4OMj+2+WY0F4RAtvYAJ0SC2Vf668C5ZjnReI0QbhlYY07EwCg3vCv XWmOBCz27fsXS0kRxd6DWmE= =QgBd -----END PGP SIGNATURE----- --==========88B549C0F2A39A9686C7==========-- Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9G0EfL19213 for <rbridge@postel.org>; Sat, 15 Oct 2005 17:14:41 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9G0Dwu00367 for <rbridge@postel.org>; Sat, 15 Oct 2005 20:13:58 -0400 (EDT) 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: Sat, 15 Oct 2005 20:13:42 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CFB@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstract for problem and applicabi lity statement Thread-Index: AcXRnNW3unSS0QoHQVCVb0jfW9IbjgAR9REQ From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9G0EfL19213 Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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: Sun, 16 Oct 2005 00:15:19 -0000 Status: RO Content-Length: 1285 > OK - thinking about this further, I think I get it - with a caveat. > > BLOCK works fine, provided the rbridge campus is the ONLY > "device" in the L2 who thinks it's appropriate to BLOCK. As > such, it knows that it can't form a loop by tying together edge trees. > > I.e., this works because all rbridges join to make a single > campus. If there are two or more campuses in the same L2, or > if some other device or pseudodevice (sbridge ;-) decides to > play this game, the rbridge campus can't BLOCK; it MUST be > PARTICIPATE or TRANSPARENT. > > I don't believe it is therefore appropriate to BLOCK; if we > break the 'all bridges/hubs must play in spanning tree' rule, > we can't ensure that there won't be any other device that > will do this too. I think that if each new type of device takes care of detecting a condition that could loop between its own devices ( and avoiding it ) then the entire L2 network will be loop free. As you can see, the rbridge did not need to 'talk' to the bridges to detect that a loop existed. It heard its own hellos and deduced that it would form a loop if it uses both devices/ports. The same would be true of any other hypothetical device, if it hears its own messages on some other port it knows there is a loop. Peter Received: from [160.39.243.182] (dyn-160-39-243-182.dyn.columbia.edu [160.39.243.182]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9FFMlL15303; Sat, 15 Oct 2005 08:22:47 -0700 (PDT) Message-ID: <43511EC5.1060606@isi.edu> Date: Sat, 15 Oct 2005 08:22:45 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig46C5E713863C1CE211F03825" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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, 15 Oct 2005 15:23:21 -0000 Status: RO Content-Length: 3014 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig46C5E713863C1CE211F03825 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: >>FWIW, nobody has answered the basic question: >>replace an rbridge in BLOCK mode with a bridge >>run whatever rbridges run internally within the bridge >>(i.e., emulate it) >>would THAT device be able to replace a bridge? >>would THAT device be able to partition the STPs of its leaves? > > > Let me take a crack at it. > > If I take one big STP domain and pick some point in the middle and > block > the BPDUS, clearly what I get is two independent trees that won't know > about > each other. Broadcast packets on one side will get to the other as if > there > were a host on the far side, but would potentially loop if there were > two links > between the trees. To fix this, somebody has to block one of the links > in > both directions at one end or the other, or both ends. > > Now, if we take the code on rbridge that elects a desgnated rbridge to > > act as the interface between these domains, run that same > logic on this new 'bridge'. Then yes. It could replace a bridge at this > boundary > since it would decide which link between the trees to use and would > block the > others. > > Anyway the key to eliminating this confusion is to understand that the > designated rbridge allows only one link between the trees. This concept > can be used to join two > trees together regardless of how they are created and only has to be > done by one > side or the other, not both. You could have two statically configured > trees with two or more links betwen them and this concept will pick one > link to use and ignore/block the others. OK - thinking about this further, I think I get it - with a caveat. BLOCK works fine, provided the rbridge campus is the ONLY "device" in the L2 who thinks it's appropriate to BLOCK. As such, it knows that it can't form a loop by tying together edge trees. I.e., this works because all rbridges join to make a single campus. If there are two or more campuses in the same L2, or if some other device or pseudodevice (sbridge ;-) decides to play this game, the rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT. I don't believe it is therefore appropriate to BLOCK; if we break the 'all bridges/hubs must play in spanning tree' rule, we can't ensure that there won't be any other device that will do this too. Joe --------------enig46C5E713863C1CE211F03825 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUR7FE5f5cImnZrsRAqRjAJ48Jl8gNSTXFrHkboJXzAvHxo1sKACfauxA D4doYLGcQ1zexOxYPj+zsdg= =5qDt -----END PGP SIGNATURE----- --------------enig46C5E713863C1CE211F03825-- Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9FFCBL13052 for <rbridge@postel.org>; Sat, 15 Oct 2005 08:12:12 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9FF9OH20430 for <rbridge@postel.org>; Sat, 15 Oct 2005 11:09:24 -0400 (EDT) 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: Sat, 15 Oct 2005 11:11:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CFA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstract for problem and applicabi lity statement Thread-Index: AcXRP151GOKndGZ3Q3m4/m8rtu4inwAWKPag From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9FFCBL13052 Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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, 15 Oct 2005 15:12:18 -0000 Status: RO Content-Length: 1526 > FWIW, nobody has answered the basic question: > replace an rbridge in BLOCK mode with a bridge > run whatever rbridges run internally within the bridge > (i.e., emulate it) > would THAT device be able to replace a bridge? > would THAT device be able to partition the STPs of its leaves? Let me take a crack at it. If I take one big STP domain and pick some point in the middle and block the BPDUS, clearly what I get is two independent trees that won't know about each other. Broadcast packets on one side will get to the other as if there were a host on the far side, but would potentially loop if there were two links between the trees. To fix this, somebody has to block one of the links in both directions at one end or the other, or both ends. Now, if we take the code on rbridge that elects a desgnated rbridge to act as the interface between these domains, run that same logic on this new 'bridge'. Then yes. It could replace a bridge at this boundary since it would decide which link between the trees to use and would block the others. Anyway the key to eliminating this confusion is to understand that the designated rbridge allows only one link between the trees. This concept can be used to join two trees together regardless of how they are created and only has to be done by one side or the other, not both. You could have two statically configured trees with two or more links betwen them and this concept will pick one link to use and ignore/block the others. Peter Ashwood-Smith Received: from [70.192.85.203] (203.sub-70-192-85.myvzw.com [70.192.85.203]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9F4CfL18986; Fri, 14 Oct 2005 21:12:41 -0700 (PDT) Message-ID: <435081B0.2040200@isi.edu> Date: Fri, 14 Oct 2005 21:12:32 -0700 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> References: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF8CA7BF29078962B06ABDEF" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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, 15 Oct 2005 04:13:27 -0000 Status: RO Content-Length: 11280 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF8CA7BF29078962B06ABDEF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gray, Eric wrote: > Joe, > > You said: The edges are individual spanning trees. The rbridge > can have more than one internal path between two edge trees, > but that's it, that's all the redundency that's provided. > Turning off ports on the outside edge of the rbridge has no > effect on the internal multipath potential. > > And then later, you also said: Yes [STP would be disabled by > default]. And not to forward ingress frames until internal > routing (IS-IS in this case) is established. At that point, > STP should be enabled at the 'edges', STP PARTICIPATEd, and > -then- ingress enabled. > > What's the problem? > > "Internal" and "external" are not meaningful terms. How would an > RBridge distinguish an "internal" bridge from an "external" bridge? Internal and external traffic is easy to distinguish (internal has the shim header). Bridges can be either or both, of course. It doesn't matter, though - both can set their spanning trees before the rbridge is configured. > You suggest that this would occur as a result of recognizing that > another RBridge exists on the local bridged network. That appears > to assume that the only way to keep RBridges from being part of the > same campus is to put a router between them. That - in turn - has > some interesting implications with respect to colocation of router > and RBridge functionality. That was Radia's assertion. I had always thought an L2 could have more than one rbridge campus, but that would imply that there was a way to indicate which campus an rbridge was part of (e.g., via override). > The key reason why I don't think that the presence of other RBridge > on a port makes it an "internal" port is that there is a distinction > between reaching other RBridges in certain extended topologies and > reaching them in other densely interconnected topologies. But that > may simply be a terminology issue. > > The same applies to "ingress" and "edge". > > But there's a larger issue. I am not at all convinced that it is > ever necessary to differentiate the behavior of "internal" verses > "external" interfaces. Consequently, I think it is an unecessary > complication, especially given that - if it is indeed based on the > presence of another RBridge on the same link - it is something that > can change very quickly, causing an RBridge to change operational > modes. There's no reason I can see for taking on the additional > complexity. I agree that interfaces aren't internal or external. Let's put it this way: rbridges ingress/egress functionality is disabled until the spanning trees of other bridges is completed (it basically has to be; otherwise, stuff falls on the floor). once the other spanning trees are set, the rbridge can enable ingress/egress (which is when it would anyway, since that's the point at which traffic would flow. > You also said: Rbridges have nothing to do with the convergence > of the spanning tree external to them, IMO. All they do is have > their INTERNAL routing converge faster than spanning tree would > have - that's where the benefit comes from. I never thought it > had anything to do with an effect on the external trees. > > And then later said: That's an interesting question - [a longer > initial convergence time] may be the result of having an internal > routing protocol that isn't setup ahead of time. [That is], maybe > rbridges DO take longer to *initially* converge the STP of an > existing net, but react faster *afterwards* to changes. > > This is only true if RBridges do not participate in STP with the > bridges in a local bridged network. If they do participate, then > the STP will not converge until after the RBridges have determined > forwarding paths among themselves, which will not occur until any > bridges between RBridges have converged on their STP. > > So, the bridges between RBridges do STP. The links between RBridges > come up. The RBridges "hello" each other, peer, exchange link state > and reachability information, and then announce a topology change to > at least all ports that they have not heard other RBridges on (though > this is not sufficient, let's assume for simplicity that it is). Now > the bridges on the affected links re-start STP - only now the network > of bridges is very much larger, because it includes at least bridges > that hang off of the RBridge's peer's other interfaces. > > How is it that this does not take longer than if the RBridges didn't > exist? Also, there appears to be a misconception that STP takes a > long time in comparison with routing. Given that STP must complete > before routing can begin, this is a bit of a misleading concern, at > best. This is a startup issue; I have already agreed that this would take longer with rbridges in the loop, with the hope that later cahnges could be propagated more quickly. > Let's take a specific case: An "internal" bridge goes down, taking > one or more links between RBridges with it. The RBridges lose a > forwarding path and make the corresponding LSDB updates. Further, > let's assume that this partitions the RBridge campus temporarily. > > The link is redundant, so a neighbor will announce a topology change > and STP will re-run to switch port forwarding states so that the > redundant path is now available. > > The link returns and IS-IS reconverges. Now the RBridges might be > clever and recognize that the net change (no pun intended) is NIL - > assuming that all of this happened fast enough that the RBridges > have not previously announced a topology change to "external" bridges. > > In this case, nothing else happens. > > However, let's assume that the re-establishment of the "internal" > link did not happen fast enough. In that case, the "external" > bridges will see two topology change notifications and STP will be > run each time. If the second topology change occurs before the STP > completes for the first topology change, it will be as if the whole > system is being restarted from scratch. I'm not sure I followed all of that, but yes, there are cases where changes in the internal paths available to an rbridge due to partitioning could affect edge STPs. > You also said: [STP convergence is] just like adding a bridge > to an existing bridged system. The new bridge doesn't forward > frames until STP finishes, but the existing bridges can finish > just fine. The rbridge is the 'new' bridge. > > All the other bridges are the existing bridge system. No chicken > and egg, AFAICT; the sequence is determined by rbridge's reliance > on bridges. > > I think that in this case (and maybe in others) we're not talking > about the same kind of convergence problem. I am talking about the > time that initial convergence takes and you're (apparently) talking > about the time it take to re-converge after a minor topology change. I had been talking about both cases (at least in later emails), and already agreed they were different. > Also, STP convergence - as explained above - is different if a > bridge goes down. > > I think - even so - that there's a flaw in your reasoning that is > based on a mistaken assumption that you specifically state below. > > Also, you said: Again, I'm back to 'what would a bridge do'. > Either this is a bridge (PARTICIPATE) or a link (e.g., hub, > which means TRANSPARENT). Those are the only two options that > have correlaries in existing L2. > > That's simply not true. Hosts exist at L2. Routers exist at L2. > Neither of them do either of these. Yes. And - sorry to shout but this point apparently isn't being appreciated - BOTH HAVE L2 SOURCE/SINK ADDRESSES. Rbridges - at least as far as ingress/egress links are concerned - do NOT. Their addresses are ONLY for rbridge-rbridge traffic. So - this is equally important: to conventional nodes (hosts/routers are the same thing in L2) on the L2, the rbridge MUST act like a link/hub or switch to other rbridge nodes (and only to them), the ingress/egress look like conventional nodes (sources/sinks) > Finally, you also said: [RBridges] can't make redundent paths > in the non-rbridge portion of an L2 net. They can only do so > within the rbridge. > > This is a flawed assumption. > > Note that even bridges can carry L2 traffic for more than one VLAN. > It's a simple matter - if you're starting from scratch to implement > a bridge - to allow an RBridge (for instance) to use one port in a > local bridged network to forward frames associated with one set of > VLANs, and another port in the same local bridged network to forward > frames associate with another set of VLANs. Different ports for different VLANs aren't redundent paths, unless you're going to move frames from one VLAN to another. > Also note that there is no possibility of looping traffic introduced > by this behavior. > > Also note that the same would obviously apply if another RBridge > in the same RBridge campus had a port in the same local bridged > network. > > Participation in the local STP would mean that the local bridges > would determine that the RBridge campus had a redundant path. As > a result, certain of the local bridges would put their ports in a > non-forwarding mode - making use of the redundant path impossible. Isn't that just an STP per VLAN? > Clearly this can be applied to other mechanisms for differentiating > frame-streams than by VLAN-ID, but it should be sufficient to show > a single example of when participating in local STP is a bad idea. > > Finally, note once again that all of this applies equally to both > "internal" and "external" ports. FWIW, nobody has answered the basic question: replace an rbridge in BLOCK mode with a bridge run whatever rbridges run internally within the bridge (i.e., emulate it) would THAT device be able to replace a bridge? would THAT device be able to partition the STPs of its leaves? So far, the ONLY reason I can see that the rbridge *might* get away doing anything different from a bridge is the requirement/assumption that all rbridge devices in an L2 aggregate into a single campus. If that IS the case, there *might* be a way it can do something other than TRANSPARENT or PARTICIPATE, but it's not clear how different it ends up being from PARTICIPATE (it seems like it still has to be roots on each STP - how does it do that?) If that IS NOT the case, someone needs to show how these behaviours couldn't be used to augment a conventional bridge to result in partitioned, faster-converging STPs. Joe --------------enigFF8CA7BF29078962B06ABDEF 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUIGwE5f5cImnZrsRAif4AJ4306mVN1Ne94YXcNCNGNd1z8OTLQCfbyYF 38nJwMR5MnOmLXb3LHrjsfY= =oLW3 -----END PGP SIGNATURE----- --------------enigFF8CA7BF29078962B06ABDEF-- Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9F3ADL07777 for <rbridge@postel.org>; Fri, 14 Oct 2005 20:10:14 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9F3A6h19767 for <rbridge@postel.org>; Fri, 14 Oct 2005 23:10:06 -0400 (EDT) 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, 14 Oct 2005 23:10:05 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CF9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge]seeking input on abstractfor problemand applicabilitystatement Thread-Index: AcXRD2JaALA+PSJlS/GcP6flYP9p2QAJYyUA From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9F3ADL07777 Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 15 Oct 2005 03:11:16 -0000 Status: RO Content-Length: 993 > The only reason it'd be blocked is if the spanning tree protocol knew both rbridges were part of the same spanning tree. I thought that's what the BPDUs would indicate. A packet can be not forwarded at either an egress or ingress port Joe. The rbridges fix this problem so the bridges don't have to. Two or more more Rbridges that are connected to the same broadcast domain (i.e. STP tree) will elect one of them to relay traffic to/from that STP domain the others will ignor everything they see comming from that port and not forward anything to that port (i.e. they block it). I think this is the critical piece you are missing. In your mind this is PARTICIPATE but its not because its one sided, only the Rbridges need to agree on this behaviour. The bridges don't need to know the Rbridges are doing it. Like I've said, take two disjoint trees, join with a single link and you have a tree. It is the behaviour above that guarantees the single connection between the two trees. Peter 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 j9F0tWL11024 for <rbridge@postel.org>; Fri, 14 Oct 2005 17:55:33 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1D7FF9D2A3 for <rbridge@postel.org>; Sat, 15 Oct 2005 02:55:02 +0200 (CEST) Received: from [163.117.203.181] (unknown [163.117.203.181]) by smtp01.uc3m.es (Postfix) with ESMTP id 0CE3F9D2A4 for <rbridge@postel.org>; Sat, 15 Oct 2005 02:55:01 +0200 (CEST) Message-ID: <43505365.8060706@it.uc3m.es> Date: Sat, 15 Oct 2005 02:55:01 +0200 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: <313680C9A886D511A06000204840E1CF0C885F9E@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F9E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] seeking input on abstractfor problemand applicabili tystatement 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, 15 Oct 2005 00:56:15 -0000 Status: RO Content-Length: 2027 Eric, The difficulties you mention regarding per VLAN trees are among the reasons I would recommend (instead of per VLAN Rbridge trees) one spanning tree per Rbridge to all other Rbridges, carrying all VLANs, irrespective of VLAN membership. Rbridges in this way act as double root bridges, for the edge tree of bridges and (route wise) for the Rbridges tree. Guillermo Gray, Eric wrote: >Guillermo, > > I agree with your comments to Joe, but I want to expand >on the last comment that you made (included below). > > One of the big problems with assuming that STP is used >across the entire RBridge campus is that this doesn't allow >us to take advantage of things we know now that were not known >when STP was designed. For example, VLANs. > > One of the proposals for creating a shortest path spanning >tree within the campus is to allow a spanning tree per VLAN. A >set of 802 bridges cannot do that. However, it is incredibly >likely that small spanning trees at the edge of a campus will >have significant non-intersecting VLAN membership. This implies >that there is a potentially significant benefit from having per >VLAN shortest path spanning trees within the RBridge campus. In >this case, topology that must be correctly understood by RBridges >in order to correctly forward STP BPDUs from one edge spanning >tree to other edge spanning trees is very complicated. Also, in >this case, the root RBridges should not be the same for all VLAN >specific shortest path spanning trees. > >-- >Eric > > >--> > >--> There is no problem as there is only one Designated Rbridge in >--> the bridges spanning tree, the only that forward frames to/from >--> that tree into the rbridges region. IMMO, the Designated Rbridge >--> should act as Root bridge of the bridges spanning tree, so the >--> path is optimum to all bridges of that tree. >--> >_______________________________________________ >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 j9F0J4L03268 for <rbridge@postel.org>; Fri, 14 Oct 2005 17:19:04 -0700 (PDT) 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 j9F0IwrP018271 for <rbridge@postel.org>; Fri, 14 Oct 2005 20:18:59 -0400 (EDT) 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 UAA22539 for <rbridge@postel.org>; Fri, 14 Oct 2005 20:18:59 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPHLD7>; Fri, 14 Oct 2005 21:18:58 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F9E@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 21:18:57 -0300 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] seeking input on abstractfor problemand applicabili tystatement 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, 15 Oct 2005 00:19:15 -0000 Status: RO Content-Length: 1437 Guillermo, I agree with your comments to Joe, but I want to expand on the last comment that you made (included below). One of the big problems with assuming that STP is used across the entire RBridge campus is that this doesn't allow us to take advantage of things we know now that were not known when STP was designed. For example, VLANs. One of the proposals for creating a shortest path spanning tree within the campus is to allow a spanning tree per VLAN. A set of 802 bridges cannot do that. However, it is incredibly likely that small spanning trees at the edge of a campus will have significant non-intersecting VLAN membership. This implies that there is a potentially significant benefit from having per VLAN shortest path spanning trees within the RBridge campus. In this case, topology that must be correctly understood by RBridges in order to correctly forward STP BPDUs from one edge spanning tree to other edge spanning trees is very complicated. Also, in this case, the root RBridges should not be the same for all VLAN specific shortest path spanning trees. -- Eric --> > --> There is no problem as there is only one Designated Rbridge in --> the bridges spanning tree, the only that forward frames to/from --> that tree into the rbridges region. IMMO, the Designated Rbridge --> should act as Root bridge of the bridges spanning tree, so the --> path is optimum to all bridges of that tree. --> 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 j9ENuuL27829 for <rbridge@postel.org>; Fri, 14 Oct 2005 16:56:56 -0700 (PDT) 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 j9ENumrP018011 for <rbridge@postel.org>; Fri, 14 Oct 2005 19:56:48 -0400 (EDT) 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 TAA21207 for <rbridge@postel.org>; Fri, 14 Oct 2005 19:56:48 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPHKWZ>; Fri, 14 Oct 2005 20:56:47 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F9C@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 20:56:46 -0300 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] seeking input on abstract for problem and applicabi lity statement 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, 14 Oct 2005 23:57:16 -0000 Status: RO Content-Length: 15178 Joe, You said: The edges are individual spanning trees. The rbridge can have more than one internal path between two edge trees, but that's it, that's all the redundency that's provided. Turning off ports on the outside edge of the rbridge has no effect on the internal multipath potential. And then later, you also said: Yes [STP would be disabled by default]. And not to forward ingress frames until internal routing (IS-IS in this case) is established. At that point, STP should be enabled at the 'edges', STP PARTICIPATEd, and -then- ingress enabled. What's the problem? "Internal" and "external" are not meaningful terms. How would an RBridge distinguish an "internal" bridge from an "external" bridge? You suggest that this would occur as a result of recognizing that another RBridge exists on the local bridged network. That appears to assume that the only way to keep RBridges from being part of the same campus is to put a router between them. That - in turn - has some interesting implications with respect to colocation of router and RBridge functionality. The key reason why I don't think that the presence of other RBridge on a port makes it an "internal" port is that there is a distinction between reaching other RBridges in certain extended topologies and reaching them in other densely interconnected topologies. But that may simply be a terminology issue. The same applies to "ingress" and "edge". But there's a larger issue. I am not at all convinced that it is ever necessary to differentiate the behavior of "internal" verses "external" interfaces. Consequently, I think it is an unecessary complication, especially given that - if it is indeed based on the presence of another RBridge on the same link - it is something that can change very quickly, causing an RBridge to change operational modes. There's no reason I can see for taking on the additional complexity. You also said: Rbridges have nothing to do with the convergence of the spanning tree external to them, IMO. All they do is have their INTERNAL routing converge faster than spanning tree would have - that's where the benefit comes from. I never thought it had anything to do with an effect on the external trees. And then later said: That's an interesting question - [a longer initial convergence time] may be the result of having an internal routing protocol that isn't setup ahead of time. [That is], maybe rbridges DO take longer to *initially* converge the STP of an existing net, but react faster *afterwards* to changes. This is only true if RBridges do not participate in STP with the bridges in a local bridged network. If they do participate, then the STP will not converge until after the RBridges have determined forwarding paths among themselves, which will not occur until any bridges between RBridges have converged on their STP. So, the bridges between RBridges do STP. The links between RBridges come up. The RBridges "hello" each other, peer, exchange link state and reachability information, and then announce a topology change to at least all ports that they have not heard other RBridges on (though this is not sufficient, let's assume for simplicity that it is). Now the bridges on the affected links re-start STP - only now the network of bridges is very much larger, because it includes at least bridges that hang off of the RBridge's peer's other interfaces. How is it that this does not take longer than if the RBridges didn't exist? Also, there appears to be a misconception that STP takes a long time in comparison with routing. Given that STP must complete before routing can begin, this is a bit of a misleading concern, at best. Let's take a specific case: An "internal" bridge goes down, taking one or more links between RBridges with it. The RBridges lose a forwarding path and make the corresponding LSDB updates. Further, let's assume that this partitions the RBridge campus temporarily. The link is redundant, so a neighbor will announce a topology change and STP will re-run to switch port forwarding states so that the redundant path is now available. The link returns and IS-IS reconverges. Now the RBridges might be clever and recognize that the net change (no pun intended) is NIL - assuming that all of this happened fast enough that the RBridges have not previously announced a topology change to "external" bridges. In this case, nothing else happens. However, let's assume that the re-establishment of the "internal" link did not happen fast enough. In that case, the "external" bridges will see two topology change notifications and STP will be run each time. If the second topology change occurs before the STP completes for the first topology change, it will be as if the whole system is being restarted from scratch. You also said: [STP convergence is] just like adding a bridge to an existing bridged system. The new bridge doesn't forward frames until STP finishes, but the existing bridges can finish just fine. The rbridge is the 'new' bridge. All the other bridges are the existing bridge system. No chicken and egg, AFAICT; the sequence is determined by rbridge's reliance on bridges. I think that in this case (and maybe in others) we're not talking about the same kind of convergence problem. I am talking about the time that initial convergence takes and you're (apparently) talking about the time it take to re-converge after a minor topology change. Also, STP convergence - as explained above - is different if a bridge goes down. I think - even so - that there's a flaw in your reasoning that is based on a mistaken assumption that you specifically state below. Also, you said: Again, I'm back to 'what would a bridge do'. Either this is a bridge (PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are the only two options that have correlaries in existing L2. That's simply not true. Hosts exist at L2. Routers exist at L2. Neither of them do either of these. Finally, you also said: [RBridges] can't make redundent paths in the non-rbridge portion of an L2 net. They can only do so within the rbridge. This is a flawed assumption. Note that even bridges can carry L2 traffic for more than one VLAN. It's a simple matter - if you're starting from scratch to implement a bridge - to allow an RBridge (for instance) to use one port in a local bridged network to forward frames associated with one set of VLANs, and another port in the same local bridged network to forward frames associate with another set of VLANs. Also note that there is no possibility of looping traffic introduced by this behavior. Also note that the same would obviously apply if another RBridge in the same RBridge campus had a port in the same local bridged network. Participation in the local STP would mean that the local bridges would determine that the RBridge campus had a redundant path. As a result, certain of the local bridges would put their ports in a non-forwarding mode - making use of the redundant path impossible. Clearly this can be applied to other mechanisms for differentiating frame-streams than by VLAN-ID, but it should be sufficient to show a single example of when participating in local STP is a bad idea. Finally, note once again that all of this applies equally to both "internal" and "external" ports. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Friday, October 14, 2005 5:15 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstract for problemand --> applicabil itystatement --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier, you said: Gray, Eric wrote: > Joe, > > I want to address specific comments/questions you > had below: > > -> All of this sounds like stuff the rbridge already > needs to do; there needs to be an internal spanning > tree anyway. > > We have not yet decided how many "spanning trees" there > needs to be, and that is a part of the problem. One of > the goals of the original proposal - as I understand it > - was to allow efficient use of redundant links that may > exist between RBridges. > > This is why the confusion keeps coming up with the use > of the term spanning tree. Its NOT the right term in > the RBridge context, because the RBridges WILL NOT be > turning ports off and WILL be forwarding distinguishable > streams of frames on as many of the available links as > it makes sense to use, given the destinations and - for > example - VLAN contexts that apply to each stream. I'm not sure I agree. The edges are individual spanning trees. The rbridge can have more than one internal path between two edge trees, but that's it, that's all the redundency that's provided. Turning off ports on the outside edge of the rbridge has no effect on the internal multipath potential. > Another goal - again as I understand it - is to reduce > the time for convergence on spanning trees for those > portions of the network that MUST use STP (the bridges). > For that goal to be achieved, it is a good idea not to > extend STP across the RBridges. I definitely disagree with this. Rbridges have nothing to do with the convergence of the spanning tree external to them, IMO. All they do is have their INTERNAL routing converge faster than spanning tree would have - that's where the benefit comes from. I never thought it had anything to do with an effect on the external trees. > Finally, there is a huge "chicken-and-egg" problem with > any intention to have RBridges participate in STP. > > The "spanning tree(s)" determined by RBridges are the > result of shortest path analysis of reachability info > provided by IS-IS. If this is not the case, then there > was never any reason to suggest using a shortest-path, > Link State Routing Protocol in the first place. > > However, before the RBridges can reliably determine > link state and advertise reachability, any "internal" > bridges MUST have already determined a spanning tree > (using STP). As I pointed out previously, and Radia > stated as well, bridges typically do not forward during > STP, consequently some or all of the links between the > RBridges will be DOWN as far as IS-IS is concerned. That's just like adding a bridge to an existing bridged system. The new bridge doesn't forward frames until STP finishes, but the existing bridges can finish just fine. The rbridge is the 'new' bridge. All the other bridges are the existing bridge system. No chicken and egg, AFAICT; the sequence is determined by rbridge's reliance on bridges. > Also, again as pointeed out previously, "internal" and > "external" are topologically meaningless terms as far > as RBridges are concerned - unless that information is > explicitly configured. Consequently, default RBridge > behavior really MUST be to ignore STP on any port not > explicitly configured to participate in STP. Yes. And not to forward ingress frames until internal routing (IS-IS in this case) is established. At that point, STP should be enabled at the 'edges', STP PARTICIPATEd, and -then- ingress enabled. What's the problem? > Also, because the link state between RBridges is not > determined until after any internal STP required has > been completed between bridges that may be involved > in those links, either the RBridges have to wait a > pre-determined period of time (to blindly allow for > "internal" STP) or send topology change BPDUs on all > ports every time they discover new links. Either way > will result in potentially huge delays in overall STP > convergence time for the network. Again, I'm back to 'what would a bridge do'. Either this is a bridge (PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are the only two options that have correlaries in existing L2. > -> I'd like someone to explain which of these are valid > if we replace the rbridge campus with an existing > bridge. > > I am not sure that this concept of a "virtual bridge" > is - or ever has been - a goal for RBridges. It's not a goal; it's a definition, IMO. > If you > want a "virtual bridge", one approach that already is > out there is VPLS. Consequently, why would we need > to specify how to do it with RBridges? VPLS, depending on where I look, are either pseudowires (virtual hubs) or L2 over L3. Rbridge is L2 over L2 with routing. > If it is not a goal, then the notion of replacing an > RBridge with a single bridge is not something we need > to consider. > > -> My understanding is that PARTICIPATE is valid, if not > required. TRANSPARENT seems like it turns the bridge > into a hub. And BLOCK would break things. > > Assuming that this _is_ a goal, there is no particular > reason why someone would not replace a hub (even a > "virtual hub") with a bridge. For reasons explained > above, however, PARTICIPATE - while potentially valid > - is extremely undesirable. If you replace a hub with a bridge that refuses to PARTICIPATE, what's the effect? Nothing. That assumes that hubs weren't in rings, which they weren't supposed to be. However, you CAN wire bridges in rings and they're supposed to do the right thing. That's only because they PARTICIPATE, though. > Transparent also is not good because the path through > the RBridges will not exist (or not be complete) until > A) STP is completed between any "internal" bridges and > B) the RBridges have converged on a complete LSDB and > determine SPSTs (shortest path spanning trees). I already answered this in a separate email; yes, both of these steps need to happen in order, and they will. > So, even with Transparent, the insertion of RBridges > would result in increased STP convergence time, even > if the network size has not changed. That's an interesting question - that may be the result of having an internal routing protocol that isn't setup ahead of time. I.e., maybe rbridges DO take longer to *initially* converge the STP of an existing net, but react faster *afterwards* to changes. > In addition, TRANSPARENT would require configuration > of the RBridges to recognize "external" interfaces - The need to know which interfaces they can reach rbridges on, which can (and should) be autoconfigured. > since it is clearly not the case that, even in this > mode, you would want bridges inside an RBridge campus > to participate with bridges outside that campus. As > implied previously, having all bridges - both inside > and outside of an RBridge campus - participating in > forming a single spanning tree would prevent using > redundant paths (and would very likely drop RBridge > ports out of the topology as the corresponding bridge > ports - at the other end of the physical link - are > put in the non-forwarding state). I also already answered this - rbridges can't make redundent paths in the non-rbridge portion of an L2 net. They can only do so within the rbridge. Joe 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 j9ENYgL22532 for <rbridge@postel.org>; Fri, 14 Oct 2005 16:34:42 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C2D99D328 for <rbridge@postel.org>; Sat, 15 Oct 2005 01:34:36 +0200 (CEST) Received: from [163.117.203.181] (unknown [163.117.203.181]) by smtp01.uc3m.es (Postfix) with ESMTP id 0F40B9D316 for <rbridge@postel.org>; Sat, 15 Oct 2005 01:34:35 +0200 (CEST) Message-ID: <4350408B.6020608@it.uc3m.es> Date: Sat, 15 Oct 2005 01:34:35 +0200 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: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> <43502ABB.4040007@it.uc3m.es> <43503287.8080707@isi.edu> In-Reply-To: <43503287.8080707@isi.edu> 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] seekinginput on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 23:35:16 -0000 Status: RO Content-Length: 1594 Joe Touch wrote: >Guillermo Ib??ez wrote: > > >>Guillermo Ib??ez wrote: >> >>OK. So the designated Rbridge should act as root bridge of that spanning >>tree, for a shortest path to all bridges of spanning trees. >> >> > >To do that, it would need to emit BPDUs to all edge trees to announce it >was the root, wouldn't it? Only then could it KNOW that the ingresses it >expects from each spanning tree would be the ones used (e.g., for those >attached multiple times). > >(which would be back to PARTICIPATE) > > > >Joe > > > Sorry, I did not follow the whole discussion. My understanding is that rbridges can participate in the spanning tree they are attached to but do not forward BPDUs. Each port emits BPDUs based solely on its port information, opposite to the standard operation , where the bridge builds the BPDUs to be transmitted based on information collected from all bridge ports and selecting the best BPDU, thus conveyed the distance to root bridge. I would call this mode PARTICIPATE PER PORT. Rbridge ports should announce themselves as designated ports of Rbridge (root). The Rbridge ports will be in role Designated if the win the competition in the link or in Back-Up or Alternate role (that means blocked) if they lost the competition of best BPDU heard in the local link. They would never be in Root port role. Guillermo >------------------------------------------------------------------------ > >_______________________________________________ >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 j9EN2LL14866 for <rbridge@postel.org>; Fri, 14 Oct 2005 16:02:22 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8A15D8CF90 for <rbridge@postel.org>; Sat, 15 Oct 2005 01:02:15 +0200 (CEST) Received: from [163.117.203.181] (unknown [163.117.203.181]) by smtp01.uc3m.es (Postfix) with ESMTP id DA4409D02E for <rbridge@postel.org>; Sat, 15 Oct 2005 01:02:13 +0200 (CEST) Message-ID: <435038F6.8000109@it.uc3m.es> Date: Sat, 15 Oct 2005 01:02:14 +0200 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: <713043CE8B8E1348AF3C546DBE02C1B405213CF3@zcarhxm2.corp.nortel.com> <43501A04.1020402@isi.edu> <435024C0.6010704@it.uc3m.es> <43503177.9090508@isi.edu> In-Reply-To: <43503177.9090508@isi.edu> 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] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 23:03:22 -0000 Status: RO Content-Length: 3796 Guillermo Ib??ez wrote: Joe Touch wrote: >Guillermo Ib??ez wrote: > > >>I am not sure I interpreted the terms right. My understanding is that >>rbridges must participate in the spanning tree. This is required to >>avoid loops if two links of same network get attached to same rbridge. >>But rbridges must act as hosts, >> >> > >I have always disagreed with that assertion. > >To the outside of the network: > >I thought they would always act as if a single bridge (meaning >PARTICIPATE); I understand now how they might act as if a single >hub/link (TRANSPARENT). > >To bridges they send encapsulated packets over, the ingress rbridges >look like hosts, but that's only to transit the L2. > > > >>should not >>forward received BPDUs to other ports of rbridge, as it is much more >>efficient and faster to converge, to have many small spanning trees than >>a big one. >> >> > >I agree with that, except that this argues that existing bridges should >act in the same way. But they don't. I'm not sure they can. > > > I do not see the point. Existing bridges should forward their spanning tree BPDUs. Tree extends till a link terminates in an Rbridge. >>Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a >>path to complexity, opposite to selfconfiguration. >> >> > >Manual configuration is the opposite of selfconfiguration. >Selfconfiguration does not prohibit complexity, provided the complexity >can be selfconfigured - which I think it can. > > > I agree, but I does not look easy to obtain selconfiguration. Linking spanning trees with the rbridges network creates dependencies in transitions in case of reconfigurations. Linking spanning trees 802.1D with the rbridge protocol increases the risks of interference between protocols. >>See below my comment on loops with broadcast frames. >> >> >... > > >>>How do I know they're disjoint trees, and what happens if (when) they >>>get interconnected? >>> >>>If a spanning tree is attached to the rbridge in more than one place, >>>what happens with broadcasts? Won't they create a loop? >>> >>> >>If there are two attachments to the same spanning tree to the same >>rbridge one of them acts as designated port and the other will be >>blocked by the spanning tree protocol. >> >> > >The only reason it'd be blocked is if the spanning tree protocol knew >both rbridges were part of the same spanning tree. I thought that's what >the BPDUs would indicate. > > > >>Participation in STP is needed >>for that. >> >> > >That's what I thought - but that requires PARTICIPATE, right? > > >I see the potential problem you mention with the attachment of spanning >tree to /different/ rbridges > > > >In the same campus? Why does that matter? > > > >>with broadcast frames. An rbridge receives >>the broadcast frame from the spanning tree, encapsulates it with the >>all_rbridges_multicast address and forwards to all rbridges. >> >> > >The same would happen to all ports on a single rbridge, though. > > > >>The frame >>is received by an rbridge of the same spanning tree, decapsulated and >>retransmitted to same spanning tree. Do I miss something? >>Guillermo >> >> > >That's what I think happens too. > > > There is no problem as there is only one Designated Rbridge in the bridges spanning tree, the only that forward frames to/from that tree into the rbridges region. IMMO, the Designated Rbridge should act as Root bridge of the bridges spanning tree, so the path is optimum to all bridges of that tree. >Joe > > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EMntL11867 for <rbridge@postel.org>; Fri, 14 Oct 2005 15:49:56 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 15:49:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9EMmcKL002807; Fri, 14 Oct 2005 15:49:23 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 15:49:21 -0700 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, 14 Oct 2005 15:49:09 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8DCDB58@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge]seekinginput on abstractfor problemand applicabilitystatement Thread-Index: AcXREMt3hg+PunW1SmWa5o+54SHGDwAAEaKg From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org>, <saikat@seas.upenn.edu> X-OriginalArrivalTime: 14 Oct 2005 22:49:21.0221 (UTC) FILETIME=[842E6750:01C5D111] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9EMntL11867 Subject: Re: [rbridge] seekinginput on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 22:50:37 -0000 Status: RO Content-Length: 1016 > -----Original Message----- > From: rbridge-bounces@postel.org > > Saikat Ray wrote: > > I see the potential problem you mention with the attachment of > > spanning tree to /different/ rbridges with broadcast frames. An > > rbridge receives the broadcast frame from the spanning tree, > > encapsulates it with the all_rbridges_multicast address and > forwards > > to all rbridges. The frame is received by an rbridge of the same > > spanning tree, decapsulated and retransmitted to same > spanning tree. Do I miss something? > > Guillermo > > > > [Saikat] Only one of the RBridges would be *designated* to > encapsulate > > the packets from and decapsulate the packets to that spanning tree. > > Designated works for decapsulation, since the rbridge can > control that. > > How does the rbridge campus control which ingress is used if > the spanning tree touches it multiple times? I would expect it would be the same way. Only the designated rbridge accepts the packet. Michael > > Joe > Received: from [70.193.118.134] (134.sub-70-193-118.myvzw.com [70.193.118.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EMYtL08111; Fri, 14 Oct 2005 15:34:55 -0700 (PDT) Message-ID: <43503287.8080707@isi.edu> Date: Fri, 14 Oct 2005 15:34:47 -0700 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> References: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> <43502ABB.4040007@it.uc3m.es> In-Reply-To: <43502ABB.4040007@it.uc3m.es> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB9D991D5B4447FB83E4CAF8B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seekinginput on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 22:35:23 -0000 Status: RO Content-Length: 1201 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB9D991D5B4447FB83E4CAF8B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guillermo Ib=E1=F1ez wrote: > Guillermo Ib=E1=F1ez wrote: > =20 > OK. So the designated Rbridge should act as root bridge of that spannin= g=20 > tree, for a shortest path to all bridges of spanning trees. To do that, it would need to emit BPDUs to all edge trees to announce it was the root, wouldn't it? Only then could it KNOW that the ingresses it expects from each spanning tree would be the ones used (e.g., for those attached multiple times). (which would be back to PARTICIPATE) Joe --------------enigB9D991D5B4447FB83E4CAF8B 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUDKHE5f5cImnZrsRAvm2AKDXco9QMi3xpBYWdAY36ipmXzBi5wCgkxsy gx6xiDby7UTz/L98bjCpQCU= =S/BQ -----END PGP SIGNATURE----- --------------enigB9D991D5B4447FB83E4CAF8B-- Received: from [70.193.118.134] (134.sub-70-193-118.myvzw.com [70.193.118.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EMXQL07742; Fri, 14 Oct 2005 15:33:27 -0700 (PDT) Message-ID: <4350322C.40503@isi.edu> Date: Fri, 14 Oct 2005 15:33:16 -0700 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: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> In-Reply-To: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE7A7203E3879955AB3DC3078" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seekinginput on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 22:34:22 -0000 Status: RO Content-Length: 1485 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7A7203E3879955AB3DC3078 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > I see the potential problem you mention with the attachment of spanning > tree to /different/ rbridges with broadcast frames. An rbridge receives > the broadcast frame from the spanning tree, encapsulates it with the > all_rbridges_multicast address and forwards to all rbridges. The frame > is received by an rbridge of the same spanning tree, decapsulated and > retransmitted to same spanning tree. Do I miss something? > Guillermo > > [Saikat] Only one of the RBridges would be *designated* to encapsulate the > packets from and decapsulate the packets to that spanning tree. Designated works for decapsulation, since the rbridge can control that. How does the rbridge campus control which ingress is used if the spanning tree touches it multiple times? Joe --------------enigE7A7203E3879955AB3DC3078 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUDIsE5f5cImnZrsRAuc5AKDuK1yKA9V0WxoMsI1atpq3DkINAQCg7uFf zeUgXXXllf2LmEjsRRvROZ0= =gvyW -----END PGP SIGNATURE----- --------------enigE7A7203E3879955AB3DC3078-- Received: from [70.193.118.134] (134.sub-70-193-118.myvzw.com [70.193.118.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EMUNL06880; Fri, 14 Oct 2005 15:30:23 -0700 (PDT) Message-ID: <43503177.9090508@isi.edu> Date: Fri, 14 Oct 2005 15:30:15 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CF3@zcarhxm2.corp.nortel.com> <43501A04.1020402@isi.edu> <435024C0.6010704@it.uc3m.es> In-Reply-To: <435024C0.6010704@it.uc3m.es> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8CE0FB118C111118E40B6595" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 22:31:19 -0000 Status: RO Content-Length: 3337 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8CE0FB118C111118E40B6595 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guillermo Ib=E1=F1ez wrote: > I am not sure I interpreted the terms right. My understanding is that=20 > rbridges must participate in the spanning tree. This is required to=20 > avoid loops if two links of same network get attached to same rbridge.= =20 > But rbridges must act as hosts, I have always disagreed with that assertion. To the outside of the network: I thought they would always act as if a single bridge (meaning PARTICIPATE); I understand now how they might act as if a single hub/link (TRANSPARENT). To bridges they send encapsulated packets over, the ingress rbridges look like hosts, but that's only to transit the L2. > should not > forward received BPDUs to other ports of rbridge, as it is much more =20 > efficient and faster to converge, to have many small spanning trees tha= n=20 > a big one. I agree with that, except that this argues that existing bridges should act in the same way. But they don't. I'm not sure they can. > Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a=20 > path to complexity, opposite to selfconfiguration. Manual configuration is the opposite of selfconfiguration. Selfconfiguration does not prohibit complexity, provided the complexity can be selfconfigured - which I think it can. > See below my comment on loops with broadcast frames. =2E.. >>How do I know they're disjoint trees, and what happens if (when) they >>get interconnected? >> >>If a spanning tree is attached to the rbridge in more than one place, >>what happens with broadcasts? Won't they create a loop? >=20 > If there are two attachments to the same spanning tree to the same=20 > rbridge one of them acts as designated port and the other will be > blocked by the spanning tree protocol. The only reason it'd be blocked is if the spanning tree protocol knew both rbridges were part of the same spanning tree. I thought that's what the BPDUs would indicate. > Participation in STP is needed=20 > for that. That's what I thought - but that requires PARTICIPATE, right? > I see the potential problem you mention with the attachment of spanning= =20 > tree to /different/ rbridges In the same campus? Why does that matter? > with broadcast frames. An rbridge receives=20 > the broadcast frame from the spanning tree, encapsulates it with the=20 > all_rbridges_multicast address and forwards to all rbridges. The same would happen to all ports on a single rbridge, though. > The frame=20 > is received by an rbridge of the same spanning tree, decapsulated and=20 > retransmitted to same spanning tree. Do I miss something? > Guillermo That's what I think happens too. Joe --------------enig8CE0FB118C111118E40B6595 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUDF3E5f5cImnZrsRAvsNAKCW3MakmEYUstN3vfGdAAXooUeSvwCdGE8a 3S5bzu8fqNCuIfK/BG7LB2E= =1lAv -----END PGP SIGNATURE----- --------------enig8CE0FB118C111118E40B6595-- 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 j9EM1cL29501 for <rbridge@postel.org>; Fri, 14 Oct 2005 15:01:38 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 599289D01E; Sat, 15 Oct 2005 00:01:32 +0200 (CEST) Received: from [163.117.203.181] (unknown [163.117.203.181]) by smtp01.uc3m.es (Postfix) with ESMTP id 376399D101; Sat, 15 Oct 2005 00:01:31 +0200 (CEST) Message-ID: <43502ABB.4040007@it.uc3m.es> Date: Sat, 15 Oct 2005 00:01:31 +0200 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: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> In-Reply-To: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> 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] seekinginput on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 22:02:12 -0000 Status: RO Content-Length: 1737 Guillermo Ib??ez wrote: OK. So the designated Rbridge should act as root bridge of that spanning tree, for a shortest path to all bridges of spanning trees. Saikat Ray wrote: >I see the potential problem you mention with the attachment of spanning >tree to /different/ rbridges with broadcast frames. An rbridge receives >the broadcast frame from the spanning tree, encapsulates it with the >all_rbridges_multicast address and forwards to all rbridges. The frame >is received by an rbridge of the same spanning tree, decapsulated and >retransmitted to same spanning tree. Do I miss something? >Guillermo > >[Saikat] Only one of the RBridges would be *designated* to encapsulate the >packets from and decapsulate the packets to that spanning tree. > > > >> >> >> >> >>>The >>>worst it can do is change the routes because you get two STP trees each >>>with different root bridges ... which is not always ideal and why I >>>think you need TRANSPARENT AND BLOCK options at different phases of a >>>migration ... and possibly even Ships in the Night mode too. >>> >>> >>> >>> >>SITN assumes some level of manual configuration - you have to know which >>ship you're on ;-) >> >>Joe >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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 j9ELwmL28860 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:58:48 -0700 (PDT) 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 j9ELwhrP016607 for <rbridge@postel.org>; Fri, 14 Oct 2005 17:58:43 -0400 (EDT) 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 RAA14116 for <rbridge@postel.org>; Fri, 14 Oct 2005 17:58:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPH2S4>; Fri, 14 Oct 2005 18:58:42 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F99@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 18:58:40 -0300 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] seeking inputon abstractfor problemand applicabilit ystatement 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, 14 Oct 2005 21:59:13 -0000 Status: RO Content-Length: 844 Joe, You said: [Even] if each edge is its own tree, it can touch the rbridge in more than one place (if not, why not?) It seems like the internal spanning tree needs to 'pick' one of those tree attachment points to join to, so that one overall tree is picked. But that's back to PARTICIPATE rather than BLOCK. No. See earlier mail. Please. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Friday, October 14, 2005 4:55 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking inputon abstractfor problemand --> applicabilitystatement --> --> --> _______________________________________________ --> 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 j9ELthL28200 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:55:44 -0700 (PDT) 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 j9ELtcrP016580 for <rbridge@postel.org>; Fri, 14 Oct 2005 17:55:38 -0400 (EDT) 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 RAA13943 for <rbridge@postel.org>; Fri, 14 Oct 2005 17:55:38 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPH2QX>; Fri, 14 Oct 2005 18:55:37 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F98@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 18:55:36 -0300 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] seeking input on abstractfor problemand applicabili tystatement 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, 14 Oct 2005 21:56:13 -0000 Status: RO Content-Length: 3286 Joe, You said: I'm not sure whether the 802 specs allow for a non-hub device to not participate in the spanning tree alg. Anyone else know? The 802 specs mostly address Ethernet forwarding and bridge behavior for STP. A lot of bridge behavior (like the entire section on bridge learning) was removed in more recent versions of the specification. As an aside, the reason I know this is that we (Cabletron at that time) had filed a patent application that listed the removed text as "prior art" and - consequently - had to dig up a prior version to hand over to the USPTO. As pointed out by Dino earlier, irrespective of what 802 says, many implementations allow STP to be turned off for specific bridge ports. Clearly this can work. You also asked: If a spanning tree is attached to the rbridge in more than one place, what happens with broadcasts? Won't they create a loop? Radia had earlier answered this question for me though it may have been in an unrecognizably similar form. I had asked what would happen if I deploy one RBridge into a network that does not segment it. Note that this is an isomorphism of the situ you ask about. The answer turns out to be straight forward. RBridges do not have to completely ignore STP, so an RBridge can determine it has more than one port on the same local bridged network (Erik was uncomfortable with referring to it as a "local broadcast domain"). Also, even if it does not do this, the RBridge will hear its own hello messages on different interfaces - allowing it to conclude that it has more than one interface on the same local bridged network. Note that - like bridges during STP - RBridges SHOULD not be forwarding frames until they have determined how to do so. Note that the same observation applies whether the interfaces for which this is true are "internal" or "external" to the RBridge campus. Once the RBridge has determined that it has more than one port in the same local briged network, then what it does next will depend on whether it "hears" another RBridge on that same local bridged network. Note that - again - this could occur for either the "internal" or "external" case, since nothing exists to preclude connecting one RBridge campus to another. If the RBridge hears one or more additional RBridges on the same port, then it will determine appropriate SPST paths via routing protocol interactions with that (or those) other RBridge(s). If it does not, then it may decide to only forward broadcast frames on one of those interfaces - either way - thus preventing loops in broadcast/multicast traffic, or it might do something clever (that we do not need to specify in this context). It is enough to show that there is a single proof of concept way in which to prevent looping broadcast frames. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Friday, October 14, 2005 4:50 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstractfor problemand --> applicabilitystatement --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9ELkQL25780 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:46:26 -0700 (PDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA26378 for <rbridge@postel.org>; Fri, 14 Oct 2005 16:46:21 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9ELkKm06903 for <rbridge@postel.org>; Fri, 14 Oct 2005 16:46:21 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 14:46:20 -0700 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, 14 Oct 2005 14:46:20 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC836963B@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstractfor problemand applicabilitystatement Thread-Index: AcXRAKRdINrzaropQCqyYWzCNVFHIgAB/WVw From: "Drake, John E" <John.E.Drake2@boeing.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 14 Oct 2005 21:46:20.0448 (UTC) FILETIME=[B6AA3A00:01C5D108] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: john.e.drake2@boeing.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9ELkQL25780 Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 21:47:12 -0000 Status: RO Content-Length: 297 > > So I see no advantage in RBridges forwarding spanning tree messages. In > contrast, the > advantage of having them discard them is that then the little spanning > trees formed by > bridged islands are smaller, and independent of each other. [JD] When they get older, will they get bigger? Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9ELghL24672 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:42:43 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9ELggVb027241 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Fri, 14 Oct 2005 17:42:42 -0400 Message-Id: <200510142142.j9ELggVb027241@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 17:42:48 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXRB4QH/gPd1pSKS+6N8JcNzuEqEQAAIZCA In-reply-to: <435024C0.6010704@it.uc3m.es> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] seekinginput on abstractfor problemand applicabilitystatement X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 14 Oct 2005 21:43:15 -0000 Status: RO Content-Length: 1336 I see the potential problem you mention with the attachment of spanning tree to /different/ rbridges with broadcast frames. An rbridge receives the broadcast frame from the spanning tree, encapsulates it with the all_rbridges_multicast address and forwards to all rbridges. The frame is received by an rbridge of the same spanning tree, decapsulated and retransmitted to same spanning tree. Do I miss something? Guillermo [Saikat] Only one of the RBridges would be *designated* to encapsulate the packets from and decapsulate the packets to that spanning tree. > > >>The >>worst it can do is change the routes because you get two STP trees each >>with different root bridges ... which is not always ideal and why I >>think you need TRANSPARENT AND BLOCK options at different phases of a >>migration ... and possibly even Ships in the Night mode too. >> >> > >SITN assumes some level of manual configuration - you have to know which >ship you're on ;-) > >Joe > > >------------------------------------------------------------------------ > >_______________________________________________ >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 smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9ELa7L23112 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:36:08 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0297D9D34D for <rbridge@postel.org>; Fri, 14 Oct 2005 23:36:01 +0200 (CEST) Received: from [163.117.203.181] (unknown [163.117.203.181]) by smtp01.uc3m.es (Postfix) with ESMTP id 10FB39D336 for <rbridge@postel.org>; Fri, 14 Oct 2005 23:36:00 +0200 (CEST) Message-ID: <435024C0.6010704@it.uc3m.es> Date: Fri, 14 Oct 2005 23:36:00 +0200 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: <713043CE8B8E1348AF3C546DBE02C1B405213CF3@zcarhxm2.corp.nortel.com> <43501A04.1020402@isi.edu> In-Reply-To: <43501A04.1020402@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 21:36:40 -0000 Status: RO Content-Length: 3274 I am not sure I interpreted the terms right. My understanding is that rbridges must participate in the spanning tree. This is required to avoid loops if two links of same network get attached to same rbridge. But rbridges must act as hosts, should not forward received BPDUs to other ports of rbridge, as it is much more efficient and faster to converge, to have many small spanning trees than a big one. Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a path to complexity, opposite to selfconfiguration. See below my comment on loops with broadcast frames. Joe Touch wrote: >Peter Ashwood-Smith wrote: > > >>>My understanding is that PARTICIPATE is valid, if not required. >>> >>> >>TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would >>break things. >> >> PARTICIPATE is definitely valid, but I disagree it is always required. >>Its definitely useful though. It is only always required if both of >>TRANSPARENT and BLOCK do not work. >> >> Yup, TRANSPARENT turns the rbridge network into a hub therefore it is >>also valid with different trade-offs. Therefore PARTICIPATE is not >>always required it is simply valid. >> >> > >The only reason I could imagine a difference in requirement is that a >hub broadcasts everything, so 'TRANSPARENT' is consistent with how it >handles other frames. > >I'm not sure whether the 802 specs allow for a non-hub device to not >participate in the spanning tree alg. Anyone else know? > > >(i.e., this might be a spec equivalance issue) > > > >> BLOCK will break things? How. I think I've convinced myself this is >>not possible in the steady state (because you have nodally disjoint >>trees joined by a single link therefore a loop is not possible). >> >> > >How do I know they're disjoint trees, and what happens if (when) they >get interconnected? > >If a spanning tree is attached to the rbridge in more than one place, >what happens with broadcasts? Won't they create a loop? > > If there are two attachments to the same spanning tree to the same rbridge one of them acts as designated port and the other will be blocked by the spanning tree protocol. Participation in STP is needed for that. I see the potential problem you mention with the attachment of spanning tree to /different/ rbridges with broadcast frames. An rbridge receives the broadcast frame from the spanning tree, encapsulates it with the all_rbridges_multicast address and forwards to all rbridges. The frame is received by an rbridge of the same spanning tree, decapsulated and retransmitted to same spanning tree. Do I miss something? Guillermo > > >>The >>worst it can do is change the routes because you get two STP trees each >>with different root bridges ... which is not always ideal and why I >>think you need TRANSPARENT AND BLOCK options at different phases of a >>migration ... and possibly even Ships in the Night mode too. >> >> > >SITN assumes some level of manual configuration - you have to know which >ship you're on ;-) > >Joe > > >------------------------------------------------------------------------ > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from [70.193.118.134] (134.sub-70-193-118.myvzw.com [70.193.118.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9ELFQL17547; Fri, 14 Oct 2005 14:15:37 -0700 (PDT) Message-ID: <43501FE5.40206@isi.edu> Date: Fri, 14 Oct 2005 14:15:17 -0700 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> References: <313680C9A886D511A06000204840E1CF0C885F8F@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F8F@whq-msgusr-02.pit.comms.marconi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CFDAAF7052D2A866908C380" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problemand applicabil itystatement 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, 14 Oct 2005 21:16:25 -0000 Status: RO Content-Length: 7958 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CFDAAF7052D2A866908C380 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gray, Eric wrote: > Joe, > > I want to address specific comments/questions you > had below: > > -> All of this sounds like stuff the rbridge already > needs to do; there needs to be an internal spanning > tree anyway. > > We have not yet decided how many "spanning trees" there > needs to be, and that is a part of the problem. One of > the goals of the original proposal - as I understand it > - was to allow efficient use of redundant links that may > exist between RBridges. > > This is why the confusion keeps coming up with the use > of the term spanning tree. Its NOT the right term in > the RBridge context, because the RBridges WILL NOT be > turning ports off and WILL be forwarding distinguishable > streams of frames on as many of the available links as > it makes sense to use, given the destinations and - for > example - VLAN contexts that apply to each stream. I'm not sure I agree. The edges are individual spanning trees. The rbridge can have more than one internal path between two edge trees, but that's it, that's all the redundency that's provided. Turning off ports on the outside edge of the rbridge has no effect on the internal multipath potential. > Another goal - again as I understand it - is to reduce > the time for convergence on spanning trees for those > portions of the network that MUST use STP (the bridges). > For that goal to be achieved, it is a good idea not to > extend STP across the RBridges. I definitely disagree with this. Rbridges have nothing to do with the convergence of the spanning tree external to them, IMO. All they do is have their INTERNAL routing converge faster than spanning tree would have - that's where the benefit comes from. I never thought it had anything to do with an effect on the external trees. > Finally, there is a huge "chicken-and-egg" problem with > any intention to have RBridges participate in STP. > > The "spanning tree(s)" determined by RBridges are the > result of shortest path analysis of reachability info > provided by IS-IS. If this is not the case, then there > was never any reason to suggest using a shortest-path, > Link State Routing Protocol in the first place. > > However, before the RBridges can reliably determine > link state and advertise reachability, any "internal" > bridges MUST have already determined a spanning tree > (using STP). As I pointed out previously, and Radia > stated as well, bridges typically do not forward during > STP, consequently some or all of the links between the > RBridges will be DOWN as far as IS-IS is concerned. That's just like adding a bridge to an existing bridged system. The new bridge doesn't forward frames until STP finishes, but the existing bridges can finish just fine. The rbridge is the 'new' bridge. All the other bridges are the existing bridge system. No chicken and egg, AFAICT; the sequence is determined by rbridge's reliance on bridges. > Also, again as pointeed out previously, "internal" and > "external" are topologically meaningless terms as far > as RBridges are concerned - unless that information is > explicitly configured. Consequently, default RBridge > behavior really MUST be to ignore STP on any port not > explicitly configured to participate in STP. Yes. And not to forward ingress frames until internal routing (IS-IS in this case) is established. At that point, STP should be enabled at the 'edges', STP PARTICIPATEd, and -then- ingress enabled. What's the problem? > Also, because the link state between RBridges is not > determined until after any internal STP required has > been completed between bridges that may be involved > in those links, either the RBridges have to wait a > pre-determined period of time (to blindly allow for > "internal" STP) or send topology change BPDUs on all > ports every time they discover new links. Either way > will result in potentially huge delays in overall STP > convergence time for the network. Again, I'm back to 'what would a bridge do'. Either this is a bridge (PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are the only two options that have correlaries in existing L2. > -> I'd like someone to explain which of these are valid > if we replace the rbridge campus with an existing > bridge. > > I am not sure that this concept of a "virtual bridge" > is - or ever has been - a goal for RBridges. It's not a goal; it's a definition, IMO. > If you > want a "virtual bridge", one approach that already is > out there is VPLS. Consequently, why would we need > to specify how to do it with RBridges? VPLS, depending on where I look, are either pseudowires (virtual hubs) or L2 over L3. Rbridge is L2 over L2 with routing. > If it is not a goal, then the notion of replacing an > RBridge with a single bridge is not something we need > to consider. > > -> My understanding is that PARTICIPATE is valid, if not > required. TRANSPARENT seems like it turns the bridge > into a hub. And BLOCK would break things. > > Assuming that this _is_ a goal, there is no particular > reason why someone would not replace a hub (even a > "virtual hub") with a bridge. For reasons explained > above, however, PARTICIPATE - while potentially valid > - is extremely undesirable. If you replace a hub with a bridge that refuses to PARTICIPATE, what's the effect? Nothing. That assumes that hubs weren't in rings, which they weren't supposed to be. However, you CAN wire bridges in rings and they're supposed to do the right thing. That's only because they PARTICIPATE, though. > Transparent also is not good because the path through > the RBridges will not exist (or not be complete) until > A) STP is completed between any "internal" bridges and > B) the RBridges have converged on a complete LSDB and > determine SPSTs (shortest path spanning trees). I already answered this in a separate email; yes, both of these steps need to happen in order, and they will. > So, even with Transparent, the insertion of RBridges > would result in increased STP convergence time, even > if the network size has not changed. That's an interesting question - that may be the result of having an internal routing protocol that isn't setup ahead of time. I.e., maybe rbridges DO take longer to *initially* converge the STP of an existing net, but react faster *afterwards* to changes. > In addition, TRANSPARENT would require configuration > of the RBridges to recognize "external" interfaces - The need to know which interfaces they can reach rbridges on, which can (and should) be autoconfigured. > since it is clearly not the case that, even in this > mode, you would want bridges inside an RBridge campus > to participate with bridges outside that campus. As > implied previously, having all bridges - both inside > and outside of an RBridge campus - participating in > forming a single spanning tree would prevent using > redundant paths (and would very likely drop RBridge > ports out of the topology as the corresponding bridge > ports - at the other end of the physical link - are > put in the non-forwarding state). I also already answered this - rbridges can't make redundent paths in the non-rbridge portion of an L2 net. They can only do so within the rbridge. Joe --------------enig2CFDAAF7052D2A866908C380 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUB/lE5f5cImnZrsRAiPVAKCfIdaPVIDRZjXGVtwjfe0O2u+B2QCgxC2M rv4PKCSLHJj9GAuA4okHQQY= =ThF1 -----END PGP SIGNATURE----- --------------enig2CFDAAF7052D2A866908C380-- Received: from [70.193.118.134] (134.sub-70-193-118.myvzw.com [70.193.118.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EKt4L11932; Fri, 14 Oct 2005 13:55:04 -0700 (PDT) Message-ID: <43501B1F.70405@isi.edu> Date: Fri, 14 Oct 2005 13:54:55 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CF4@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213CF4@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig545E008B86EF181E7C3FCE4C" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking inputon abstractfor problemand applicabilitystatement 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, 14 Oct 2005 20:55:16 -0000 Status: RO Content-Length: 2539 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig545E008B86EF181E7C3FCE4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: >>>I think I missed something, what breaks if we block BPDUs ? > > >>If nothing, then lets. For bridges too. >>Now what happens? (i.e., if bridges block BPDUs) - won't that kill the > > spanning tree? > > Yes of course if you block a BPDU the bridge will stop the STP tree at > that point. Thats exactly what we are trying to do. Stop the STP > computed portion of the FULL tree at that point. > > With BLOCK. Each protocol computes its own smaller part of the bigger > spanning tree. > STP computes using BPDUS etc. and Rbridge computes using > IS-IS/Krusal's. Eve if each edge is its own tree, it can touch the rbridge in more than one place (if not, why not?) It seems like the internal spanning tree needs to 'pick' one of those tree attachment points to join to, so that one overall tree is picked. But that's back to PARTICIPATE rather than BLOCK. > When done you have a bunch of unconnected spanning trees which are made > into one big tree by the designated rbridge concept i.e. single link. The rbridge isn't acting like a link. It acts like a link in TRANSPARENT mode; in that case, when one edge tree send a BPDU to the link, everyone on the link (all the other edge trees) will receive it. > To convince yourself that this really works. Draw an arbitrary tree on > a piece of paper. Then draw another disjoint tree somewhere else on the > paper. You can make one big tree by connecting any two of the points > between the two trees and you cannot create a loop with single link. > That is why BLOCK works. The only way it'll work like a single link is in TRANSPARENT - consider a spanning tree that touches the 'connecting link' (the rbridge) in more than one place (which is valid). The reason the spanning tree would pick only one of those to join is because of the BDPU messages. Joe --------------enig545E008B86EF181E7C3FCE4C 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUBsfE5f5cImnZrsRAvKkAKDdrQ0OYZYg20BOppaX1rIUpaTHGQCgm2Uu pvNA2QE7+WcqF2xqXVHRD/w= =AdJp -----END PGP SIGNATURE----- --------------enig545E008B86EF181E7C3FCE4C-- Received: from [70.193.118.134] (134.sub-70-193-118.myvzw.com [70.193.118.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EKoLL10753; Fri, 14 Oct 2005 13:50:21 -0700 (PDT) Message-ID: <43501A04.1020402@isi.edu> Date: Fri, 14 Oct 2005 13:50:12 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CF3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213CF3@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2A839AA38DEDE46A826D8662" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 20:51:14 -0000 Status: RO Content-Length: 2398 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2A839AA38DEDE46A826D8662 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: >>My understanding is that PARTICIPATE is valid, if not required. > > TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would > break things. > > PARTICIPATE is definitely valid, but I disagree it is always required. > Its definitely useful though. It is only always required if both of > TRANSPARENT and BLOCK do not work. > > Yup, TRANSPARENT turns the rbridge network into a hub therefore it is > also valid with different trade-offs. Therefore PARTICIPATE is not > always required it is simply valid. The only reason I could imagine a difference in requirement is that a hub broadcasts everything, so 'TRANSPARENT' is consistent with how it handles other frames. I'm not sure whether the 802 specs allow for a non-hub device to not participate in the spanning tree alg. Anyone else know? (i.e., this might be a spec equivalance issue) > BLOCK will break things? How. I think I've convinced myself this is > not possible in the steady state (because you have nodally disjoint > trees joined by a single link therefore a loop is not possible). How do I know they're disjoint trees, and what happens if (when) they get interconnected? If a spanning tree is attached to the rbridge in more than one place, what happens with broadcasts? Won't they create a loop? > The > worst it can do is change the routes because you get two STP trees each > with different root bridges ... which is not always ideal and why I > think you need TRANSPARENT AND BLOCK options at different phases of a > migration ... and possibly even Ships in the Night mode too. SITN assumes some level of manual configuration - you have to know which ship you're on ;-) Joe --------------enig2A839AA38DEDE46A826D8662 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDUBoEE5f5cImnZrsRAqkAAJ9zPvrYTuay1YmWmor/dki7f6ng+ACg/C8y VM6xnT+hyJHxQKUWoT/rWe0= =wn3H -----END PGP SIGNATURE----- --------------enig2A839AA38DEDE46A826D8662-- 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 j9EKiQL08625 for <rbridge@postel.org>; Fri, 14 Oct 2005 13:44:26 -0700 (PDT) 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 <0IOD00K2HAXXLF00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 14 Oct 2005 13:44:21 -0700 (PDT) Received: from sun.com ([129.150.28.127]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOD00K95AXW2300@mail.sunlabs.com> for rbridge@postel.org; Fri, 14 Oct 2005 13:44:21 -0700 (PDT) Date: Fri, 14 Oct 2005 13:44:24 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <313680C9A886D511A06000204840E1CF0C885F91@whq-msgusr-02.pit.comms.marconi.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <435018A8.1050903@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: <313680C9A886D511A06000204840E1CF0C885F91@whq-msgusr-02.pit.comms.marconi.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] seeking input on abstractfor problemand applicabili tystatement 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, 14 Oct 2005 20:45:12 -0000 Status: RO Content-Length: 599 Actually, thinking about it a bit more...it really scares me to have RBridges forwarding spanning tree messages. RBridges would then be wormholing spanning tree messages, so bridges might mysteriously get spanning tree messages from someone that is really several hops away. This probably would only occur during transient states, but it seems scary. So I see no advantage in RBridges forwarding spanning tree messages. In contrast, the advantage of having them discard them is that then the little spanning trees formed by bridged islands are smaller, and independent of each other. Radia 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 j9EJUdL16449 for <rbridge@postel.org>; Fri, 14 Oct 2005 12:30:39 -0700 (PDT) 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 j9EJUYrP013613 for <rbridge@postel.org>; Fri, 14 Oct 2005 15:30:34 -0400 (EDT) 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 PAA00241 for <rbridge@postel.org>; Fri, 14 Oct 2005 15:30:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPH1NC>; Fri, 14 Oct 2005 16:30:33 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F91@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 16:30:32 -0300 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] seeking input on abstractfor problemand applicabili tystatement 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, 14 Oct 2005 19:31:19 -0000 Status: RO Content-Length: 2222 Michael, "What breaks" is - from the original context - the assumption that an RBridge campus looks to the outside world like a single bridge. As stated in other mail, I don't think this is a goal for the work we're doing. If BLOCKING is used - as I believe must be the case by default - then an RBridge looks like "the rest of the world" to external bridges. In other words, external bridges see and learn SA MAC addresses from all traffic the RBridge injects onto the shared link - just as if the devices corresponding to the addresses were also on that link. As far as local bridges are concerned - in this case - the spanning tree ends (or starts, depending on perspective) with that link. The same is true for internal bridges - except that, owing to the encapsulation of frames in an extra MAC header + shim, the internal bridges only see SA MAC addresses for RBridges. The terms "internal" and "external" in this context are not significant to the behavior of bridges or RBridges in this mode. I use them because they determine 1) the scope of each STP and 2) SA MAC visibility at bridges. Note that this also works just fine if one RBridge campus is attached to another. In this case, no STP takes place between the RBridges themselves (though STP may take place between bridges on the link). In this case, the term "external" is particularly "interesting". -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Michael Smith (michsmit) --> Sent: Friday, October 14, 2005 1:39 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstractfor problemand --> applicabilitystatement --> --> --> --> > -----Original Message----- --> > From: rbridge-bounces@postel.org --> > --> > My understanding is that PARTICIPATE is valid, if not required. --> > TRANSPARENT seems like it turns the bridge into a hub. And --> > BLOCK would break things. --> --> I think I missed something, what breaks if we block BPDUs ? --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EInqL05476 for <rbridge@postel.org>; Fri, 14 Oct 2005 11:49:52 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2005 11:49:20 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="352254927:sNHT45431240" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EImpv1025886 for <rbridge@postel.org>; Fri, 14 Oct 2005 11:49:18 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 11:49:17 -0700 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, 14 Oct 2005 11:49:16 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D879F461B@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seekinginputon abstractfor problemand applicabilitystatement Thread-Index: AcXQ6Q0gdPf0G98dR52bvv+okF/OGAAAClEgAAFbeZA= From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 14 Oct 2005 18:49:17.0663 (UTC) FILETIME=[FAFDDEF0:01C5D0EF] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9EInqL05476 Subject: Re: [rbridge] seekinginputon abstractfor problemand applicabilitystatement 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, 14 Oct 2005 18:50:10 -0000 Status: RO Content-Length: 2396 If rbridges blocked BPDUs, you may lose the root-id and root-cost information of the spanning tree. Thus, the points at which the rbridge spanning tree hooks up to L2 spanning tree may not be optimal. i.e. Consider rbridge cloud having many intersections with external spanning tree cloud. The choice about boundary ports (designated rbridges) may have to be made entirely based on rbridge's view of the topology. Whereas, if rbridges participated, and -- created their own internal spanning tree -- propogate the external L2 spanning tree BPDU over its internal spanning tree, thus retaining the root-information to make good choices about boundary ports. -- participate with external L2 spanning tree only at the "boundary ports" -- turn the rbridge cloud into a single virtual bridge. (this would look similar to how MSTP region (802.1s) interacts with CIST at boundary ports) Thanks, Sanjay >-----Original Message----- >From: rbridge-bounces@postel.org >[mailto:rbridge-bounces@postel.org] On Behalf Of Peter Ashwood-Smith >Sent: Friday, October 14, 2005 11:18 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] seekinginputon abstractfor problemand >applicabilitystatement > > >>> I think I missed something, what breaks if we block BPDUs ? > >>If nothing, then lets. For bridges too. >> Now what happens? (i.e., if bridges block BPDUs) - won't >that kill the >spanning tree? > > Yes of course if you block a BPDU the bridge will stop the >STP tree at that point. Thats exactly what we are trying to >do. Stop the STP computed portion of the FULL tree at that point. > > With BLOCK. Each protocol computes its own smaller part of >the bigger spanning tree. > STP computes using BPDUS etc. and Rbridge computes using >IS-IS/Krusal's. > > When done you have a bunch of unconnected spanning trees >which are made into one big tree by the designated rbridge >concept i.e. single link. > > To convince yourself that this really works. Draw an >arbitrary tree on a piece of paper. Then draw another disjoint >tree somewhere else on the paper. You can make one big tree by >connecting any two of the points between the two trees and you >cannot create a loop with single link. >That is why BLOCK works. > > Peter >_______________________________________________ >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 j9EIntL05507 for <rbridge@postel.org>; Fri, 14 Oct 2005 11:49:56 -0700 (PDT) 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 j9EInhrP012401 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:49:44 -0400 (EDT) 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 OAA24977 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:49:39 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPHC8R>; Fri, 14 Oct 2005 15:49:38 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F8F@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 14 Oct 2005 15:49:37 -0300 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] seeking input on abstract for problemand applicabil itystatement 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, 14 Oct 2005 18:50:11 -0000 Status: RO Content-Length: 8023 Joe, I want to address specific comments/questions you had below: -> All of this sounds like stuff the rbridge already needs to do; there needs to be an internal spanning tree anyway. We have not yet decided how many "spanning trees" there needs to be, and that is a part of the problem. One of the goals of the original proposal - as I understand it - was to allow efficient use of redundant links that may exist between RBridges. This is why the confusion keeps coming up with the use of the term spanning tree. Its NOT the right term in the RBridge context, because the RBridges WILL NOT be turning ports off and WILL be forwarding distinguishable streams of frames on as many of the available links as it makes sense to use, given the destinations and - for example - VLAN contexts that apply to each stream. Another goal - again as I understand it - is to reduce the time for convergence on spanning trees for those portions of the network that MUST use STP (the bridges). For that goal to be achieved, it is a good idea not to extend STP across the RBridges. Finally, there is a huge "chicken-and-egg" problem with any intention to have RBridges participate in STP. The "spanning tree(s)" determined by RBridges are the result of shortest path analysis of reachability info provided by IS-IS. If this is not the case, then there was never any reason to suggest using a shortest-path, Link State Routing Protocol in the first place. However, before the RBridges can reliably determine link state and advertise reachability, any "internal" bridges MUST have already determined a spanning tree (using STP). As I pointed out previously, and Radia stated as well, bridges typically do not forward during STP, consequently some or all of the links between the RBridges will be DOWN as far as IS-IS is concerned. Also, again as pointeed out previously, "internal" and "external" are topologically meaningless terms as far as RBridges are concerned - unless that information is explicitly configured. Consequently, default RBridge behavior really MUST be to ignore STP on any port not explicitly configured to participate in STP. Also, because the link state between RBridges is not determined until after any internal STP required has been completed between bridges that may be involved in those links, either the RBridges have to wait a pre-determined period of time (to blindly allow for "internal" STP) or send topology change BPDUs on all ports every time they discover new links. Either way will result in potentially huge delays in overall STP convergence time for the network. -> I'd like someone to explain which of these are valid if we replace the rbridge campus with an existing bridge. I am not sure that this concept of a "virtual bridge" is - or ever has been - a goal for RBridges. If you want a "virtual bridge", one approach that already is out there is VPLS. Consequently, why would we need to specify how to do it with RBridges? If it is not a goal, then the notion of replacing an RBridge with a single bridge is not something we need to consider. -> My understanding is that PARTICIPATE is valid, if not required. TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would break things. Assuming that this _is_ a goal, there is no particular reason why someone would not replace a hub (even a "virtual hub") with a bridge. For reasons explained above, however, PARTICIPATE - while potentially valid - is extremely undesirable. Transparent also is not good because the path through the RBridges will not exist (or not be complete) until A) STP is completed between any "internal" bridges and B) the RBridges have converged on a complete LSDB and determine SPSTs (shortest path spanning trees). So, even with Transparent, the insertion of RBridges would result in increased STP convergence time, even if the network size has not changed. In addition, TRANSPARENT would require configuration of the RBridges to recognize "external" interfaces - since it is clearly not the case that, even in this mode, you would want bridges inside an RBridge campus to participate with bridges outside that campus. As implied previously, having all bridges - both inside and outside of an RBridge campus - participating in forming a single spanning tree would prevent using redundant paths (and would very likely drop RBridge ports out of the topology as the corresponding bridge ports - at the other end of the physical link - are put in the non-forwarding state). -- Eric Gray --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Friday, October 14, 2005 1:21 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstract for problemand --> applicabilitystatement --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge Earlier, Joe Touch burbled... --> Peter Ashwood-Smith wrote: >>But isn't this just what STP does? >>I.e., a bridge: >> >> accepts BPDUs as input >> determines an internal spanning tree based on port selection >> emits appropriate BPDUs on those ports >> >>Why isn't this exactly what an rbridge needs to do? I.e., neither a > > bridge > >>nor an rbridge 'transparently' forward BPDUs, but both are nodes in the >>resulting spanning tree. > > > Hmmm so you have added yet a third possibility. At this point I think > giving them names is probably helpful. Here is what I'd suggest. > > [BLOCK] Rbridge block BPDU's > [TRANSPARENT] Rbridge transparently passes BPDU's > [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's) > > >>This still provides a benefit for an rbridge - that it is just ONE > > node in > the spanning tree, not O(#rbridges) or even O(#egress > rbridges). > > Yeah, but its messy to implement this kind of thing. We refer to that as > an abstract node in routing. Making a network appear as a single node to > its neighbors. It requires more 'internal' messaging between the > different 'parts' of the abstract node to create this illusion. For > example the BPDUs must be gathered and sorted etc. so you'd have to > elect one of the 'parts' of that node to act on behalf of the others, do > the gather/sort and regeneration. A 'designated virtual bridge' so to > speak. All of this sounds like stuff the rbridge already needs to do; there needs to be an internal spanning tree anyway. > I'd suggest that the I.D mention the three (giving them concrete names > to avoid further confusion). Personally, and I think from the emails it > sounds like we'd recommend BLOCK, allow TRANSPARENT and leave > PARTICIPATE for further study? (I can hear the graduate students > sharpening their pencils already). I'd like someone to explain which of these are valid if we replace the rbridge campus with an existing bridge. My understanding is that PARTICIPATE is valid, if not required. TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would break things. > Oh, speaking of TRANSPARENT, it may be a very useful mode during a > migration since it allows the installation of rbridges without affecting > the bulk of the paths. BLOCK would result in a sudden change in root > bridge on one side of the Rbridged network with resulting sudden shift > in traffic patterns. For some carefully crafted networks that sudden > change may be a bit of a shock and an impediment to migration so while > undesirable in the final state, it may be useful during transition ... > unless we mandate ships in the night with a quick switchover when all > bridges were replaced with rbridges ... but I've not seen this done very > often successfully. > > Peter Ashwood-Smith > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EIIOL26858 for <rbridge@postel.org>; Fri, 14 Oct 2005 11:18:24 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9EIIGC23809 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:18:16 -0400 (EDT) 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, 14 Oct 2005 14:18:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CF4@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking inputon abstractfor problemand applicabilitystatement Thread-Index: AcXQ6Q0gdPf0G98dR52bvv+okF/OGAAAClEg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9EIIOL26858 Subject: Re: [rbridge] seeking inputon abstractfor problemand applicabilitystatement 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, 14 Oct 2005 18:19:10 -0000 Status: RO Content-Length: 1005 >> I think I missed something, what breaks if we block BPDUs ? >If nothing, then lets. For bridges too. > Now what happens? (i.e., if bridges block BPDUs) - won't that kill the spanning tree? Yes of course if you block a BPDU the bridge will stop the STP tree at that point. Thats exactly what we are trying to do. Stop the STP computed portion of the FULL tree at that point. With BLOCK. Each protocol computes its own smaller part of the bigger spanning tree. STP computes using BPDUS etc. and Rbridge computes using IS-IS/Krusal's. When done you have a bunch of unconnected spanning trees which are made into one big tree by the designated rbridge concept i.e. single link. To convince yourself that this really works. Draw an arbitrary tree on a piece of paper. Then draw another disjoint tree somewhere else on the paper. You can make one big tree by connecting any two of the points between the two trees and you cannot create a loop with single link. That is why BLOCK works. Peter Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EI0UL21189 for <rbridge@postel.org>; Fri, 14 Oct 2005 11:00:30 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9EI0J708847 for <rbridge@postel.org>; Fri, 14 Oct 2005 14:00:20 -0400 (EDT) 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, 14 Oct 2005 14:00:16 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CF3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstractfor problemand applicabilitystatement Thread-Index: AcXQ5IxS6DU58rBHQ1aH+isy6sxlPwAAZAQg From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9EI0UL21189 Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 18:01:09 -0000 Status: RO Content-Length: 1014 > My understanding is that PARTICIPATE is valid, if not required. TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would break things. PARTICIPATE is definitely valid, but I disagree it is always required. Its definitely useful though. It is only always required if both of TRANSPARENT and BLOCK do not work. Yup, TRANSPARENT turns the rbridge network into a hub therefore it is also valid with different trade-offs. Therefore PARTICIPATE is not always required it is simply valid. BLOCK will break things? How. I think I've convinced myself this is not possible in the steady state (because you have nodally disjoint trees joined by a single link therefore a loop is not possible). The worst it can do is change the routes because you get two STP trees each with different root bridges ... which is not always ideal and why I think you need TRANSPARENT AND BLOCK options at different phases of a migration ... and possibly even Ships in the Night mode too. Peter Ashwood-Smith Received: from [70.192.68.73] (73.sub-70-192-68.myvzw.com [70.192.68.73]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EHtwL20033; Fri, 14 Oct 2005 10:55:58 -0700 (PDT) Message-ID: <434FF126.2040208@isi.edu> Date: Fri, 14 Oct 2005 10:55:50 -0700 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> References: <BC468F3648F16146B9FA9123627514F8DCD9E4@xmb-sjc-217.amer.cisco.com> In-Reply-To: <BC468F3648F16146B9FA9123627514F8DCD9E4@xmb-sjc-217.amer.cisco.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B371A5000287BD0D6E2DB47" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 17:56:14 -0000 Status: RO Content-Length: 1158 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B371A5000287BD0D6E2DB47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael Smith (michsmit) wrote: > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >> >>My understanding is that PARTICIPATE is valid, if not required. >>TRANSPARENT seems like it turns the bridge into a hub. And >>BLOCK would break things. > > > I think I missed something, what breaks if we block BPDUs ? If nothing, then lets. For bridges too. Now what happens? (i.e., if bridges block BPDUs) - won't that kill the spanning tree? Joe --------------enig6B371A5000287BD0D6E2DB47 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDT/EmE5f5cImnZrsRAqujAJ9Dd1FmTntWgY6J/DRHHEsjH0einACgyeMQ N/qTJ4jPour4dBBO7YRTXis= =G9zE -----END PGP SIGNATURE----- --------------enig6B371A5000287BD0D6E2DB47-- Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EHcnL15130 for <rbridge@postel.org>; Fri, 14 Oct 2005 10:38:49 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 10:38:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9EHcN9M028355 for <rbridge@postel.org>; Fri, 14 Oct 2005 10:38:42 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:38:42 -0700 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, 14 Oct 2005 10:38:40 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8DCD9E4@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstractfor problemand applicabilitystatement Thread-Index: AcXQ5WiVrmmfJBeGQhy9p2yBw0GuHQAADwcg From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 14 Oct 2005 17:38:42.0478 (UTC) FILETIME=[1E9FECE0:01C5D0E6] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9EHcnL15130 Subject: Re: [rbridge] seeking input on abstractfor problemand applicabilitystatement 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, 14 Oct 2005 17:39:09 -0000 Status: RO Content-Length: 287 > -----Original Message----- > From: rbridge-bounces@postel.org > > My understanding is that PARTICIPATE is valid, if not required. > TRANSPARENT seems like it turns the bridge into a hub. And > BLOCK would break things. I think I missed something, what breaks if we block BPDUs ? Received: from [70.192.68.73] (73.sub-70-192-68.myvzw.com [70.192.68.73]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EHRjL11896; Fri, 14 Oct 2005 10:27:45 -0700 (PDT) Message-ID: <434FEA89.3020409@isi.edu> Date: Fri, 14 Oct 2005 10:27:37 -0700 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> References: <39C363776A4E8C4A94691D2BD9D1C9A181891D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A181891D@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36DE0EB60B511D8EAE289B50" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Rbridges for MANETs? 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, 14 Oct 2005 17:28:10 -0000 Status: RO Content-Length: 2270 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36DE0EB60B511D8EAE289B50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Templin, Fred L wrote: > I am wondering if anyone has considered Mobile Ad-hoc Networks > (MANETs) as an instance of a "campus" that Rbridges might find > themselves in? For this WG, my understanding is no. In particular, we assume that existing routing is used inside the campus (perhaps modified to transit rbridge info, but otherwise as-is), and that rbridge dynamics are similar to existing bridge dynamics. > Due to node mobility, Rbridges would have to deal > with frequent link state changes in such an environment which > would give a constantly changing topology along with potentially > multiplicative increase in routing protocol overhead. Do we see > Rbridges as potentially extending to cover the MANET space? That sounds like a job for a new routing protocol that an rbridge might use, but not specific to rbridges. > I ask this partly because there will be a BOF on Ad-Hoc Network > Autonconfiguration (AUTOCONF) at the upcoming IETF and I wonder > about the overlap between what is being considered there and > TRILL. A quick overview makes it seem that the AUTOCONF approach > has more of a layer 3 flavor while TRILL is more focused on the > layer 2 proxy approach. Has anyone considered whether the two > approaches are essentially addressing the same problem space? Bridges live in a world of known (or at least assumed) unique, predeployed global endpoint identifiers, and provide broadcast as well as multicast. These are some of the more significant challenges that AUTOCONF needs to address (sans broadcast), so I don't see them as related. Joe --------------enig36DE0EB60B511D8EAE289B50 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDT+qJE5f5cImnZrsRAgBrAJ94pN3dMxnjDJlWt06BnERXvbVmRACg5kDo yv495NT9+k/INgtXO4gO1kM= =yPUH -----END PGP SIGNATURE----- --------------enig36DE0EB60B511D8EAE289B50-- Received: from [70.192.68.73] (73.sub-70-192-68.myvzw.com [70.192.68.73]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9EHLKL09880; Fri, 14 Oct 2005 10:21:20 -0700 (PDT) Message-ID: <434FE900.8050003@isi.edu> Date: Fri, 14 Oct 2005 10:21:04 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CEA@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213CEA@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3D8BB5C8BF34C434B950190" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problemand applicabilitystatement 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, 14 Oct 2005 17:22:45 -0000 Status: RO Content-Length: 3633 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC3D8BB5C8BF34C434B950190 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: >>But isn't this just what STP does? >>I.e., a bridge: >> >> accepts BPDUs as input >> determines an internal spanning tree based on port selection >> emits appropriate BPDUs on those ports >> >>Why isn't this exactly what an rbridge needs to do? I.e., neither a > > bridge > >>nor an rbridge 'transparently' forward BPDUs, but both are nodes in the >>resulting spanning tree. > > > Hmmm so you have added yet a third possibility. At this point I think > giving them names is probably helpful. Here is what I'd suggest. > > [BLOCK] Rbridge block BPDU's > [TRANSPARENT] Rbridge transparently passes BPDU's > [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's) > > >>This still provides a benefit for an rbridge - that it is just ONE > > node in > the spanning tree, not O(#rbridges) or even O(#egress > rbridges). > > Yeah, but its messy to implement this kind of thing. We refer to that as > an abstract node in routing. Making a network appear as a single node to > its neighbors. It requires more 'internal' messaging between the > different 'parts' of the abstract node to create this illusion. For > example the BPDUs must be gathered and sorted etc. so you'd have to > elect one of the 'parts' of that node to act on behalf of the others, do > the gather/sort and regeneration. A 'designated virtual bridge' so to > speak. All of this sounds like stuff the rbridge already needs to do; there needs to be an internal spanning tree anyway. > I'd suggest that the I.D mention the three (giving them concrete names > to avoid further confusion). Personally, and I think from the emails it > sounds like we'd recommend BLOCK, allow TRANSPARENT and leave > PARTICIPATE for further study? (I can hear the graduate students > sharpening their pencils already). I'd like someone to explain which of these are valid if we replace the rbridge campus with an existing bridge. My understanding is that PARTICIPATE is valid, if not required. TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would break things. > Oh, speaking of TRANSPARENT, it may be a very useful mode during a > migration since it allows the installation of rbridges without affecting > the bulk of the paths. BLOCK would result in a sudden change in root > bridge on one side of the Rbridged network with resulting sudden shift > in traffic patterns. For some carefully crafted networks that sudden > change may be a bit of a shock and an impediment to migration so while > undesirable in the final state, it may be useful during transition ... > unless we mandate ships in the night with a quick switchover when all > bridges were replaced with rbridges ... but I've not seen this done very > often successfully. > > Peter Ashwood-Smith > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge --------------enigC3D8BB5C8BF34C434B950190 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDT+kIE5f5cImnZrsRAsnIAKC4La4vBEdwFU9dRVHpSnhEO5l61wCg5O9p onRslOqPbENzsVHblajm0ik= =gkx6 -----END PGP SIGNATURE----- --------------enigC3D8BB5C8BF34C434B950190-- Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9E4a5L19034 for <rbridge@postel.org>; Thu, 13 Oct 2005 21:36:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9E4ZwC04125 for <rbridge@postel.org>; Fri, 14 Oct 2005 00:35:58 -0400 (EDT) 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, 14 Oct 2005 00:35:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CEA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstract for problemand applicabilitystatement Thread-Index: AcXQcAcKFEXbTZncRimjlFj0AGgGsQAAUHaQ From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9E4a5L19034 Subject: Re: [rbridge] seeking input on abstract for problemand applicabilitystatement 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, 14 Oct 2005 04:37:01 -0000 Status: RO Content-Length: 2291 > But isn't this just what STP does? > I.e., a bridge: > > accepts BPDUs as input > determines an internal spanning tree based on port selection > emits appropriate BPDUs on those ports > >Why isn't this exactly what an rbridge needs to do? I.e., neither a bridge >nor an rbridge 'transparently' forward BPDUs, but both are nodes in the >resulting spanning tree. Hmmm so you have added yet a third possibility. At this point I think giving them names is probably helpful. Here is what I'd suggest. [BLOCK] Rbridge block BPDU's [TRANSPARENT] Rbridge transparently passes BPDU's [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's) > This still provides a benefit for an rbridge - that it is just ONE node in > the spanning tree, not O(#rbridges) or even O(#egress rbridges). Yeah, but its messy to implement this kind of thing. We refer to that as an abstract node in routing. Making a network appear as a single node to its neighbors. It requires more 'internal' messaging between the different 'parts' of the abstract node to create this illusion. For example the BPDUs must be gathered and sorted etc. so you'd have to elect one of the 'parts' of that node to act on behalf of the others, do the gather/sort and regeneration. A 'designated virtual bridge' so to speak. I'd suggest that the I.D mention the three (giving them concrete names to avoid further confusion). Personally, and I think from the emails it sounds like we'd recommend BLOCK, allow TRANSPARENT and leave PARTICIPATE for further study? (I can hear the graduate students sharpening their pencils already). Oh, speaking of TRANSPARENT, it may be a very useful mode during a migration since it allows the installation of rbridges without affecting the bulk of the paths. BLOCK would result in a sudden change in root bridge on one side of the Rbridged network with resulting sudden shift in traffic patterns. For some carefully crafted networks that sudden change may be a bit of a shock and an impediment to migration so while undesirable in the final state, it may be useful during transition ... unless we mandate ships in the night with a quick switchover when all bridges were replaced with rbridges ... but I've not seen this done very often successfully. Peter Ashwood-Smith Received: from [70.193.102.9] (9.sub-70-193-102.myvzw.com [70.193.102.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9E3SGL03696; Thu, 13 Oct 2005 20:28:17 -0700 (PDT) Message-ID: <434F25C9.3090608@isi.edu> Date: Thu, 13 Oct 2005 20:28:09 -0700 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> References: <713043CE8B8E1348AF3C546DBE02C1B405213CCD@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405213CCD@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA4F64E4D6D246C3DFC98EB6D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicabilitystatement 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, 14 Oct 2005 03:28:59 -0000 Status: RO Content-Length: 2348 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA4F64E4D6D246C3DFC98EB6D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: > >>I still think the rbridge MUST participate in order to avoid loops, >>but if that's contentious it can't be part of the abstract yet...) > > > > Let me see if I can help. Radia gave a good description of why the > Rbridge does not need to participate in STP/FSTP but here is another way > to think of it and perhaps it will strike different chords: > > Take two node disjoint trees A and B. > > Now, connect the trees A and B with only ONE link. The result is still a > tree. > > This is "sort of" what the combination of STP and Rbridge protocols are > doing. > > STP computes one tree. Rbridge computes the other and finally Rbridge > connects the two with only ONE link using the designated Rbridge > concept. > > Since we can apply this same mechanism over and over again, i.e. > induction we are guaranteed the end result is indeed one big tree and > therefore is loop free, ... at least in the steady state. But isn't this just what STP does? I.e., a bridge: accepts BPDUs as input determines an internal spanning tree based on port selection emits appropriate BPDUs on those ports Why isn't this exactly what an rbridge needs to do? I.e., neither a bridge nor an rbridge 'transparently' forward BPDUs, but both are nodes in the resulting spanning tree. This still provides a benefit for an rbridge - that it is just ONE node in the spanning tree, not O(#rbridges) or even O(#egress rbridges). I.e., it still helps the remaining spanning tree converge faster and react better. AND rbridges 'inside' the campus (acting as transits) can move around without affecting the spanning tree at all. Joe --------------enigA4F64E4D6D246C3DFC98EB6D 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDTyXJE5f5cImnZrsRAoucAKDlwTXmtwp2Cf59IhOQOzvkRY2TWwCeI1pr fhcNV6bnONjC65sA/tCgoHk= =7Xx0 -----END PGP SIGNATURE----- --------------enigA4F64E4D6D246C3DFC98EB6D-- 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 j9E0ofL27527 for <rbridge@postel.org>; Thu, 13 Oct 2005 17:50:43 -0700 (PDT) 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 j9E0oZrP011310 for <rbridge@postel.org>; Thu, 13 Oct 2005 20:50:35 -0400 (EDT) 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 UAA26053 for <rbridge@postel.org>; Thu, 13 Oct 2005 20:50:35 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPG1FA>; Thu, 13 Oct 2005 21:50:35 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F82@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Thu, 13 Oct 2005 21:50:34 -0300 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] loops in trill networks 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, 14 Oct 2005 00:51:39 -0000 Status: RO Content-Length: 3003 Dino, This potential "scaling problem" comes from mixing goals. It should not - simultaneously - be a goal to both extend STP across an L2 network and target a larger L2 network. If we are planning to keep the spanning trees simple and small, then we might be able to achieve better performance with larger scale layer two networks. In any case, I believe it has already been said that it is not necessarily a goal of RBridges to make LANs larger. If LANs get larger because of RBridges, it will be because they allow them to - not because they force them to. I've yet to see what the reasoning is for wanting to have STP take place over the entire extended L2 network (overlay). I've seen people argue that we could do so - but not why we would do so. I've also seen people argue that we should do so, but the argument seems to be based on a somewhat "purest" point of view based on the belief that L2 networks do this. The entire discussions seems to have been initiated as a result of confusing use of the term "spanning tree". The fact that a spanning tree may be determined in one way or another does not mean, or even imply, that STP is always used. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Thursday, October 13, 2005 8:17 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> I think this is suboptimal, since the larger the --> spanning tree, the --> >> slower convergence would be. --> --> So that's a good point we should also decide on. If the --> introduction of --> RBridges causes traditional bridged networks to get --> larger, we could --> introduce a scaling problem by making STP work harder --> than it was --> originally designed for. --> --> Now, yes, anyone could tunnel over any infrastructure --> and create an --> overlay topology (i.e. VPLS and L2 metro networks) but --> do we want to make --> it more inherent in the architecture. --> --> >> So I think it's a lot better to have RBridges not --> forward spanning tree --> >> messages, and keep the --> >> bridge spanning trees really separate. --> --> I think I can go along with this too but we need to --> state that an RBridge --> network is not a traditional L2-based subnet. I think --> there are other --> reasons to claim this already (i.e. low incident --> forwarding loops and --> duplicate packets) so we wouldn't be setting a --> precedent for this case. --> --> >> We could think of it as RBridges "participating" in --> 802.1d spanning tree --> >> by simply consuming --> >> the messages (and not doing anything other than dropping them). --> --> Sure, makes sense. --> --> Dino --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9E0GtL19182 for <rbridge@postel.org>; Thu, 13 Oct 2005 17:16:55 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Oct 2005 17:16:51 -0700 Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9E0GmUw019160 for <rbridge@postel.org>; Thu, 13 Oct 2005 17:16:49 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9E0Gm09028936 for <rbridge@postel.org>; Thu, 13 Oct 2005 17:16:48 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9E0GmB7028932; Thu, 13 Oct 2005 17:16:48 -0700 Date: Thu, 13 Oct 2005 17:16:48 -0700 Message-Id: <200510140016.j9E0GmB7028932@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <434EBE39.5030402@sun.com> (message from Radia Perlman on Thu, 13 Oct 2005 13:06:17 -0700) References: <BC468F3648F16146B9FA9123627514F8D67641@xmb-sjc-217.amer.cisco.com> <434EBE39.5030402@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 14 Oct 2005 00:17:58 -0000 Status: RO Content-Length: 1194 >> I think this is suboptimal, since the larger the spanning tree, the >> slower convergence would be. So that's a good point we should also decide on. If the introduction of RBridges causes traditional bridged networks to get larger, we could introduce a scaling problem by making STP work harder than it was originally designed for. Now, yes, anyone could tunnel over any infrastructure and create an overlay topology (i.e. VPLS and L2 metro networks) but do we want to make it more inherent in the architecture. >> So I think it's a lot better to have RBridges not forward spanning tree >> messages, and keep the >> bridge spanning trees really separate. I think I can go along with this too but we need to state that an RBridge network is not a traditional L2-based subnet. I think there are other reasons to claim this already (i.e. low incident forwarding loops and duplicate packets) so we wouldn't be setting a precedent for this case. >> We could think of it as RBridges "participating" in 802.1d spanning tree >> by simply consuming >> the messages (and not doing anything other than dropping them). Sure, makes sense. Dino Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DNCnL27614 for <rbridge@postel.org>; Thu, 13 Oct 2005 16:12:49 -0700 (PDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA17072 for <rbridge@postel.org>; Thu, 13 Oct 2005 16:12:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9DNChm14964 for <rbridge@postel.org>; Thu, 13 Oct 2005 18:12:43 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 16:12:43 -0700 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, 13 Oct 2005 16:12:42 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A181891D@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rbridges for MANETs? Thread-Index: AcXQO+ssm/GVaBgsQiu/rMlVXuo+qwADQx2g From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 13 Oct 2005 23:12:43.0246 (UTC) FILETIME=[9D70B0E0:01C5D04B] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: fred.l.templin@boeing.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9DNCnL27614 Subject: [rbridge] Rbridges for MANETs? 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, 13 Oct 2005 23:13:00 -0000 Status: RO Content-Length: 921 I am wondering if anyone has considered Mobile Ad-hoc Networks (MANETs) as an instance of a "campus" that Rbridges might find themselves in? Due to node mobility, Rbridges would have to deal with frequent link state changes in such an environment which would give a constantly changing topology along with potentially multiplicative increase in routing protocol overhead. Do we see Rbridges as potentially extending to cover the MANET space? I ask this partly because there will be a BOF on Ad-Hoc Network Autonconfiguration (AUTOCONF) at the upcoming IETF and I wonder about the overlap between what is being considered there and TRILL. A quick overview makes it seem that the AUTOCONF approach has more of a layer 3 flavor while TRILL is more focused on the layer 2 proxy approach. Has anyone considered whether the two approaches are essentially addressing the same problem space? Fred fred.l.templin@boeing.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DLF3L24222 for <rbridge@postel.org>; Thu, 13 Oct 2005 14:15:03 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9DLF21L004861 for <rbridge@postel.org>; Thu, 13 Oct 2005 15:15:03 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j9DLF2sn003506; Thu, 13 Oct 2005 17:15:02 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j9DLF1hu008586; Thu, 13 Oct 2005 17:15:01 -0400 (EDT) From: Bill Sommerfeld <sommerfeld@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <434DC367.6@sun.com> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> <434DC367.6@sun.com> Content-Type: text/plain Message-Id: <1129238100.7341.154.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Thu, 13 Oct 2005 17:15:01 -0400 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sommerfeld@sun.com Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 13 Oct 2005 21:17:04 -0000 Status: RO Content-Length: 1281 On Wed, 2005-10-12 at 22:16, Erik Nordmark wrote: > I assume you might want to be able to have a single MAC address and > receive packets over multiple ports - with the rbridges using the > shortest path. Is this correct? Exactly. You'll get better performance when all paths are working, and simple failover when they aren't. > That is more of a functional problem than a security problem I think. so, a simple way to do this functionally is for the host to just become an rbridge. but then historically many sites are organized such that the people who administer the network don't trust the people who run the hosts and vice versa..... > Since end stations might move around, one would assume that when a MAC > address appears on a different port, perhaps on a different rbridge as > well, that the host has moved. Thus it would make sense to add the route > which points to the new place, and remove the route that points to the > old place. > > But in your case you would need that both routes remain in place > somehow. Perhaps we can do that by being smarter about when we remove a > route for a MAC address? yup. routing protocols already provide a way to solve that problem, but then you get into the organizational issue alluded to above. - Bill Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DKHRL04766 for <rbridge@postel.org>; Thu, 13 Oct 2005 13:17:27 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9DKHGj01318 for <rbridge@postel.org>; Thu, 13 Oct 2005 16:17:16 -0400 (EDT) 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, 13 Oct 2005 16:17:01 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CE6@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXQMnvzBMcF84haTB+ZEefMOhYXYQAAHblw From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9DKHRL04766 Subject: Re: [rbridge] loops in trill networks 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, 13 Oct 2005 20:17:53 -0000 Status: RO Content-Length: 4528 Agreed, this is why I said it is a SHOULD v.s. a MUST. Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Thursday, October 13, 2005 4:06 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks I'm travelling and not necessarily following this whole thread. However...I think it actually would work to have RBridges forwarding spanning tree messages. It would result in lots of little trees, partitioned because data traffic must not be forwarded mindlessly along that super-tree, but all the little trees would think the same ID was Root bridge. I think this is suboptimal, since the larger the spanning tree, the slower convergence would be. So I think it's a lot better to have RBridges not forward spanning tree messages, and keep the bridge spanning trees really separate. We could think of it as RBridges "participating" in 802.1d spanning tree by simply consuming the messages (and not doing anything other than dropping them). Radia Michael Smith (michsmit) wrote: > > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >> >>Dino, >> >> The argument that an RBridge network provides a layer 2 >>service therefore any frames that are presented should be >>forwarded is a non sequitur. >> >> This is not even true of bridges now. Conditions under >>which a bridge "should" forward frames are somewhat >>restricted, even if those conditions are typically satisfied >>under steady-state conditions, for most frames. There are >>plenty of examples of situations in which a bridge must not >>forward frames and other in which a bridge should not forward frames. >> >> > >For the most part, bridges only terminate their own control protocols, >link layer protocols, and local management traffic. Since the rbridge >doesn't participate in STP, I see a valid argument that this protocol >should be passed. This is basically what an 802.1ad bridge does, it >doesn't participate in the customer STP and simply passes the customer >BPDUs through and everything works fine. On the other hand, since the >goal is to provide an alternative to spanning tree, this would imply >that the entire network will run both rbridging control plane and STP >until it is fully upgraded to rbridges. If STP is terminated at the >rbridge, there would be incremental benefit of upgrading the network >with rbridges by localizing STP as rbridges are incrementally deployed. >Personally, I feel passing or terminating STP can be equally justified >(and if this is used in the Metro space, we could end up doing both). > >Michael > > > >>-- >>Eric >> >>--> -----Original Message----- >>--> From: rbridge-bounces@postel.org >>--> [mailto:rbridge-bounces@postel.org]On >>--> Behalf Of Dino Farinacci >>--> Sent: Wednesday, October 12, 2005 5:46 PM >>--> To: rbridge@postel.org >>--> Cc: rbridge@postel.org >>--> Subject: Re: [rbridge] loops in trill networks >>--> >>--> >>--> >> No, actually, it is not like saying that. >>--> >>--> I think the fundamental question that needs to be answered is >>--> does an >>--> RBridge network proivde a layer-2 serivce. And I think the >>--> answer should >>--> be yes. Therefore any frames that are sent on such a network >>--> should be >>--> forwarded. >>--> >>--> Two bridges connected via a cable or an RBridge-based network >>--> should >>--> look no different. The two bridges should be able to run STP >>--> over it and >>--> decide if the ports leading to such a network are in >>Blocked or >>--> Forward >>--> state. >>--> >>--> The RBridges should forward such packets like any >>other frames. >>--> The only >>--> frames that RBridges will consume and process are >>IS-IS packets >>--> (which >>--> will be multicasted on a *new MAC group address*). >>--> >>--> Dino >>--> _______________________________________________ >>--> 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 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 j9DK6ML01631 for <rbridge@postel.org>; Thu, 13 Oct 2005 13:06:22 -0700 (PDT) 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 <0IOB00J0ZEIEPO00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 13 Oct 2005 13:06:14 -0700 (PDT) Received: from sun.com ([129.150.28.98]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IOB00JEPEID1500@mail.sunlabs.com> for rbridge@postel.org; Thu, 13 Oct 2005 13:06:14 -0700 (PDT) Date: Thu, 13 Oct 2005 13:06:17 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <BC468F3648F16146B9FA9123627514F8D67641@xmb-sjc-217.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434EBE39.5030402@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: <BC468F3648F16146B9FA9123627514F8D67641@xmb-sjc-217.amer.cisco.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] loops in trill networks 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, 13 Oct 2005 20:06:55 -0000 Status: RO Content-Length: 4081 I'm travelling and not necessarily following this whole thread. However...I think it actually would work to have RBridges forwarding spanning tree messages. It would result in lots of little trees, partitioned because data traffic must not be forwarded mindlessly along that super-tree, but all the little trees would think the same ID was Root bridge. I think this is suboptimal, since the larger the spanning tree, the slower convergence would be. So I think it's a lot better to have RBridges not forward spanning tree messages, and keep the bridge spanning trees really separate. We could think of it as RBridges "participating" in 802.1d spanning tree by simply consuming the messages (and not doing anything other than dropping them). Radia Michael Smith (michsmit) wrote: > > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >> >>Dino, >> >> The argument that an RBridge network provides a layer 2 >>service therefore any frames that are presented should be >>forwarded is a non sequitur. >> >> This is not even true of bridges now. Conditions under >>which a bridge "should" forward frames are somewhat >>restricted, even if those conditions are typically satisfied >>under steady-state conditions, for most frames. There are >>plenty of examples of situations in which a bridge must not >>forward frames and other in which a bridge should not forward frames. >> >> > >For the most part, bridges only terminate their own control protocols, >link layer protocols, and local management traffic. Since the rbridge >doesn't participate in STP, I see a valid argument that this protocol >should be passed. This is basically what an 802.1ad bridge does, it >doesn't participate in the customer STP and simply passes the customer >BPDUs through and everything works fine. On the other hand, since the >goal is to provide an alternative to spanning tree, this would imply >that the entire network will run both rbridging control plane and STP >until it is fully upgraded to rbridges. If STP is terminated at the >rbridge, there would be incremental benefit of upgrading the network >with rbridges by localizing STP as rbridges are incrementally deployed. >Personally, I feel passing or terminating STP can be equally justified >(and if this is used in the Metro space, we could end up doing both). > >Michael > > > >>-- >>Eric >> >>--> -----Original Message----- >>--> From: rbridge-bounces@postel.org >>--> [mailto:rbridge-bounces@postel.org]On >>--> Behalf Of Dino Farinacci >>--> Sent: Wednesday, October 12, 2005 5:46 PM >>--> To: rbridge@postel.org >>--> Cc: rbridge@postel.org >>--> Subject: Re: [rbridge] loops in trill networks >>--> >>--> >>--> >> No, actually, it is not like saying that. >>--> >>--> I think the fundamental question that needs to be answered is >>--> does an >>--> RBridge network proivde a layer-2 serivce. And I think the >>--> answer should >>--> be yes. Therefore any frames that are sent on such a network >>--> should be >>--> forwarded. >>--> >>--> Two bridges connected via a cable or an RBridge-based network >>--> should >>--> look no different. The two bridges should be able to run STP >>--> over it and >>--> decide if the ports leading to such a network are in >>Blocked or >>--> Forward >>--> state. >>--> >>--> The RBridges should forward such packets like any >>other frames. >>--> The only >>--> frames that RBridges will consume and process are >>IS-IS packets >>--> (which >>--> will be multicasted on a *new MAC group address*). >>--> >>--> Dino >>--> _______________________________________________ >>--> 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 sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DHuuL23198 for <rbridge@postel.org>; Thu, 13 Oct 2005 10:56:56 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2005 10:56:51 -0700 X-IronPort-AV: i="3.97,211,1125903600"; d="scan'208"; a="665915625:sNHT27544694" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9DHunUw011644 for <rbridge@postel.org>; Thu, 13 Oct 2005 10:56:50 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9DHun4B018638 for <rbridge@postel.org>; Thu, 13 Oct 2005 10:56:49 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9DHune8018634; Thu, 13 Oct 2005 10:56:49 -0700 Date: Thu, 13 Oct 2005 10:56:49 -0700 Message-Id: <200510131756.j9DHune8018634@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <313680C9A886D511A06000204840E1CF0C885F78@whq-msgusr-02.pit.comms.marconi.com> (Eric.Gray@marconi.com) References: <313680C9A886D511A06000204840E1CF0C885F78@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 13 Oct 2005 17:57:53 -0000 Status: RO Content-Length: 787 >> This is not even true of bridges now. Conditions under which a >> bridge "should" forward frames are somewhat restricted, even if those >> conditions are typically satisfied under steady-state conditions, for >> most frames. There are plenty of examples of situations in which a >> bridge must not forward frames and other in which a bridge should not >> forward frames. I disagree. There are very few cases (I can think of only one standard case and one proprietary case) where architecturally a 802.1D bridge states "a bridge should not forward packet with ethertype foo or DA bar". Now this is all modulo what vendors do for policy based forwarding/ filtering. But that is an implementation extension and not an architectural specification. Dino Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DGZuL27196 for <rbridge@postel.org>; Thu, 13 Oct 2005 09:35:56 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 13 Oct 2005 09:35:50 -0700 X-IronPort-AV: i="3.97,211,1125903600"; d="scan'208"; a="351714676:sNHT744763258" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9DGZD9a029999 for <rbridge@postel.org>; Thu, 13 Oct 2005 09:35:48 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 09:35:45 -0700 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, 13 Oct 2005 09:35:45 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8D67641@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXP9BUajnPwfLYWSCWYyJU0F+27hgAHdePw From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 13 Oct 2005 16:35:45.0708 (UTC) FILETIME=[2914CEC0:01C5D014] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9DGZuL27196 Subject: Re: [rbridge] loops in trill networks 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, 13 Oct 2005 16:36:53 -0000 Status: RO Content-Length: 3094 > -----Original Message----- > From: rbridge-bounces@postel.org > > Dino, > > The argument that an RBridge network provides a layer 2 > service therefore any frames that are presented should be > forwarded is a non sequitur. > > This is not even true of bridges now. Conditions under > which a bridge "should" forward frames are somewhat > restricted, even if those conditions are typically satisfied > under steady-state conditions, for most frames. There are > plenty of examples of situations in which a bridge must not > forward frames and other in which a bridge should not forward frames. For the most part, bridges only terminate their own control protocols, link layer protocols, and local management traffic. Since the rbridge doesn't participate in STP, I see a valid argument that this protocol should be passed. This is basically what an 802.1ad bridge does, it doesn't participate in the customer STP and simply passes the customer BPDUs through and everything works fine. On the other hand, since the goal is to provide an alternative to spanning tree, this would imply that the entire network will run both rbridging control plane and STP until it is fully upgraded to rbridges. If STP is terminated at the rbridge, there would be incremental benefit of upgrading the network with rbridges by localizing STP as rbridges are incrementally deployed. Personally, I feel passing or terminating STP can be equally justified (and if this is used in the Metro space, we could end up doing both). Michael > > -- > Eric > > --> -----Original Message----- > --> From: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org]On > --> Behalf Of Dino Farinacci > --> Sent: Wednesday, October 12, 2005 5:46 PM > --> To: rbridge@postel.org > --> Cc: rbridge@postel.org > --> Subject: Re: [rbridge] loops in trill networks > --> > --> > --> >> No, actually, it is not like saying that. > --> > --> I think the fundamental question that needs to be answered is > --> does an > --> RBridge network proivde a layer-2 serivce. And I think the > --> answer should > --> be yes. Therefore any frames that are sent on such a network > --> should be > --> forwarded. > --> > --> Two bridges connected via a cable or an RBridge-based network > --> should > --> look no different. The two bridges should be able to run STP > --> over it and > --> decide if the ports leading to such a network are in > Blocked or > --> Forward > --> state. > --> > --> The RBridges should forward such packets like any > other frames. > --> The only > --> frames that RBridges will consume and process are > IS-IS packets > --> (which > --> will be multicasted on a *new MAC group address*). > --> > --> Dino > --> _______________________________________________ > --> 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 j9DCZCL18411 for <rbridge@postel.org>; Thu, 13 Oct 2005 05:35:12 -0700 (PDT) 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 j9DCZ6rP025888 for <rbridge@postel.org>; Thu, 13 Oct 2005 08:35:07 -0400 (EDT) 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 IAA04419 for <rbridge@postel.org>; Thu, 13 Oct 2005 08:35:06 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPFM2S>; Thu, 13 Oct 2005 09:35:06 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F78@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Thu, 13 Oct 2005 09:35:05 -0300 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] loops in trill networks 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, 13 Oct 2005 12:35:52 -0000 Status: RO Content-Length: 1831 Dino, The argument that an RBridge network provides a layer 2 service therefore any frames that are presented should be forwarded is a non sequitur. This is not even true of bridges now. Conditions under which a bridge "should" forward frames are somewhat restricted, even if those conditions are typically satisfied under steady-state conditions, for most frames. There are plenty of examples of situations in which a bridge must not forward frames and other in which a bridge should not forward frames. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Wednesday, October 12, 2005 5:46 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> No, actually, it is not like saying that. --> --> I think the fundamental question that needs to be --> answered is does an --> RBridge network proivde a layer-2 serivce. And I think --> the answer should --> be yes. Therefore any frames that are sent on such a --> network should be --> forwarded. --> --> Two bridges connected via a cable or an RBridge-based --> network should --> look no different. The two bridges should be able to --> run STP over it and --> decide if the ports leading to such a network are in --> Blocked or Forward --> state. --> --> The RBridges should forward such packets like any other --> frames. The only --> frames that RBridges will consume and process are IS-IS --> packets (which --> will be multicasted on a *new MAC group address*). --> --> Dino --> _______________________________________________ --> 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 j9DCTNL16970 for <rbridge@postel.org>; Thu, 13 Oct 2005 05:29:23 -0700 (PDT) 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 j9DCTIrP025733 for <rbridge@postel.org>; Thu, 13 Oct 2005 08:29:18 -0400 (EDT) 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 IAA03839 for <rbridge@postel.org>; Thu, 13 Oct 2005 08:29:17 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPFMDG>; Thu, 13 Oct 2005 09:29:17 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F77@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Thu, 13 Oct 2005 09:29:16 -0300 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] loops in trill networks 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, 13 Oct 2005 12:30:21 -0000 Status: RO Content-Length: 5039 Erik, I agree that sending a topology change BPDU might be a better approach. There are two things for us to look at if that's what we're thinking of doing: what are the results of having a device that is enough of a regular bridge to be able to send topology change BPDUs but not enough of one to be able to otherwise participate in bridging - and - what are the consequences to forwarding when we put all of the bridges in non-forwarding mode while they re-run STP and then in flooding mode while they re-learn their filtering DB? I think the latter is not so much of an issue, if we subscribe to the philosophy stated earlier that having the ability to create a larger L2 domain is an objective. In that case, the "trauma" thus induced would be no worse than if the RBridge that went down was a regular bridge. The former issue is something we can maybe finesse, if we allow RBridges to originate BPDUs but not (in the normal case) forward them. In this case, other bridges will normally construe that an RBridge - rather than being a host - is a bridge with no transit connectivity. In that case, the normal mode would be that local bridges would only forward frames to an RBridge that are MAC-addressed to it. For the case where RBridges might forward BPDUs, it must be the case that they are configured with information that will allow them to determine which BPDUs to forward an which not to forward. Otherwise - for forwarding - it will not be possible to take advantage of many redundant paths as the bridges will see the RBridges as part of a single spanning tree and will forward and accept frames only on that single spanning tree. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Erik Nordmark --> Sent: Wednesday, October 12, 2005 10:35 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> Gray, Eric wrote: --> --> > Instead, the normal case should be for RBridges --> > to terminate the local broadcast domain and the local --> > STP-based spanning tree. To do this, RBridges should --> > act as if they were hosts to STP and ignore it. --> --> Eric, --> I'm not sure we have a useful definition for "local --> broadcast domain" - --> we have a broadcast domain which spans the whole rbridged --> network so --> that IP broadcast continues to work as before. --> --> I think that having rbridges act as if they are hosts is a --> good starting --> point to think about the problem. But the desire to attach --> the local --> (bridged) segment to multiple rbridges for redundancy makes --> things a bit --> more complex. Take this picture: --> --> H4 --> | --> ( Rest of rbridged network ) --> | | --> RB1 RB2 --> | | --> ( bridged cloud at edge ) --> | | | --> H1 H2 H3 --> --> Suppose RB1 has been elected as the forwarder to/from the --> bridged cloud. --> This means that the bridges have learned (from received --> packets) that --> packets to MAC addresses in the rest of the network (e.g., --> H4) should be --> sent towards RB1. --> --> What happens when RB1 fails? RB2 would take over, and the routing --> protocol would quickly cause the other rbridges to find out. --> But packets from H1 to H4 will continue to be forwarded by --> the bridges --> towards RB1 until those learning tables time out, or until --> a packet from --> H4 arrives via RB2. --> --> If we want to ensure that the bridges more quickly find out --> that they --> should use RB2, it would seem like we need to add something in the --> interaction at the edge. Effectively we want RB2 to be able --> to tell the --> bridges in the cloud either --> - that they should discard their learning tables, or --> - that they should switch to use RB2. --> --> I haven't looked at the options in detail, but perhaps we --> can do the --> first by RB2 injecting a toplogy change BPDU? --> For the second approach, one could envision the RBs at the edge --> presenting themselves as a bridge with a low cost to an --> imaginary root --> bridge (which represents the rbridge core)? Of course, we --> can't ensure --> that the imaginary becomes the root bridge; the best we can --> do is to --> have it have a high probability of becoming the root bridge --> from the --> perspective of the bridged cloud at this part of the edge. --> I don't think this requires that BPDUs be carried across --> the rbridged --> cloud - each bridged cloud at the edges can be treated as separate. --> --> I don't know how fancy we need to be here, but waiting for --> the learning --> tables to time out when there is an RB failures seems a bid bad. --> --> Erik --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9D2gHL27189 for <rbridge@postel.org>; Wed, 12 Oct 2005 19:42:17 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9D2gG1L007179 for <rbridge@postel.org>; Wed, 12 Oct 2005 20:42:16 -0600 (MDT) Received: from [129.158.215.244] (dhcp-cbjs05-215-09.PRC.Sun.COM [129.158.215.244]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9D2gD4J253760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Oct 2005 19:42:15 -0700 (PDT) Message-ID: <434DC9A1.3010902@sun.com> Date: Wed, 12 Oct 2005 19:42:41 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <313680C9A886D511A06000204840E1CF0C885F72@whq-msgusr-02.pit.comms.marconi.com> <200510122146.j9CLk2BJ020071@dino-lnx.cisco.com> In-Reply-To: <200510122146.j9CLk2BJ020071@dino-lnx.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] loops in trill networks 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, 13 Oct 2005 02:42:50 -0000 Status: RO Content-Length: 1805 Dino Farinacci wrote: > I think the fundamental question that needs to be answered is does an > RBridge network proivde a layer-2 serivce. And I think the answer should > be yes. Therefore any frames that are sent on such a network should be > forwarded. > > Two bridges connected via a cable or an RBridge-based network should > look no different. The two bridges should be able to run STP over it and > decide if the ports leading to such a network are in Blocked or Forward > state. > > The RBridges should forward such packets like any other frames. The only > frames that RBridges will consume and process are IS-IS packets (which > will be multicasted on a *new MAC group address*). Dino, I don't claim to understand the tradeoffs between this approach and the approach when BPDUs are filtered (so that they are not encapsulated between the rbridges like other packets). Does anybody want to take a crack at describing what the tradeoffs might be? If the rbridge cloud is BPDU transparent, then we will end up with a single, large 802.1D spanning tree across the whole network. Does or does this not cause more disruption when there are failures/changes in the rbridge core? When there are failures/changes in the far side of the network? (on the other side of the rbridge core) If the rbridge cloud does not let BPDUs transit, then each edge will run its own 802.1D spanning tree, so the trees will be smaller. But the handling of rbridge failures causing the bridges to sent things to a new designated rbridge might be slower or at least different. These are just off the top of my head. As I said it would be good if somebody could try to pull together a comparison of the pros and cons of the different approaches. Erik Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9D2YbL24818 for <rbridge@postel.org>; Wed, 12 Oct 2005 19:34:37 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9D2YaHT009588 for <rbridge@postel.org>; Wed, 12 Oct 2005 19:34:36 -0700 (PDT) Received: from [129.158.215.244] (dhcp-cbjs05-215-09.PRC.Sun.COM [129.158.215.244]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9D2YYvU252081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Oct 2005 19:34:35 -0700 (PDT) Message-ID: <434DC7D6.80502@sun.com> Date: Wed, 12 Oct 2005 19:35:02 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <313680C9A886D511A06000204840E1CF0C885F75@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F75@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] loops in trill networks 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, 13 Oct 2005 02:35:17 -0000 Status: RO Content-Length: 2589 Gray, Eric wrote: > Instead, the normal case should be for RBridges > to terminate the local broadcast domain and the local > STP-based spanning tree. To do this, RBridges should > act as if they were hosts to STP and ignore it. Eric, I'm not sure we have a useful definition for "local broadcast domain" - we have a broadcast domain which spans the whole rbridged network so that IP broadcast continues to work as before. I think that having rbridges act as if they are hosts is a good starting point to think about the problem. But the desire to attach the local (bridged) segment to multiple rbridges for redundancy makes things a bit more complex. Take this picture: H4 | ( Rest of rbridged network ) | | RB1 RB2 | | ( bridged cloud at edge ) | | | H1 H2 H3 Suppose RB1 has been elected as the forwarder to/from the bridged cloud. This means that the bridges have learned (from received packets) that packets to MAC addresses in the rest of the network (e.g., H4) should be sent towards RB1. What happens when RB1 fails? RB2 would take over, and the routing protocol would quickly cause the other rbridges to find out. But packets from H1 to H4 will continue to be forwarded by the bridges towards RB1 until those learning tables time out, or until a packet from H4 arrives via RB2. If we want to ensure that the bridges more quickly find out that they should use RB2, it would seem like we need to add something in the interaction at the edge. Effectively we want RB2 to be able to tell the bridges in the cloud either - that they should discard their learning tables, or - that they should switch to use RB2. I haven't looked at the options in detail, but perhaps we can do the first by RB2 injecting a toplogy change BPDU? For the second approach, one could envision the RBs at the edge presenting themselves as a bridge with a low cost to an imaginary root bridge (which represents the rbridge core)? Of course, we can't ensure that the imaginary becomes the root bridge; the best we can do is to have it have a high probability of becoming the root bridge from the perspective of the bridged cloud at this part of the edge. I don't think this requires that BPDUs be carried across the rbridged cloud - each bridged cloud at the edges can be treated as separate. I don't know how fancy we need to be here, but waiting for the learning tables to time out when there is an RB failures seems a bid bad. Erik Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9D2FgL20473 for <rbridge@postel.org>; Wed, 12 Oct 2005 19:15:43 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9D2Fg1L024433 for <rbridge@postel.org>; Wed, 12 Oct 2005 20:15:42 -0600 (MDT) Received: from [129.158.215.244] (dhcp-cbjs05-215-09.PRC.Sun.COM [129.158.215.244]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9D2FdfV247890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Oct 2005 19:15:41 -0700 (PDT) Message-ID: <434DC367.6@sun.com> Date: Wed, 12 Oct 2005 19:16:07 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> In-Reply-To: <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 13 Oct 2005 02:15:50 -0000 Status: RO Content-Length: 2932 Harald Tveit Alvestrand wrote: > My worry is the end-user PC that attaches to an rbridge, calls itself an > rbridge, and injects fake mappings for another PC in order to deny service > to someone he doesn't like. Or perhaps sniff/modify the traffic ala > "dsniff". > > I guess you could do the same thing with spanning tree.... the defense is > probably to let the bridges distinguish between "core ports" and "user > ports" - but then we're out of the "automatic" configuration space again.... Yes, you can do similar things with spanning tree; the details might be a bit different though. I think the requirement for TRILL should be to do no harm, which I interpret as not being any worse than a bridged network. We can easily do that without any configuration. There are two ways I think we can do better, but it requires configuration. The first one is to use the features in the routing protocol to make sure that your PC can't spoof routing protocol updates. As Bill said, this doesn't require distinguishing between different type of ports on the rbridges. But since at the edge the rbridges, just like bridges, need to learn the location of the MAC address from received frames, this still doesn't prevent your PC from sourcing packets with my MAC address, thereby causing packets to be routed towards you. This is compatible with bridge behavior ;-) If we want to prevent this we need something different (hence incompatible) at the edge. One way would be to use 802.1X at the edge, and some EAP backend which associates the authenticated identity with the allowed MAC address. If you do that, then the rbridges don't need to learn from received packets but can instead use the completion of the 802.1X EAP exchange as the time when the route is injected. Bill Sommerfeld wrote: > Indeed. And to toss in another wrinkle, I may want my multi-ported > server to appear on the rbridge cloud simultaneously at multiple points > without necessarily being willing to provide "transit" to anything other > than the real or virtual end systems inside my box. I assume you might want to be able to have a single MAC address and receive packets over multiple ports - with the rbridges using the shortest path. Is this correct? That is more of a functional problem than a security problem I think. Since end stations might move around, one would assume that when a MAC address appears on a different port, perhaps on a different rbridge as well, that the host has moved. Thus it would make sense to add the route which points to the new place, and remove the route that points to the old place. But in your case you would need that both routes remain in place somehow. Perhaps we can do that by being smarter about when we remove a route for a MAC address? I don't think 802.1X type security changes this, because 802.1X doesn't (reliably) indicate when something goes away. Erik Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9D1svL15649 for <rbridge@postel.org>; Wed, 12 Oct 2005 18:54:57 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9D1qHJ03093 for <rbridge@postel.org>; Wed, 12 Oct 2005 21:52:17 -0400 (EDT) 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: Wed, 12 Oct 2005 21:54:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CD6@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXPdZ8ls6DbVWSzSziejndx9BH9CwAIdBPQ From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9D1svL15649 Subject: Re: [rbridge] loops in trill networks 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, 13 Oct 2005 01:55:49 -0000 Status: RO Content-Length: 704 > Instead, the normal case should be for RBridges > to terminate the local broadcast domain No argument about the 'should'. I was simply trying to understand if this is an absolute 'must'. Your statement below implies this is an absolute 'must' or STP breaks. So I guess I need to take out a sheet of paper and try to understand how... Cheers, Peter > If they do not, then there may be scenarios in which a bridge - thinking that an RBridge is another bridge - will make an incorrect assumption about the forwarding state of the local port of that "bridge". There are doubtless many ways we could finesse this, but what would we gain from doing so other than a lot of needless complexity? Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CLk9L11916 for <rbridge@postel.org>; Wed, 12 Oct 2005 14:46:09 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2005 14:46:05 -0700 Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9CLk2ub002695 for <rbridge@postel.org>; Wed, 12 Oct 2005 14:46:03 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9CLk2NJ020075 for <rbridge@postel.org>; Wed, 12 Oct 2005 14:46:02 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9CLk2BJ020071; Wed, 12 Oct 2005 14:46:02 -0700 Date: Wed, 12 Oct 2005 14:46:02 -0700 Message-Id: <200510122146.j9CLk2BJ020071@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <313680C9A886D511A06000204840E1CF0C885F72@whq-msgusr-02.pit.comms.marconi.com> (Eric.Gray@marconi.com) References: <313680C9A886D511A06000204840E1CF0C885F72@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 21:46:47 -0000 Status: RO Content-Length: 745 >> No, actually, it is not like saying that. I think the fundamental question that needs to be answered is does an RBridge network proivde a layer-2 serivce. And I think the answer should be yes. Therefore any frames that are sent on such a network should be forwarded. Two bridges connected via a cable or an RBridge-based network should look no different. The two bridges should be able to run STP over it and decide if the ports leading to such a network are in Blocked or Forward state. The RBridges should forward such packets like any other frames. The only frames that RBridges will consume and process are IS-IS packets (which will be multicasted on a *new MAC group address*). Dino 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 j9CLZgL07792 for <rbridge@postel.org>; Wed, 12 Oct 2005 14:35:42 -0700 (PDT) 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 j9CLZbUk016010 for <rbridge@postel.org>; Wed, 12 Oct 2005 17:35:37 -0400 (EDT) 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 RAA02959 for <rbridge@postel.org>; Wed, 12 Oct 2005 17:35:37 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP17X9>; Wed, 12 Oct 2005 18:35:36 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F75@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 18:35:35 -0300 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] loops in trill networks 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, 12 Oct 2005 21:35:54 -0000 Status: RO Content-Length: 6450 Peter, With some exceptions (already discussed between Dino and Radia), we don't want an STP based spanning tree being setup across RBridges. There are a lot of potential interaction models between bridges and RBridges. RBridges could be made to appear transparent to bridges, but this is not the reason why RBridges are being defined, nor would we need to define - or use - an encapsulation between pairs of RBridges if this is all we wanted to do. Instead, the normal case should be for RBridges to terminate the local broadcast domain and the local STP-based spanning tree. To do this, RBridges should act as if they were hosts to STP and ignore it. If they do not, then there may be scenarios in which a bridge - thinking that an RBridge is another bridge - will make an incorrect assumption about the forwarding state of the local port of that "bridge". There are doubtless many ways we could finesse this, but what would we gain from doing so other than a lot of needless complexity? For specific exceptions, it is possible to use tunneling to create additional "virtual link(s)" - between a broadcast domain on one side (RBridge port) and one or more other broadcast domains on (an)other side (RBridge port). In this case, the RBridges that are involved would absolutely pass all traffic between each such broadcast domains - including flooded and BPDU frames - most likely without looking at them. In this sense, such exceptions would appear to the broadcast domains (and any directly attached bridges) as a Hub - i.e. - they would be transparent except to the extent that they would make multiple connections possible. Because RBridges in this case would appear as a Hub, it would then be up to the STP between bridges in each connected broadcast domain to ensure that a loop-free STP exists. This works today, and we have no reason to suspect that it should not work in the future. Another model that has been suggested is that the RBridges in this case would act like an aggregate bridge. This could be done, but it cannot be done as the default because - as has been indicated previously - it is not possible for RBridges to distinguish LANs that are "outside" the RBridge domain from LANs that are "inside" the RBridge domain except by configuration. If the RBridges are configured to act as a bridge in the aggregate, then the IS-IS MAC reachability will need to provide sufficient information to those RBridges to allow them to effectively populate filtering database information for the "outward" facing RBridge ports, and those ports will have to collectively participate in STP across the "outside" collective broadcast domains - to include managing port forwarding state. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Peter Ashwood-Smith --> Sent: Wednesday, October 12, 2005 4:20 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> --> What 'precisely' is the problem with a BPDU getting through --> an Rbriged --> network ? It certainly does not break Rbridge so how does --> it break STP? --> --> The designated Rbridge pretty much ensures that the STP on each side --> only sees one link to it, the STP protocol should continue --> normally on --> either side of the Rbridge. No? --> --> --> Peter --> --> --> --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Gray, Eric --> Sent: Wednesday, October 12, 2005 3:46 PM --> To: 'Developing a hybrid router/bridge.' --> Subject: Re: [rbridge] loops in trill networks --> --> --> Dino, --> --> No, actually, it is not like saying that. --> --> Given that we expect to have bridges between Rbridges --> (though they're supposed to be invisible to RBridges), and --> the fact that we expect to have Rbridges connected to each --> other, it is --> not at all bizarre to expect that we might end up with a bridge --> connected to an RBridge on the same port that the RBridge --> is connected --> to another RBridge. Like this: --> --> --> RB-1 ---+--- RB-2 --> | --> | --> B-3 --> | --> | --> RB-4 ---+ --> --> Moreover, there should be nothing problematic about this --> topology either as it will look to the RBridges like this: --> --> RB-1 ---+--- RB-2 --> | --> | --> RB-4 --> --> And to B-3 like this: --> --> H-1 ---+--- H-2 --> | --> | --> B-3 --> | --> | --> H-4 --> --> As you implied, the normal case is that enclosing RBridges --> - like routers - will look to enclosed bridges like hosts. --> I merely stated that RBridges - like hosts - can ignore any --> BPDUs they --> receive. --> --> -- --> Eric --> --> --> -----Original Message----- --> --> From: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org]On --> --> Behalf Of Dino Farinacci --> --> Sent: Wednesday, October 12, 2005 3:08 PM --> --> To: rbridge@postel.org --> --> Cc: rbridge@postel.org --> --> Subject: Re: [rbridge] loops in trill networks --> --> --> --> --> --> >> I believe that many of today's bridges can be --> configured to not --> --> >> send BPDUs on specific ports, but we do _not_ want --> to rely on --> --> >> this. For example, what do we do if both a bridge --> and an RBridge --> --> --> >> are connected to the same port of the bridge we are --> talking about --> --> --> >> (imagine a simple Hub between three+ devices)? --> --> --> --> This is like saying if you run IS-IS on an interface --> --> you should not run --> --> OSPF on the interface. And to make sure you don't the --> --> IS-IS standard --> --> states you must drop all other protocol messages. Which --> --> it does not! --> --> --> --> Dino --> --> _______________________________________________ --> --> 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 zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CKejL19516 for <rbridge@postel.org>; Wed, 12 Oct 2005 13:40:45 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9CKc6518641 for <rbridge@postel.org>; Wed, 12 Oct 2005 16:38:06 -0400 (EDT) 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: Wed, 12 Oct 2005 16:40:37 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CD4@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXPZm5PJrRlJtusRfmSY71DoocwiAAAgJ6wAADPa/AAAFpuMA== From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9CKejL19516 Subject: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 20:41:46 -0000 Status: RO Content-Length: 3794 Yes, clearly but that is a SHOULD not a MUST. I was looking for the MUST. Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Saikat Ray Sent: Wednesday, October 12, 2005 4:30 PM To: 'Developing a hybrid router/bridge.' Subject: Re: [rbridge] loops in trill networks I think one wants to make the spanning tree fragments as small as possible. -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Peter Ashwood-Smith Sent: Wednesday, October 12, 2005 4:20 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks What 'precisely' is the problem with a BPDU getting through an Rbriged network ? It certainly does not break Rbridge so how does it break STP? The designated Rbridge pretty much ensures that the STP on each side only sees one link to it, the STP protocol should continue normally on either side of the Rbridge. No? Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric Sent: Wednesday, October 12, 2005 3:46 PM To: 'Developing a hybrid router/bridge.' Subject: Re: [rbridge] loops in trill networks Dino, No, actually, it is not like saying that. Given that we expect to have bridges between Rbridges (though they're supposed to be invisible to RBridges), and the fact that we expect to have Rbridges connected to each other, it is not at all bizarre to expect that we might end up with a bridge connected to an RBridge on the same port that the RBridge is connected to another RBridge. Like this: RB-1 ---+--- RB-2 | | B-3 | | RB-4 ---+ Moreover, there should be nothing problematic about this topology either as it will look to the RBridges like this: RB-1 ---+--- RB-2 | | RB-4 And to B-3 like this: H-1 ---+--- H-2 | | B-3 | | H-4 As you implied, the normal case is that enclosing RBridges - like routers - will look to enclosed bridges like hosts. I merely stated that RBridges - like hosts - can ignore any BPDUs they receive. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Wednesday, October 12, 2005 3:08 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> I believe that many of today's bridges can be configured to not --> >> send BPDUs on specific ports, but we do _not_ want to rely on --> >> this. For example, what do we do if both a bridge and an RBridge --> >> are connected to the same port of the bridge we are talking about --> >> (imagine a simple Hub between three+ devices)? --> --> This is like saying if you run IS-IS on an interface you should --> not run --> OSPF on the interface. And to make sure you don't the --> IS-IS standard --> states you must drop all other protocol messages. Which --> it does not! --> --> Dino --> _______________________________________________ --> 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 stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CKUNL16011 for <rbridge@postel.org>; Wed, 12 Oct 2005 13:30:23 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9CKUM0B029494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Wed, 12 Oct 2005 16:30:22 -0400 Message-Id: <200510122030.j9CKUM0B029494@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 16:30:26 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B405213CD3@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXPZm5PJrRlJtusRfmSY71DoocwiAAAgJ6wAADPa/A= X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] loops in trill networks X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 12 Oct 2005 20:30:50 -0000 Status: RO Content-Length: 3323 I think one wants to make the spanning tree fragments as small as possible. -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Peter Ashwood-Smith Sent: Wednesday, October 12, 2005 4:20 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks What 'precisely' is the problem with a BPDU getting through an Rbriged network ? It certainly does not break Rbridge so how does it break STP? The designated Rbridge pretty much ensures that the STP on each side only sees one link to it, the STP protocol should continue normally on either side of the Rbridge. No? Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric Sent: Wednesday, October 12, 2005 3:46 PM To: 'Developing a hybrid router/bridge.' Subject: Re: [rbridge] loops in trill networks Dino, No, actually, it is not like saying that. Given that we expect to have bridges between Rbridges (though they're supposed to be invisible to RBridges), and the fact that we expect to have Rbridges connected to each other, it is not at all bizarre to expect that we might end up with a bridge connected to an RBridge on the same port that the RBridge is connected to another RBridge. Like this: RB-1 ---+--- RB-2 | | B-3 | | RB-4 ---+ Moreover, there should be nothing problematic about this topology either as it will look to the RBridges like this: RB-1 ---+--- RB-2 | | RB-4 And to B-3 like this: H-1 ---+--- H-2 | | B-3 | | H-4 As you implied, the normal case is that enclosing RBridges - like routers - will look to enclosed bridges like hosts. I merely stated that RBridges - like hosts - can ignore any BPDUs they receive. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Wednesday, October 12, 2005 3:08 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> I believe that many of today's bridges can be configured to not --> >> send BPDUs on specific ports, but we do _not_ want to rely on --> >> this. For example, what do we do if both a bridge and an RBridge --> >> are connected to the same port of the bridge we are talking about --> >> (imagine a simple Hub between three+ devices)? --> --> This is like saying if you run IS-IS on an interface --> you should not run --> OSPF on the interface. And to make sure you don't the --> IS-IS standard --> states you must drop all other protocol messages. Which --> it does not! --> --> Dino --> _______________________________________________ --> 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 zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CKKWL13337 for <rbridge@postel.org>; Wed, 12 Oct 2005 13:20:32 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9CKHk516588 for <rbridge@postel.org>; Wed, 12 Oct 2005 16:17:47 -0400 (EDT) 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: Wed, 12 Oct 2005 16:20:18 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CD3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXPZm5PJrRlJtusRfmSY71DoocwiAAAgJ6w From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9CKKWL13337 Subject: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 20:20:47 -0000 Status: RO Content-Length: 2852 What 'precisely' is the problem with a BPDU getting through an Rbriged network ? It certainly does not break Rbridge so how does it break STP? The designated Rbridge pretty much ensures that the STP on each side only sees one link to it, the STP protocol should continue normally on either side of the Rbridge. No? Peter -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric Sent: Wednesday, October 12, 2005 3:46 PM To: 'Developing a hybrid router/bridge.' Subject: Re: [rbridge] loops in trill networks Dino, No, actually, it is not like saying that. Given that we expect to have bridges between Rbridges (though they're supposed to be invisible to RBridges), and the fact that we expect to have Rbridges connected to each other, it is not at all bizarre to expect that we might end up with a bridge connected to an RBridge on the same port that the RBridge is connected to another RBridge. Like this: RB-1 ---+--- RB-2 | | B-3 | | RB-4 ---+ Moreover, there should be nothing problematic about this topology either as it will look to the RBridges like this: RB-1 ---+--- RB-2 | | RB-4 And to B-3 like this: H-1 ---+--- H-2 | | B-3 | | H-4 As you implied, the normal case is that enclosing RBridges - like routers - will look to enclosed bridges like hosts. I merely stated that RBridges - like hosts - can ignore any BPDUs they receive. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Wednesday, October 12, 2005 3:08 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> I believe that many of today's bridges can be configured to not --> >> send BPDUs on specific ports, but we do _not_ want to rely on --> >> this. For example, what do we do if both a bridge and an RBridge --> >> are connected to the same port of the bridge we are talking about --> >> (imagine a simple Hub between three+ devices)? --> --> This is like saying if you run IS-IS on an interface --> you should not run --> OSPF on the interface. And to make sure you don't the --> IS-IS standard --> states you must drop all other protocol messages. Which --> it does not! --> --> Dino --> _______________________________________________ --> 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 j9CJjoL02652 for <rbridge@postel.org>; Wed, 12 Oct 2005 12:45:50 -0700 (PDT) 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 j9CJjgUk013914 for <rbridge@postel.org>; Wed, 12 Oct 2005 15:45:42 -0400 (EDT) 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 PAA21075 for <rbridge@postel.org>; Wed, 12 Oct 2005 15:45:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP1Z34>; Wed, 12 Oct 2005 16:45:41 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F72@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 16:45:38 -0300 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] loops in trill networks 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, 12 Oct 2005 19:46:48 -0000 Status: RO Content-Length: 2138 Dino, No, actually, it is not like saying that. Given that we expect to have bridges between Rbridges (though they're supposed to be invisible to RBridges), and the fact that we expect to have Rbridges connected to each other, it is not at all bizarre to expect that we might end up with a bridge connected to an RBridge on the same port that the RBridge is connected to another RBridge. Like this: RB-1 ---+--- RB-2 | | B-3 | | RB-4 ---+ Moreover, there should be nothing problematic about this topology either as it will look to the RBridges like this: RB-1 ---+--- RB-2 | | RB-4 And to B-3 like this: H-1 ---+--- H-2 | | B-3 | | H-4 As you implied, the normal case is that enclosing RBridges - like routers - will look to enclosed bridges like hosts. I merely stated that RBridges - like hosts - can ignore any BPDUs they receive. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Wednesday, October 12, 2005 3:08 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> I believe that many of today's bridges can be configured --> >> to not send BPDUs on specific ports, but we do _not_ want to --> >> rely on this. For example, what do we do if both a bridge and --> >> an RBridge are connected to the same port of the bridge we are --> >> talking about (imagine a simple Hub between three+ devices)? --> --> This is like saying if you run IS-IS on an interface --> you should not run --> OSPF on the interface. And to make sure you don't the --> IS-IS standard --> states you must drop all other protocol messages. Which --> it does not! --> --> Dino --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CJ8IL22099 for <rbridge@postel.org>; Wed, 12 Oct 2005 12:08:18 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Oct 2005 12:08:13 -0700 X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="219513375:sNHT23451616" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9CJ868k015149 for <rbridge@postel.org>; Wed, 12 Oct 2005 12:08:07 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9CJ8BAP015551 for <rbridge@postel.org>; Wed, 12 Oct 2005 12:08:11 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9CJ8Bgw015547; Wed, 12 Oct 2005 12:08:11 -0700 Date: Wed, 12 Oct 2005 12:08:11 -0700 Message-Id: <200510121908.j9CJ8Bgw015547@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <313680C9A886D511A06000204840E1CF0C885F64@whq-msgusr-02.pit.comms.marconi.com> (Eric.Gray@marconi.com) References: <313680C9A886D511A06000204840E1CF0C885F64@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 19:08:47 -0000 Status: RO Content-Length: 554 >> I believe that many of today's bridges can be configured >> to not send BPDUs on specific ports, but we do _not_ want to >> rely on this. For example, what do we do if both a bridge and >> an RBridge are connected to the same port of the bridge we are >> talking about (imagine a simple Hub between three+ devices)? This is like saying if you run IS-IS on an interface you should not run OSPF on the interface. And to make sure you don't the IS-IS standard states you must drop all other protocol messages. Which it does not! Dino 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 j9CHGDL14236; Wed, 12 Oct 2005 10:16:13 -0700 (PDT) Message-ID: <434D4468.6050804@isi.edu> Date: Wed, 12 Oct 2005 10:14:16 -0700 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> References: <313680C9A886D511A06000204840E1CF0C885F66@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F66@whq-msgusr-02.pit.comms.marconi.com> 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: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 17:17:20 -0000 Status: RO Content-Length: 2198 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gray, Eric wrote: > Joe/Radia, > > While the case in which a new RBridge does not partition > the bridged network is uninteresting from the perspective that > we want to take to figure out how the presence of RBridges is > going to make networking more efficient, useful and exciting - > it is extremely interesting from the perspective of how does a > network continue to work while RBridges are in the process of > being deployed. > > For example, in the case Radia mentioned in which there > appears to be an unpartitioned network after replacing one or > more of the bridges with one or more RBridge(s). From what > Radia and others have been saying, the network still works for > all forms of traffic for which it previously worked. A ST will > be determined between bridges and the (one or more) RBridges > will sit there doing nothing interesting (or disruptive). It *is* distruptive if it blocks previous spanning tree paths, since it'd end up creating a detour in the spanning tree which might cause paths to be much more circuitous. > This would also be the case when an RBridge is added to > a network topology where no previous bridge existed. That ought to do not much, AFAICT. > Subsequently, one or more additional bridges are replaced > by Rbridges. This time, the previously existing ST is segmented > (as would imediately be the case when the existing bridge was > removed, even before adding the RBridge). Again, from what has > been said, the network will now work again for all forms of > traffic for which it previously worked. The difference is that > - as Radia said - the RBridges are now doing interesting stuff. Once the spanning tree is segmented; the trick is that I don't think we can know where to deploy rbridges to *force* segmentation. We can know where we disrupt the existing spanning tree, but not where we need to be to partition it. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTURoE5f5cImnZrsRAmoiAJ9IHKHZDIPsYbgLIBNzEzyN+CV3dwCgl4AR comW1mozsfT2PaUD7mR/94E= =OWHk -----END PGP SIGNATURE----- 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 j9CHB4L12577; Wed, 12 Oct 2005 10:11:04 -0700 (PDT) Message-ID: <434D4333.9070703@isi.edu> Date: Wed, 12 Oct 2005 10:09:07 -0700 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> References: <BC468F3648F16146B9FA9123627514F8D672DB@xmb-sjc-217.amer.cisco.com> In-Reply-To: <BC468F3648F16146B9FA9123627514F8D672DB@xmb-sjc-217.amer.cisco.com> 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: Re: [rbridge] seeking input on abstract for problem and applicabilitystatement 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, 12 Oct 2005 17:12:19 -0000 Status: RO Content-Length: 1470 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Smith (michsmit) wrote: > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >> > Here's a proposed abstract. > > Thoughts appreciated. > > Joe > > ----- > > RBridges are layer-2 devices that automatically aggregate > into a virtual device that emulates a single bridge on a > conventional 802.1 Ethernet. > > >> Within this mailing list, I think the above statement is understood but >> to the rest of the community, I think it would be very confusing. It >> gives the impression that the set of rbridges are managed as a single >> device, source L2 protocols as if from the same device, etc. I would >> summarize Rbridges as simply a new form of L2 bridges which use routing >> protocols as the control plane. That's better, IMO. >> A secondary point is that they >> terminate the spanning tree domain of current bridges and attempt to >> retain as much of the "plug-and-play" aspects of current bridges as >> possible. They don't really emulate a single bridge. Agreed - but I'm not sure whether the abstract needs to address spanning tree termination - does it? It should say the part about retaining... as well. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTUMzE5f5cImnZrsRAuLjAJ91+LXBrQlAxCzp0CtD+ZP34036lgCeMldD ZBnehHwsZaCdfTXqaGXTSig= =p1RW -----END PGP SIGNATURE----- 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 j9CH9AL12004; Wed, 12 Oct 2005 10:09:10 -0700 (PDT) Message-ID: <434D42C1.6020908@isi.edu> Date: Wed, 12 Oct 2005 10:07:13 -0700 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> References: <313680C9A886D511A06000204840E1CF0C885F68@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F68@whq-msgusr-02.pit.comms.marconi.com> 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: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement 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, 12 Oct 2005 17:10:16 -0000 Status: RO Content-Length: 1740 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gray, Eric wrote: > Joe, > > The way I interpret Loa's question is "do we expect that > we will have to apply concerns about security similar to those > we have to apply to routing?" I don't think the question has > to do with any expectation that RBridges _generally_ act like > routers. Agreed; sorry to pick that nit ;-) > The answer to this question is that we cannot leave the > security issues unanswered. We can say that we will introduce > no new security issues, but that's not automatic. We plan to > use IS-IS to propagate reachability information and security > concerns that apply generally to IS-IS, will apply also to > RBridges. In addition, we plan to change the way L2 networks > work in a way that allows for larger L2 broadcast domains and > may introduce new security exposures from this as well. IS-IS acts similarly to the existing spanning tree; we need to address its stability to attacks vs. that to a spanning tree. So that looks like a security issue, but not one where the rbridge is intended to be more secure. I.e., all security issues I'm thinking of reduce to 'is this as secure as a bridged L2'. As to larger domains, that's been out of scope for a while. The point of the work is increased functionality - not scale. We probably will need to address the fact that increased functionality may lead to larger deployments, but these aren't larger than a conventional L2 _could_ support. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTULBE5f5cImnZrsRAlrTAJ9FUPdJX33pzdg7/jlBUPVFCOHZ6ACg5u1M TQjYxjpVFcmUxeMwAkEwG5w= =n38h -----END PGP SIGNATURE----- Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CGQLL28699 for <rbridge@postel.org>; Wed, 12 Oct 2005 09:26:21 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2005 09:26:16 -0700 X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="665522747:sNHT27893644" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9CGPtur016921 for <rbridge@postel.org>; Wed, 12 Oct 2005 09:26:14 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 09:26:13 -0700 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: Wed, 12 Oct 2005 09:26:12 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8D672DB@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstract for problem and applicabilitystatement Thread-Index: AcXOyJo1w6Iuv6iiTo6afgHoAzsX+gAf/nQA From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 12 Oct 2005 16:26:13.0065 (UTC) FILETIME=[A958AB90:01C5CF49] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9CGQLL28699 Subject: Re: [rbridge] seeking input on abstract for problem and applicabilitystatement 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, 12 Oct 2005 16:26:46 -0000 Status: RO Content-Length: 2339 > -----Original Message----- > From: rbridge-bounces@postel.org > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's a proposed abstract. > > Thoughts appreciated. > > Joe > > - ----- > > RBridges are layer-2 devices that automatically aggregate > into a virtual device that emulates a single bridge on a > conventional 802.1 Ethernet. Within this mailing list, I think the above statement is understood but to the rest of the community, I think it would be very confusing. It gives the impression that the set of rbridges are managed as a single device, source L2 protocols as if from the same device, etc. I would summarize Rbridges as simply a new form of L2 bridges which use routing protocols as the control plane. A secondary point is that they terminate the spanning tree domain of current bridges and attempt to retain as much of the "plug-and-play" aspects of current bridges as possible. They don't really emulate a single bridge. Michael > > (I had thought that was a concise description, but with > recent discussion about non-participation in some bridge > protocols, I'm not sure. I still think the rbridge MUST > participate in order to avoid loops, but if that's > contentious it can't be part of the abstract yet...) > > They combine layer 2?s ability to allow hosts to reattach > without renumbering with layer 3?s routing benefits. RBridges > use existing link state routing to provide higher internal > cross-section bandwidth, faster convergence under > reconfiguration, and more robustness to link interruption > than an equivalent set of conventional bridges using existing > spanning tree forwarding. They are intended to apply to similar > L2 network sizes as conventional bridges and are intended to > be backward compatible with those bridges as well. This > document describes the need for RBridges and describes > situations where it will be useful. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDTFz0E5f5cImnZrsRAh/nAKCbhP6eVoNCX97zC9/L2zT0WXq9rQCdHBz/ > j6oUNPt5Rmv657FhszmCZzg= > =EpCS > -----END PGP SIGNATURE----- > _______________________________________________ > 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 j9CG9OL24357 for <rbridge@postel.org>; Wed, 12 Oct 2005 09:09:24 -0700 (PDT) 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 j9CG9IUk009355 for <rbridge@postel.org>; Wed, 12 Oct 2005 12:09:19 -0400 (EDT) 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 MAA26764 for <rbridge@postel.org>; Wed, 12 Oct 2005 12:09:18 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP1SSP>; Wed, 12 Oct 2005 13:09:17 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F68@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 13:09:17 -0300 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] seeking input on abstract for problem and applicabi lity statement 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, 12 Oct 2005 16:09:45 -0000 Status: RO Content-Length: 2486 Joe, The way I interpret Loa's question is "do we expect that we will have to apply concerns about security similar to those we have to apply to routing?" I don't think the question has to do with any expectation that RBridges _generally_ act like routers. The answer to this question is that we cannot leave the security issues unanswered. We can say that we will introduce no new security issues, but that's not automatic. We plan to use IS-IS to propagate reachability information and security concerns that apply generally to IS-IS, will apply also to RBridges. In addition, we plan to change the way L2 networks work in a way that allows for larger L2 broadcast domains and may introduce new security exposures from this as well. --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Wednesday, October 12, 2005 11:34 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] seeking input on abstract for problem and --> applicability statement --> --> --> -----BEGIN PGP SIGNED MESSAGE----- --> Hash: SHA1 --> --> --> --> Loa Andersson wrote: --> > --> > Joe Touch wrote: --> > --> > <snip> --> > --> > do we have any idea on to what level security enters into the --> > trill work? not at all, or do the rbridges also in this respect --> > behave as routers? --> --> IMO, they behave as bridges - except perhaps in participation in the --> spanning trees with bridges at their edge. --> --> They do NOT behave as routers - they can't. Routers would kill --> broadcasts, for one. Routers don't exist at L2 anyway - as --> far as the L2 --> is concerned, they're just nodes. --> --> RBridge MAC addresses should only ever be known or used by other --> rbridges, never by other nodes on the L2. --> --> Joe --> --> > /Loa --> > --> > --> >>My understanding is that rbridges are not intended to fix --> any security --> >>problems that persist with an equivalent deployment of bridges. --> >> --> > --> > --> -----BEGIN PGP SIGNATURE----- --> Version: GnuPG v1.2.4 (MingW32) --> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org --> --> iD8DBQFDTSz0E5f5cImnZrsRAuUmAJ9jcqFQjstl/E4Ua9r89LAsI0gmfgCgr4Aq --> mDfONYAdHIoTZOD8swx2HPk= --> =eG4G --> -----END PGP SIGNATURE----- --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CFuGL20386 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:56:17 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 36so58075wra for <rbridge@postel.org>; Wed, 12 Oct 2005 08:56:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=hYj0QDSiNprfQLKzxI/B2G1bR/cwRezayPVtK/NdDCTXPVXj9bv3eHhFB5noACuexDKBbJc9/QWHzWBZku/1kWJqX7DhgOJHEZYXcB/We+rBgQaYlbwTaWuZBeGl1Fra36QH4JUEVJZsnULtNHQP5S7+IOQ6Rd8NKOhUcoqIc4o= Received: by 10.54.148.10 with SMTP id v10mr247525wrd; Wed, 12 Oct 2005 08:56:16 -0700 (PDT) Received: by 10.54.118.20 with HTTP; Wed, 12 Oct 2005 08:56:16 -0700 (PDT) Message-ID: <582968a0510120856t49ab437bxdb2e973f13637e0f@mail.gmail.com> Date: Wed, 12 Oct 2005 11:56:16 -0400 From: Stephen Suryaputra <ssuryaputra@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <434C732B.4050304@sun.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14351_8003839.1129132576300" References: <200510112125.j9BLPout011190@lion.seas.upenn.edu> <434C3537.6000101@sun.com> <434C3EE6.1000405@isi.edu> <434C732B.4050304@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ssuryaputra@gmail.com Subject: Re: [rbridge] loops in trill networks X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ssurya@ieee.org, "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, 12 Oct 2005 15:56:48 -0000 Status: RO Content-Length: 8087 ------=_Part_14351_8003839.1129132576300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Let's see if I understand this: only designated Rbridge port encapsulate L2 packet, forward, and decapsulate Rbridge (shim) packet back to its L2 format. So, from forwarding point of view, non designated port is not connected to the L2 network. Please see the attached network diagram (A text file. Sorry, it's hard to draw a text diagram using my email client) for the following description. A, B, C and D are endnodes. RB1 is the designated Rbridge for segment 1 (with i as the designated port, noted by an asterisk). RB3 is the designate= d Rbridge for segment 2 (j is the designated port). D sends a broadcast frame. Only RB1 encapsulates the frame with the shim he= ader and forwards it unicast to the IS-IS spanning tree (to RB2, RB3 and RB4). R= B2 and RB3 decapsulates the frame and send it to their endnodes, but RB4 does = not because it is not the designated Rbridge for segment 2. If my understanding is correct, I agree that loops won't exist and Rbridge does not need to participate in 802.1 spanning tree protocol. The drawback is the broadcast frame is seen multiple times on segment 1. The description in section 2.3 of the draft on the role of designated bridge and designated port must be clarified to avoid confusion. Stephen. On 10/11/05, Radia Perlman <Radia.Perlman@sun.com> wrote: > Re: Joe's comments about my scenario (first saying that > replacing some bridges with RBridges may not partition the campus, which > is true but not relevant > to the point I was making, and second saying that RBridges have to join > in the bridge spanning tree > or else there will be loops, which is not true, and it's important that > we all understand that). > > ********************** > There's confusion here. Sorry if I'm not explaining properly. > > Let's start over again with the steps I was saying: > > You start with one giant bridged campus. There is one spanning tree. > > Then you replace some of the bridges with RBridges. > > Pretend that the RBridges don't forward ANY packets. > > Now the campus is likely partitioned into several pieces, let's say 5, > with no connectivity > between the pieces. > > *********** > Perhaps you are quibbling with "likely partitioned". If the > topology is such that the particular bridges you've replaced with RBridg= es doesn't > partition things, then you will wind up with what looks to the RBridges l= ike they > are all connected to the same link. One port of one will get elected Desi= gnated RBridge. > But it won't *do* anything. It won't decapsulate or encapsulate or forwar= d any > data packets. It will just sit there unless there is another "link" in th= e topology. > But all the RBridges just see a single link. Even if they have multiple p= orts onto > the same link. > > But I'm trying to explain a topology in which RBridges *will* do somethin= g. That > is when the topology, if you halted all the RBridges, *is* partitioned. S= o assume > you have replaced enough bridges with (for now halted) RBridges, so the w= orld > is partitioned into 5 pieces. > ************** > > Back to the story I was telling. To reiterate, you've either partitioned > things, or you haven't. If you haven't, > then the RBridges aren't doing anything. The bridges will all compute a > single spanning tree that connects > all the segments that the RBridges see, so all the RBridges see is the > simple topology of them all connecting > to a single link, and as I said, they won't be forwarding any data > packets. The only thing they'll be doing is > transmitting LSPs and Hello messages. But none of them will forward > anything. That's not a very interesting > topology. Let's get on to what happens in the interesting case. > > So now let's assume you have managed to partition the campus. Then let's > continue with what I was saying: > > ************* > > The bridges in each partition compute their own spanning tree, with their > own Root bridge. The different spanning trees will not see each other, a= nd will not merge (because we've said the RBridges are not forwarding the B= PDUs). > > Now let's turn on the RBridges, and let them do their thing. > > > Each of the pieces looks to the RBridges like a single link. The > RBridges don't see the difference between > a single Ethernet segment, or a bridged Ethernet segment. Just like > routers don't see the bridges. > > So now we can ignore the bridges, and think of a topology consisting of > 5 links, and a bunch of > RBridges connecting the links. Some of the RBridges might have multiple > ports onto the same link. > > Now the RBridges are similar to routers, where they compute optimal > paths between each other, over those > "links". > > Everything works, just as it works to have routers connected in an > arbitrary topology over an arbitrary > set of links. > > *************** > > I hope I'm making things clearer... > > Radia > > > Now you (Joe) said: > > >Those links can touch the rbridge in multiple places - there's no reason > >they necessarily connect to a single port. > > > What happens if an RBridge has two ports onto what it sees as the same > "link" is that only one of > the ports winds up Designated. So an RBridge will not decapsulate a > packet onto port i and then > pick it up and encapsulate it on port j, if the RBridge things that port > i and port j are the same link, > which it will, if port i and j are connected through a path of bridges. > > It is most definitely the case that RBridges do not participate in, nor > do they need to participate in, > the bridge spanning tree protocol. They need to have a forwarding entry > for the multicast address > on which the BPDUs are sent, to *not forward* packets sent to that > multicast address. > > Radia > > > > > While this is OK for the > >rbridge egress (it picks one designated rbridge on that link to send > >things out), it's entirely possible that a broadcast will end up cycling > >back over that link to another ingress port. > > > >That's why the rbridge needs to be in the spanning tree protocol. > >Otherwise the 'links' outside can loop back onto the rbridge. > > > >Joe > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.2.4 (MingW32) > >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > > >iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk > >UPKxoEu4qB+tJlVtDS8ylRo=3D > >=3Dwc2h > >-----END PGP SIGNATURE----- > >_______________________________________________ > >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 > ------=_Part_14351_8003839.1129132576300 Content-Type: text/plain; name="Understanding Designated Rbridge.txt"; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Understanding Designated Rbridge.txt" Physical topology ----------------- segment 1 | D----+ | *+-------+* +----+i RB1 j+----A | +-------+ *+-------+ | C----+i RB2 j+----+ segment 2 +-------+ | +-------+* | +----+i RB3 j+----+ | +-------+ | | +----B | +-------+ | +----+i RB4 j+----+ | +-------+ | Topology from Rbridge point of view ----------------------------------- D A | | | | +-----+ +-----+ +-----+ C----+ RB2 +====+ RB1 +=====+ RB3 +----B +-----+ +-----+ +-----+ || || || +-----+ + RB4 + +-----+ ------=_Part_14351_8003839.1129132576300-- 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 j9CFdNL15376; Wed, 12 Oct 2005 08:39:23 -0700 (PDT) Message-ID: <434D2DB6.20109@isi.edu> Date: Wed, 12 Oct 2005 08:37:26 -0700 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> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> <1129128392.14491.32.camel@unknown.hamachi.org> In-Reply-To: <1129128392.14491.32.camel@unknown.hamachi.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: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 15:40:15 -0000 Status: RO Content-Length: 2894 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: > I support "can automatically" because the customers will always want > knobs. > (Seems we're arguing about defaults). Yes, I think so. >>Joe Touch wrote: >> >>>'can' implies they might not, which would be bad (consider bridges that >>>refused to participate in spanning tree). > > I've run into managed switches which, as best as I can tell, came from > the factory with spanning tree turned off by default. Are those compliant? Or is that just a vendor choice to distribute them in non-compliant mode for some reason? > Harald wrote: > >>My worry is the end-user PC that attaches to an rbridge, calls itself an >>rbridge, and injects fake mappings for another PC in order to deny service >>to someone he doesn't like. Or perhaps sniff/modify the traffic ala >>"dsniff". > > Indeed. And to toss in another wrinkle, I may want my multi-ported > server to appear on the rbridge cloud simultaneously at multiple points > without necessarily being willing to provide "transit" to anything other > than the real or virtual end systems inside my box. That's not a wrinkle. That's a single physical box that - as far as L2 is concerned - *IS* multiple nodes on the L2. L2 doesn't care whether a node is an L3 transit (router) or an L3 source/sink (host). Nodes are L2 sources/sinks, and everything else is a link or emulation thereof (bridges, hubs, etc.) >>I guess you could do the same thing with spanning tree.... the defense is >>probably to let the bridges distinguish between "core ports" and "user >>ports" - but then we're out of the "automatic" configuration space again.... > > Yep. People who actually manage their networks will want those knobs. Sure. Right now, ports can be both core and user at the same time, but there could be options to prohibit traffic of either type. > On the other hand, given crypto authentication support in the underlying > routing protocol, the "core" vs "user" distinction might be managed by > what the other device "knows" rather than by which port it's plugged > into. 'core' traffic is defined by the existence of the campus transit header (CTH) [the shim header]. everything else is user traffic. There's no need to designate the two per-port; the rbridge device already needs to know the distiction between the two. Core is forwarded or decapsulated (if the L2 destination matches); edge is encapsulated and forwarded. While crypto for campus routing would be nice, it's like crypto for the spanning tree - it would inhibit plug-and-play, and the lack of it doesn't add a new vulnerability. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTS22E5f5cImnZrsRAnPmAJ9QKwJDxOUbOSQgCg3P/W9xz2NIWACg9CBU DyJAfQ9Vjo9q/Nqk3UJfSq8= =VUFb -----END PGP SIGNATURE----- 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 j9CFa9L14425; Wed, 12 Oct 2005 08:36:09 -0700 (PDT) Message-ID: <434D2CF4.3030003@isi.edu> Date: Wed, 12 Oct 2005 08:34:12 -0700 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> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> <434D1770.2080503@isi.edu> <434D1B12.8000903@pi.se> In-Reply-To: <434D1B12.8000903@pi.se> 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: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 15:37:14 -0000 Status: RO Content-Length: 1071 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Loa Andersson wrote: > > Joe Touch wrote: > > <snip> > > do we have any idea on to what level security enters into the > trill work? not at all, or do the rbridges also in this respect > behave as routers? IMO, they behave as bridges - except perhaps in participation in the spanning trees with bridges at their edge. They do NOT behave as routers - they can't. Routers would kill broadcasts, for one. Routers don't exist at L2 anyway - as far as the L2 is concerned, they're just nodes. RBridge MAC addresses should only ever be known or used by other rbridges, never by other nodes on the L2. Joe > /Loa > > >>My understanding is that rbridges are not intended to fix any security >>problems that persist with an equivalent deployment of bridges. >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTSz0E5f5cImnZrsRAuUmAJ9jcqFQjstl/E4Ua9r89LAsI0gmfgCgr4Aq mDfONYAdHIoTZOD8swx2HPk= =eG4G -----END PGP SIGNATURE----- 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 j9CFa9L14421 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:36:09 -0700 (PDT) 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 j9CFa3Uk008640 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:36:03 -0400 (EDT) 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 LAA22846 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:36:03 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP1RP6>; Wed, 12 Oct 2005 12:36:02 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F66@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 12:36:00 -0300 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] loops in trill networks 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, 12 Oct 2005 15:37:12 -0000 Status: RO Content-Length: 5136 Joe/Radia, While the case in which a new RBridge does not partition the bridged network is uninteresting from the perspective that we want to take to figure out how the presence of RBridges is going to make networking more efficient, useful and exciting - it is extremely interesting from the perspective of how does a network continue to work while RBridges are in the process of being deployed. For example, in the case Radia mentioned in which there appears to be an unpartitioned network after replacing one or more of the bridges with one or more RBridge(s). From what Radia and others have been saying, the network still works for all forms of traffic for which it previously worked. A ST will be determined between bridges and the (one or more) RBridges will sit there doing nothing interesting (or disruptive). This would also be the case when an RBridge is added to a network topology where no previous bridge existed. Subsequently, one or more additional bridges are replaced by Rbridges. This time, the previously existing ST is segmented (as would imediately be the case when the existing bridge was removed, even before adding the RBridge). Again, from what has been said, the network will now work again for all forms of traffic for which it previously worked. The difference is that - as Radia said - the RBridges are now doing interesting stuff. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Tuesday, October 11, 2005 11:04 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Earlier, Joe said... Radia Perlman wrote: ... > But I'm trying to explain a topology in which RBridges *will* do something. That > is when the topology, if you halted all the RBridges, *is* partitioned. So assume > you have replaced enough bridges with (for now halted) RBridges, so the world > is partitioned into 5 pieces. AOK - I was thinking of this in particular for the applicability part of the problem/applicability statement. The catch is that this is going to be less useful if this is required but cannot be detected or encouraged somehow. ... > Now let's turn on the RBridges, and let them do their thing. > > Each of the pieces looks to the RBridges like a single link. The > RBridges don't see the difference between > a single Ethernet segment, or a bridged Ethernet segment. Just like > routers don't see the bridges. You've said here and before that the rbridge looks like a router - but it does not, because routers have ethernet addresses and source and sink packets. Routers and hosts are just nodes on a ethernet segment, nodes that have 802 addresses. Now if the rbridge has an 802 address, then we have a big problem about how to cross the rbridge and come out the right place - we need to do proxy ARP on all the external links, we need to rewrite the packets we receive, and we potentially pollute the ARP caches of nodes on the links that then move elsewhere in the system. So we need to have some other analogy - e.g., it's a bridge that blocks BPDUs. Back to the key question... ... >>Those links can touch the rbridge in multiple places - there's no reason >>they necessarily connect to a single port. > > What happens if an RBridge has two ports onto what it sees as the same > "link" is that only one of > the ports winds up Designated. So an RBridge will not decapsulate a > packet onto port i and then > pick it up and encapsulate it on port j, if the RBridge things that port > i and port j are the same link, > which it will, if port i and j are connected through a path of bridges. OK. I'm understanding the trick -maybe. Basically, there's effectively a phantom spanning tree inside the rbridge. You just made one by saying there's exactly one 'designated' port. So I *can* think of this as one big bridge. One that has internal logic that makes sure that it touches each spanning tree it sees externally in one place (isn't that what spanning tree does?) and then ends up acting like a terminus on each spanning tree (again, what spanning tree does). So although BPDUs aren't forwarded, the net effect of a spanning tree is retained. So maybe (***here's the interesting point, IMO - if I understand this now***) this also works for bridges. They don't strictly need to forward BPDUs either (by analogy). All they need to do is act sufficiently like an rbridge campus and things will work - and the spanning trees will be partitioned. Can anyone explain to me why this won't work with a regular bridge if we built it? And if it did, wouldn't it make the spanning trees a LOT simpler at the edges? All we have to do is make sure these 'magic bridges' are deployed in ways that partition the existing bridges into non-connected stubs - which we have to figure a way to do with rbridges too. So does that work? (and if so, has anybody tried it?) Joe Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CFN9L11012 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:23:09 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9CFN1U24149 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:23:02 -0400 (EDT) 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: Wed, 12 Oct 2005 11:23:01 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405213CCD@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] seeking input on abstract for problem and applicabilitystatement Thread-Index: AcXOyL6wcMe2UVYuQfKSMkrJaG4oLgAApcEAAB1Oc1A= From: "Peter Ashwood-Smith" <petera@nortel.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: petera@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9CFN9L11012 Subject: Re: [rbridge] seeking input on abstract for problem and applicabilitystatement 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, 12 Oct 2005 15:23:44 -0000 Status: RO Content-Length: 913 > I still think the rbridge MUST participate in order to avoid loops, > but if that's contentious it can't be part of the abstract yet...) Let me see if I can help. Radia gave a good description of why the Rbridge does not need to participate in STP/FSTP but here is another way to think of it and perhaps it will strike different chords: Take two node disjoint trees A and B. Now, connect the trees A and B with only ONE link. The result is still a tree. This is "sort of" what the combination of STP and Rbridge protocols are doing. STP computes one tree. Rbridge computes the other and finally Rbridge connects the two with only ONE link using the designated Rbridge concept. Since we can apply this same mechanism over and over again, i.e. induction we are guaranteed the end result is indeed one big tree and therefore is loop free, ... at least in the steady state. Cheers, Peter Ashwood-Smith 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 j9CFIWL09563 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:18:32 -0700 (PDT) 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 j9CFIRUk008288 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:18:27 -0400 (EDT) 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 LAA20637 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:18:26 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP1Q7K>; Wed, 12 Oct 2005 12:18:25 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F65@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 12:18:23 -0300 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] loops in trill networks 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, 12 Oct 2005 15:18:48 -0000 Status: RO Content-Length: 3365 Joe, If RBridges are connected by a single broadcast domain, "outside" of the RBridge domain, this is the same as having a common LAN/broadcast-domain inside the RBridge domain. The term "outside" is topologically meaningless. Consequently, the potential for looping traffic through this "outside" broadcast domain is exactly the same as looping traffic through an "inside" broadcast domain. Therefore, the same process for selecting a designated forwarder would be used for either common broadcast domain. It should _not_ be done using STP. It is not necessary and results in the same disuse of redundant capacity as would be the case without RBridges. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Tuesday, October 11, 2005 6:39 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> -----BEGIN PGP SIGNED MESSAGE----- --> Hash: SHA1 --> --> --> --> Radia Perlman wrote: --> > Let me try explaining it a different way. --> > --> > You start with one giant bridged campus. There is one --> spanning tree. --> > --> > Then you replace some of the bridges with RBridges. --> > --> > Pretend that the RBridges don't forward ANY packets. --> > --> > Now the campus is likely partitioned into several pieces, --> let's say 5, --> > with no connectivity --> > between the pieces. --> --> That's not necessarily likely. That would only occur if the --> network were --> wired as a spanning tree; if we could expect that, we --> wouldn't need to --> generate one. --> --> I.e., it's more likely that such partitioning might not --> occur - however, --> the rbridge system might not provide a benefit in those --> cases. AFAICT, --> an rbridge helps only where it does partition the bridges as above. --> --> Let's thus assume that's the case, as engineered: --> --> > Each piece computes its own spanning tree, with its own --> Root bridge. So you --> > have 5 independent, disconnected spanning trees. --> > --> > Now think of each of those 5 pieces as a single link. The --> fact that each --> > piece --> > is glued together with spanning tree with bridges is --> invisible outside --> > that piece. So we --> > can stop thinking about bridges, and now only look at the --> next layer --> > up...the RBridges. --> --> Those links can touch the rbridge in multiple places - --> there's no reason --> they necessarily connect to a single port. While this is OK for the --> rbridge egress (it picks one designated rbridge on that link to send --> things out), it's entirely possible that a broadcast will --> end up cycling --> back over that link to another ingress port. --> --> That's why the rbridge needs to be in the spanning tree protocol. --> Otherwise the 'links' outside can loop back onto the rbridge. --> --> Joe --> -----BEGIN PGP SIGNATURE----- --> Version: GnuPG v1.2.4 (MingW32) --> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org --> --> iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk --> UPKxoEu4qB+tJlVtDS8ylRo= --> =wc2h --> -----END PGP SIGNATURE----- --> _______________________________________________ --> 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 j9CF9QL06870 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:09:26 -0700 (PDT) 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 j9CF9LUk008032 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:09:21 -0400 (EDT) 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 LAA19499 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:09:21 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP1QS6>; Wed, 12 Oct 2005 12:09:20 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F64@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 12:09:19 -0300 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] loops in trill networks 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, 12 Oct 2005 15:09:47 -0000 Status: RO Content-Length: 1834 Dino, I believe that many of today's bridges can be configured to not send BPDUs on specific ports, but we do _not_ want to rely on this. For example, what do we do if both a bridge and an RBridge are connected to the same port of the bridge we are talking about (imagine a simple Hub between three+ devices)? Also, I am not sure that all bridges have this capability - since it is not necessary even for hosts (hosts ignore BPDUs, even if they get them). If it is not necessary for any current deployment, it is an unnecessary complication and may be left out. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Dino Farinacci --> Sent: Tuesday, October 11, 2005 8:10 PM --> To: rbridge@postel.org --> Cc: rbridge@postel.org --> Subject: Re: [rbridge] loops in trill networks --> --> --> >> As for providing glue to two broadcast domains in order to merge --> >> them...yes, an RBridged "campus" --> >> could be used to tunnel packets from the two broadcast --> domains in order --> >> to merge them. --> --> Yes, agree. --> --> >> But in general an RBridge would not forward a native --> BPDU. It would --> >> recognize it as something --> >> it shouldn't forward. Because RBridges intend to make --> the spanning trees --> --> So we have to put special checks in the hardware --> forwarding plane? I --> would rather not put this in the architecture and just --> document that --> bridges should not send BPDUs on links where rBridges --> exist. Just like --> bridges don't generally send BPDUs on host ports today. --> --> Dino --> --> --> --> --> _______________________________________________ --> 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 j9CF2fL05025 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:02:41 -0700 (PDT) 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 j9CF2aUk007864 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:02:36 -0400 (EDT) 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 LAA18719 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:02:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFP1QLV>; Wed, 12 Oct 2005 12:02:35 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F63@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Wed, 12 Oct 2005 12:02:34 -0300 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] loops in trill networks 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, 12 Oct 2005 15:03:46 -0000 Status: RO Content-Length: 10778 Larry, I don't think we're disagreeing. The trouble is in the phrase "spanning tree". What I am trying to say is that how frames are forwarded between RBridges (e.g. - RB3 and RB4) is determined by a different protocol than is used to make the same determination for frame forwarding between bridges. Yes, the effect is similar to a "spanning tree" as will be determined by STP between bridges, but it is not the same. For RBridges RB1, RB2, RB3 and RB4, the topology you posit is going to be marginally simpler: A--RB1----+--RB2--B | | | | D--RB4---RB3--C All of the RBridges see the topology this same way. I assume that the difference between this and any other form of link state routing is that routers aren't _normally_ concerned with broadcast. However, routers will have to deal with IP multicast, and the difference between broadcast and multicast is not important, as the same topology issues arise in IP multicast routing - especially if you assume a majority of routers in any locality might be serving the same multicast group. We don't want to use STP to determine how to avoid loops and duplicate transmissions because using a link-state routing protocol allows us to make clever use of redundant connections. This is the important logical distinction. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Larry Kreeger (kreeger) --> Sent: Tuesday, October 11, 2005 7:42 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> Eric, --> --> Notice that in my example below, I am only talking about broadcast --> connectivity - not unicast. There is not MAC advertisements for --> broadcast. A broadcast must go to every edge port. In this case, a --> spanning tree must exist (across both the RBridge and 802.1d bridged --> network) or a broadcast loop will occur. --> --> - Larry --> --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Gray, Eric --> Sent: Tuesday, October 11, 2005 3:45 PM --> To: 'Developing a hybrid router/bridge.' --> Subject: Re: [rbridge] loops in trill networks --> --> Larry, --> --> You have to think of bridges and RBridges as existing at two --> layers. How frames are forwarded between RBridges will be --> determined by --> shortest path computation based on MAC advertisements in IS-IS. How --> frames are forwarded across --> 802.1 bridges between RBridges is based on STP. --> --> -- --> E --> --> --> -----Original Message----- --> --> From: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org]On --> --> Behalf Of Larry Kreeger (kreeger) --> --> Sent: Tuesday, October 11, 2005 5:08 PM --> --> To: Developing a hybrid router/bridge. --> --> Subject: Re: [rbridge] loops in trill networks --> --> --> --> --> --> Radia, --> --> --> --> How about the case where the two ports connected to the --> same bridged --> --> --> domain are on different RBridges? --> --> --> --> Consider, the following topology where A,B,C are hosts. --> --> --> --> A--RB1--Bridged-Domain--RB2--B --> --> | --> --> | --> --> RB3--C --> --> --> --> In this case, would all RB's forward a L2 broadcast to their --> --> respective edge ports? I was assuming, yes. If so, --> then RB1,RB2 --> --> and --> --> RB3 are all --> --> designated RBs in order to have broadcast connectivity between --> --> A,B,C. --> --> --> --> Now a new RB4 is added to the topology which connects --> RB1 and RB3, --> --> --> --> A--RB1--Bridged-Domain--RB2--B --> --> | | --> --> | | --> --> D--RB4-------RB3--C --> --> --> --> Are you saying that RB1 and RB3 detect that they now have new --> --> connectivity and battle to be a Designated RB to serve --> their side of --> --> --> the network? Assuming RB3 wins, all broadcasts must --> enter and leave --> --> --> the Bridged-Domain via RB3 to get between hosts A,C,D and B. --> --> RB2 must still --> --> be the Designated RB for traffic to reach B. --> --> --> --> I didn't think routers needed to deal with this since --> they don't --> --> forward broadcasts. Are you saying that routing --> protocols already --> --> deal with these types of scenarios? --> --> --> --> Thanks, Larry --> --> --> --> -----Original Message----- --> --> From: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> --> Sent: Tuesday, October 11, 2005 12:46 PM --> --> To: Developing a hybrid router/bridge. --> --> Subject: Re: [rbridge] loops in trill networks --> --> --> --> The intention is that deployment not have to be --> careful. If two of --> --> an RBridge's ports are connected to the same bridged broadcast --> --> domain (i.e., there is a bridge-connected path between the two --> --> ports), then the RBridge will think it has two ports --> connected to --> --> the same link. Which is OK. --> --> It won't forward any packets, including not BPDUs, --> between those --> --> ports. --> --> At most one of --> --> its ports will become "designated" for sourcing/sinking --> --> unencapsulated traffic to/from that link. --> --> --> --> It would be just like a router having two ports --> connected to the --> --> same link, which should work with no problem. --> --> --> --> Radia --> --> --> --> --> --> --> --> Gray, Eric wrote: --> --> --> --> >Radia, --> --> > --> --> > If I am understanding what you are saying --> correctly, there are --> --> some --> --> >deployment issues with Rbridges into a 802.1 bridged --> environment. --> --> > --> --> > The deployment issues arise when individual RBridges are --> --> installed, if --> --> >this is not carefully planned in advance. --> --> >If an Rbridge is installed on a link where it is connected --> --> to two or --> --> >more 802.1 bridges and there is another L2 path --> between those two --> --> >bridges, the RBridge will either have to forward BPDUs --> or - like a --> --> >router - recognize that multiple ports are connected to --> --> the same LAN. --> --> > --> --> > Is there an intention that the latter would be --> the default case --> --> until --> --> >and unless the installed RBridge is able to discover a --> connected --> --> >RBridge peer? --> --> > --> --> >-- --> --> >Eric Gray --> --> > --> --> >--> -----Original Message----- --> --> >--> From: rbridge-bounces@postel.org --> --> >--> [mailto:rbridge-bounces@postel.org]On --> --> >--> Behalf Of Radia Perlman --> --> >--> Sent: Tuesday, October 11, 2005 12:44 PM --> --> >--> To: Developing a hybrid router/bridge. --> --> >--> Subject: Re: [rbridge] loops in trill networks --> --> >--> --> --> >--> --> --> >--> There's nothing an RBridge can do about loops --> --> consisting of just --> --> >--> bridges. --> --> >--> Which is why it's good to partition the spanning trees --> --> formed by --> --> >--> the bridges so that the remaining spanning trees are --> --> as small, and --> --> >--> therefore as stable, as possible. --> --> >--> --> --> >--> RBridges are like routers. They sit at a layer above --> --> bridges. The --> --> >--> bridges form what looks like a single link to the --> RBridges. If --> --> >--> there are a bunch of bridges connecting a bunch of --> --> segments, all --> --> >--> the RBridges attached to that portion of the --> network see that --> --> >--> bridged segment as a single link. --> --> >--> --> --> >--> Radia --> --> >--> --> --> >--> Loa Andersson wrote: --> --> >--> --> --> >--> >Oh, yes it is true ... --> --> >--> > --> --> >--> >but I thought that a trill network could consist of a --> --> mixed of --> --> >--> >rbridges and the type of bridges that exist today, if --> --> that is the --> --> >--> >case you can possibly form the loop over only non-rbridges --> --> >--> > --> --> >--> >but I'm not up to speed on this, there might be a way --> --> to handle --> --> >--> >this also --> --> >--> > --> --> >--> >/Loa --> --> >--> > --> --> >--> >Joe Touch wrote: --> --> >--> > --> --> >--> > --> --> >--> >>There is, and that's what it's there for. --> --> >--> >> --> --> >--> >>Joe --> --> >--> >> --> --> >--> >>Mike Hughes wrote: --> --> >--> >> --> --> >--> >> --> --> >--> >> --> --> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson --> <loa@pi.se> --> --> wrote: --> --> >--> >>> --> --> >--> >>> --> --> >--> >>> --> --> >--> >>> --> --> >--> >>> --> --> >--> >>>>this might be an old discussion, but it is some --> --> time since it --> --> >--> >>>>look at it. What do we do in trill networks about --> --> transient --> --> >--> >>>>loops, i.e. if use link state protocols there is a --> --> possibility --> --> >--> >>>>that we have transient loops. With no TTL mechanisms --> --> >--> those looping --> --> >--> >>>>frames could cause quite a bit of problem. --> --> >--> >>>> --> --> >--> >>>> --> --> >--> >>>Unless I've missed something, or things have changed --> --> >--> overnight, there is a --> --> >--> >>>TTL provided in the SHIM header. --> --> >--> >>> --> --> >--> >>>Mike --> --> >--> >>> --> --> >--> >>> --> --> >--> --> >>>--------------------------------------------------------- --> --> >--> --------------- --> --> >--> >>> --> --> >--> >>>_______________________________________________ --> --> >--> >>>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 --> --> _______________________________________________ --> --> 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 brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CElqL01062 for <rbridge@postel.org>; Wed, 12 Oct 2005 07:47:52 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9CElnvD019656 for <rbridge@postel.org>; Wed, 12 Oct 2005 08:47:50 -0600 (MDT) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j9CElmf8001398; Wed, 12 Oct 2005 07:47:49 -0700 (PDT) From: Bill Sommerfeld <sommerfeld@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> Content-Type: text/plain; charset=ASCII Message-Id: <1129128392.14491.32.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Wed, 12 Oct 2005 10:46:32 -0400 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sommerfeld@sun.com Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 14:48:45 -0000 Status: RO Content-Length: 1443 I support "can automatically" because the customers will always want knobs. (Seems we're arguing about defaults). > Joe Touch wrote: > > 'can' implies they might not, which would be bad (consider bridges that > > refused to participate in spanning tree). I've run into managed switches which, as best as I can tell, came from the factory with spanning tree turned off by default. Harald wrote: > My worry is the end-user PC that attaches to an rbridge, calls itself an > rbridge, and injects fake mappings for another PC in order to deny service > to someone he doesn't like. Or perhaps sniff/modify the traffic ala > "dsniff". Indeed. And to toss in another wrinkle, I may want my multi-ported server to appear on the rbridge cloud simultaneously at multiple points without necessarily being willing to provide "transit" to anything other than the real or virtual end systems inside my box. > I guess you could do the same thing with spanning tree.... the defense is > probably to let the bridges distinguish between "core ports" and "user > ports" - but then we're out of the "automatic" configuration space again.... Yep. People who actually manage their networks will want those knobs. On the other hand, given crypto authentication support in the underlying routing protocol, the "core" vs "user" distinction might be managed by what the other device "knows" rather than by which port it's plugged into. - Bill Received: from smtp.testbed.se ([80.86.78.228]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CEKHL24006 for <rbridge@postel.org>; Wed, 12 Oct 2005 07:20:17 -0700 (PDT) Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.209]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EPhSP-0001Xu-Ue for rbridge@postel.org; Wed, 12 Oct 2005 16:19:55 +0200 Message-ID: <434D1B12.8000903@pi.se> Date: Wed, 12 Oct 2005 16:17:54 +0200 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> <434D1770.2080503@isi.edu> In-Reply-To: <434D1770.2080503@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: loa@pi.se Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 14:20:44 -0000 Status: RO Content-Length: 617 Joe Touch wrote: > <snip> do we have any idea on to what level security enters into the trill work? not at all, or do the rbridges also in this respect behave as routers? /Loa > > My understanding is that rbridges are not intended to fix any security > problems that persist with an equivalent deployment of bridges. > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9CE2UL19951; Wed, 12 Oct 2005 07:02:30 -0700 (PDT) Message-ID: <434D1770.2080503@isi.edu> Date: Wed, 12 Oct 2005 07:02:24 -0700 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> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> In-Reply-To: <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE2089271106CDD6CCB7B341D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 14:02:45 -0000 Status: RO Content-Length: 1851 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE2089271106CDD6CCB7B341D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > --On tirsdag, oktober 11, 2005 23:19:07 -0700 Joe Touch <touch@ISI.EDU> > wrote: > > >>>somehow I get this awful feeling when I see a disruption-sensitive >>>infrastructure that devices can "automatically" join..... too many IETFs >>>watching NOC crew hunt down rogue devices of various kinds... >>> >>>no objection to "can automatically"..... >> >>'can' implies they might not, which would be bad (consider bridges that >>refused to participate in spanning tree). > > My worry is the end-user PC that attaches to an rbridge, calls itself an > rbridge, and injects fake mappings for another PC in order to deny service > to someone he doesn't like. Or perhaps sniff/modify the traffic ala > "dsniff". > > I guess you could do the same thing with spanning tree.... the defense is > probably to let the bridges distinguish between "core ports" and "user > ports" - but then we're out of the "automatic" configuration space again.... My understanding is that rbridges are not intended to fix any security problems that persist with an equivalent deployment of bridges. Somebody let me know if otherwise ;-) Joe --------------enigE2089271106CDD6CCB7B341D 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDTRdwE5f5cImnZrsRAt4hAKC/A5ZmkqMpJ6MOClrQx/8CTYjvZACgzluP fOxQ0bJ6ojLRp/51pbw043Y= =BwRn -----END PGP SIGNATURE----- --------------enigE2089271106CDD6CCB7B341D-- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9C9mCL14680 for <rbridge@postel.org>; Wed, 12 Oct 2005 02:48:13 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AB952596BD for <rbridge@postel.org>; Wed, 12 Oct 2005 11:47:38 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15313-02 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:47:35 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2313A2596B9 for <rbridge@postel.org>; Wed, 12 Oct 2005 11:47:35 +0200 (CEST) Date: Wed, 12 Oct 2005 11:48:01 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <8F94E116410D9BF8B8046939@gloppen.hjemme.alvestrand.no> In-Reply-To: <434CAADB.4050204@isi.edu> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> <434CAADB.4050204@isi.edu> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 09:48:45 -0000 Status: RO Content-Length: 956 --On tirsdag, oktober 11, 2005 23:19:07 -0700 Joe Touch <touch@ISI.EDU> wrote: >> somehow I get this awful feeling when I see a disruption-sensitive >> infrastructure that devices can "automatically" join..... too many IETFs >> watching NOC crew hunt down rogue devices of various kinds... >> >> no objection to "can automatically"..... > > 'can' implies they might not, which would be bad (consider bridges that > refused to participate in spanning tree). My worry is the end-user PC that attaches to an rbridge, calls itself an rbridge, and injects fake mappings for another PC in order to deny service to someone he doesn't like. Or perhaps sniff/modify the traffic ala "dsniff". I guess you could do the same thing with spanning tree.... the defense is probably to let the bridges distinguish between "core ports" and "user ports" - but then we're out of the "automatic" configuration space again.... Harald, paranoid. Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9C6JDL23090; Tue, 11 Oct 2005 23:19:14 -0700 (PDT) Message-ID: <434CAADB.4050204@isi.edu> Date: Tue, 11 Oct 2005 23:19:07 -0700 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> References: <434C5CF4.2050808@isi.edu> <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> In-Reply-To: <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0AC5C4A321491B37DBF5C56A" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 06:20:25 -0000 Status: RO Content-Length: 1718 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0AC5C4A321491B37DBF5C56A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > --On tirsdag, oktober 11, 2005 17:46:44 -0700 Joe Touch <touch@ISI.EDU> > wrote: > > >>RBridges are layer-2 devices that automatically aggregate into a virtual >>device that emulates a single bridge on a conventional 802.1 Ethernet. > > > question: is the "automatically" part necessary & sufficient? I thought so, in the same sense that bridges automatically aggregate into a single spanning tree. > somehow I get this awful feeling when I see a disruption-sensitive > infrastructure that devices can "automatically" join..... too many IETFs > watching NOC crew hunt down rogue devices of various kinds... > > no objection to "can automatically"..... 'can' implies they might not, which would be bad (consider bridges that refused to participate in spanning tree). >>This document describes the need >>for RBridges and describes situations where it will be useful. > > nit: singular/plural mismatch (or I parsed the sentence incorrectly) Nope - thanks for the catch. Joe --------------enig0AC5C4A321491B37DBF5C56A 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDTKrbE5f5cImnZrsRApuAAKD23+YhTsk8MhsLgvVy3p1tI+tB8gCgvCqy eNPD+M93WNVgedvpBQpd5+U= =+bB3 -----END PGP SIGNATURE----- --------------enig0AC5C4A321491B37DBF5C56A-- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9C5vAL18293 for <rbridge@postel.org>; Tue, 11 Oct 2005 22:57:11 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 160272596BD for <rbridge@postel.org>; Wed, 12 Oct 2005 07:56:41 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09720-10 for <rbridge@postel.org>; Wed, 12 Oct 2005 07:56:37 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id B967E2596B9 for <rbridge@postel.org>; Wed, 12 Oct 2005 07:56:36 +0200 (CEST) Date: Wed, 12 Oct 2005 07:57:04 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <ED65AC84A9431D0D0667C1C3@gloppen.hjemme.alvestrand.no> In-Reply-To: <434C5CF4.2050808@isi.edu> References: <434C5CF4.2050808@isi.edu> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 05:57:44 -0000 Status: RO Content-Length: 716 --On tirsdag, oktober 11, 2005 17:46:44 -0700 Joe Touch <touch@ISI.EDU> wrote: > > RBridges are layer-2 devices that automatically aggregate into a virtual > device that emulates a single bridge on a conventional 802.1 Ethernet. question: is the "automatically" part necessary & sufficient? somehow I get this awful feeling when I see a disruption-sensitive infrastructure that devices can "automatically" join..... too many IETFs watching NOC crew hunt down rogue devices of various kinds... no objection to "can automatically"..... > This document describes the need > for RBridges and describes situations where it will be useful. nit: singular/plural mismatch (or I parsed the sentence incorrectly) Received: from [128.9.176.128] (ras28.isi.edu [128.9.176.128]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9C349L12927; Tue, 11 Oct 2005 20:04:09 -0700 (PDT) Message-ID: <434C7D28.8070906@isi.edu> Date: Tue, 11 Oct 2005 20:04:08 -0700 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> References: <200510112125.j9BLPout011190@lion.seas.upenn.edu> <434C3537.6000101@sun.com> <434C3EE6.1000405@isi.edu> <434C732B.4050304@sun.com> In-Reply-To: <434C732B.4050304@sun.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCE65287A22FCEBDD3941C49A" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 03:04:52 -0000 Status: RO Content-Length: 3980 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCE65287A22FCEBDD3941C49A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Radia Perlman wrote: ... > But I'm trying to explain a topology in which RBridges *will* do something. That > is when the topology, if you halted all the RBridges, *is* partitioned. So assume > you have replaced enough bridges with (for now halted) RBridges, so the world > is partitioned into 5 pieces. AOK - I was thinking of this in particular for the applicability part of the problem/applicability statement. The catch is that this is going to be less useful if this is required but cannot be detected or encouraged somehow. ... > Now let's turn on the RBridges, and let them do their thing. > > Each of the pieces looks to the RBridges like a single link. The > RBridges don't see the difference between > a single Ethernet segment, or a bridged Ethernet segment. Just like > routers don't see the bridges. You've said here and before that the rbridge looks like a router - but it does not, because routers have ethernet addresses and source and sink packets. Routers and hosts are just nodes on a ethernet segment, nodes that have 802 addresses. Now if the rbridge has an 802 address, then we have a big problem about how to cross the rbridge and come out the right place - we need to do proxy ARP on all the external links, we need to rewrite the packets we receive, and we potentially pollute the ARP caches of nodes on the links that then move elsewhere in the system. So we need to have some other analogy - e.g., it's a bridge that blocks BPDUs. Back to the key question... ... >>Those links can touch the rbridge in multiple places - there's no reason >>they necessarily connect to a single port. > > What happens if an RBridge has two ports onto what it sees as the same > "link" is that only one of > the ports winds up Designated. So an RBridge will not decapsulate a > packet onto port i and then > pick it up and encapsulate it on port j, if the RBridge things that port > i and port j are the same link, > which it will, if port i and j are connected through a path of bridges. OK. I'm understanding the trick -maybe. Basically, there's effectively a phantom spanning tree inside the rbridge. You just made one by saying there's exactly one 'designated' port. So I *can* think of this as one big bridge. One that has internal logic that makes sure that it touches each spanning tree it sees externally in one place (isn't that what spanning tree does?) and then ends up acting like a terminus on each spanning tree (again, what spanning tree does). So although BPDUs aren't forwarded, the net effect of a spanning tree is retained. So maybe (***here's the interesting point, IMO - if I understand this now***) this also works for bridges. They don't strictly need to forward BPDUs either (by analogy). All they need to do is act sufficiently like an rbridge campus and things will work - and the spanning trees will be partitioned. Can anyone explain to me why this won't work with a regular bridge if we built it? And if it did, wouldn't it make the spanning trees a LOT simpler at the edges? All we have to do is make sure these 'magic bridges' are deployed in ways that partition the existing bridges into non-connected stubs - which we have to figure a way to do with rbridges too. So does that work? (and if so, has anybody tried it?) Joe --------------enigCE65287A22FCEBDD3941C49A 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDTH0oE5f5cImnZrsRAqG6AJ9ZqLXoJHK4X/hJw/58SDn6Sf8DoQCgs7N/ a/6me4EZBq1f2udFoUjU1aM= =jTBW -----END PGP SIGNATURE----- --------------enigCE65287A22FCEBDD3941C49A-- 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 j9C2LcL03928 for <rbridge@postel.org>; Tue, 11 Oct 2005 19:21:38 -0700 (PDT) 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 <0IO800HCF6JXXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 19:21:33 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO800HN16JT1610@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 19:21:31 -0700 (PDT) Date: Tue, 11 Oct 2005 19:21:31 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <434C3EE6.1000405@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C732B.4050304@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: <200510112125.j9BLPout011190@lion.seas.upenn.edu> <434C3537.6000101@sun.com> <434C3EE6.1000405@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: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 02:21:51 -0000 Status: RO Content-Length: 4980 Re: Joe's comments about my scenario (first saying that replacing some bridges with RBridges may not partition the campus, which is true but not relevant to the point I was making, and second saying that RBridges have to join in the bridge spanning tree or else there will be loops, which is not true, and it's important that we all understand that). ********************** There's confusion here. Sorry if I'm not explaining properly. Let's start over again with the steps I was saying: You start with one giant bridged campus. There is one spanning tree. Then you replace some of the bridges with RBridges. Pretend that the RBridges don't forward ANY packets. Now the campus is likely partitioned into several pieces, let's say 5, with no connectivity between the pieces. *********** Perhaps you are quibbling with "likely partitioned". If the topology is such that the particular bridges you've replaced with RBridges doesn't partition things, then you will wind up with what looks to the RBridges like they are all connected to the same link. One port of one will get elected Designated RBridge. But it won't *do* anything. It won't decapsulate or encapsulate or forward any data packets. It will just sit there unless there is another "link" in the topology. But all the RBridges just see a single link. Even if they have multiple ports onto the same link. But I'm trying to explain a topology in which RBridges *will* do something. That is when the topology, if you halted all the RBridges, *is* partitioned. So assume you have replaced enough bridges with (for now halted) RBridges, so the world is partitioned into 5 pieces. ************** Back to the story I was telling. To reiterate, you've either partitioned things, or you haven't. If you haven't, then the RBridges aren't doing anything. The bridges will all compute a single spanning tree that connects all the segments that the RBridges see, so all the RBridges see is the simple topology of them all connecting to a single link, and as I said, they won't be forwarding any data packets. The only thing they'll be doing is transmitting LSPs and Hello messages. But none of them will forward anything. That's not a very interesting topology. Let's get on to what happens in the interesting case. So now let's assume you have managed to partition the campus. Then let's continue with what I was saying: ************* The bridges in each partition compute their own spanning tree, with their own Root bridge. The different spanning trees will not see each other, and will not merge (because we've said the RBridges are not forwarding the BPDUs). Now let's turn on the RBridges, and let them do their thing. Each of the pieces looks to the RBridges like a single link. The RBridges don't see the difference between a single Ethernet segment, or a bridged Ethernet segment. Just like routers don't see the bridges. So now we can ignore the bridges, and think of a topology consisting of 5 links, and a bunch of RBridges connecting the links. Some of the RBridges might have multiple ports onto the same link. Now the RBridges are similar to routers, where they compute optimal paths between each other, over those "links". Everything works, just as it works to have routers connected in an arbitrary topology over an arbitrary set of links. *************** I hope I'm making things clearer... Radia Now you (Joe) said: >Those links can touch the rbridge in multiple places - there's no reason >they necessarily connect to a single port. > What happens if an RBridge has two ports onto what it sees as the same "link" is that only one of the ports winds up Designated. So an RBridge will not decapsulate a packet onto port i and then pick it up and encapsulate it on port j, if the RBridge things that port i and port j are the same link, which it will, if port i and j are connected through a path of bridges. It is most definitely the case that RBridges do not participate in, nor do they need to participate in, the bridge spanning tree protocol. They need to have a forwarding entry for the multicast address on which the BPDUs are sent, to *not forward* packets sent to that multicast address. Radia > While this is OK for the >rbridge egress (it picks one designated rbridge on that link to send >things out), it's entirely possible that a broadcast will end up cycling >back over that link to another ingress port. > >That's why the rbridge needs to be in the spanning tree protocol. >Otherwise the 'links' outside can loop back onto the rbridge. > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk >UPKxoEu4qB+tJlVtDS8ylRo= >=wc2h >-----END PGP SIGNATURE----- >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > 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 j9C0mgL13499; Tue, 11 Oct 2005 17:48:42 -0700 (PDT) Message-ID: <434C5CF4.2050808@isi.edu> Date: Tue, 11 Oct 2005 17:46:44 -0700 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] seeking input on abstract for problem and applicability statement 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, 12 Oct 2005 00:50:13 -0000 Status: RO Content-Length: 1407 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's a proposed abstract. Thoughts appreciated. Joe - ----- RBridges are layer-2 devices that automatically aggregate into a virtual device that emulates a single bridge on a conventional 802.1 Ethernet. (I had thought that was a concise description, but with recent discussion about non-participation in some bridge protocols, I'm not sure. I still think the rbridge MUST participate in order to avoid loops, but if that's contentious it can't be part of the abstract yet...) They combine layer 2?s ability to allow hosts to reattach without renumbering with layer 3?s routing benefits. RBridges use existing link state routing to provide higher internal cross-section bandwidth, faster convergence under reconfiguration, and more robustness to link interruption than an equivalent set of conventional bridges using existing spanning tree forwarding. They are intended to apply to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as well. This document describes the need for RBridges and describes situations where it will be useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTFz0E5f5cImnZrsRAh/nAKCbhP6eVoNCX97zC9/L2zT0WXq9rQCdHBz/ j6oUNPt5Rmv657FhszmCZzg= =EpCS -----END PGP SIGNATURE----- Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9C0AUL02015 for <rbridge@postel.org>; Tue, 11 Oct 2005 17:10:30 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2005 17:10:26 -0700 X-IronPort-AV: i="3.97,202,1125903600"; d="scan'208"; a="350917992:sNHT22719864" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9C0AJ8k028421 for <rbridge@postel.org>; Tue, 11 Oct 2005 17:10:19 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9C0ANSI027408 for <rbridge@postel.org>; Tue, 11 Oct 2005 17:10:23 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9C0ANWC027404; Tue, 11 Oct 2005 17:10:23 -0700 Date: Tue, 11 Oct 2005 17:10:23 -0700 Message-Id: <200510120010.j9C0ANWC027404@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <434C2166.1020309@sun.com> (message from Radia Perlman on Tue, 11 Oct 2005 13:32:38 -0700) References: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> <200510112012.j9BKCoRY020573@dino-lnx.cisco.com> <434C2166.1020309@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 12 Oct 2005 00:10:42 -0000 Status: RO Content-Length: 687 >> As for providing glue to two broadcast domains in order to merge >> them...yes, an RBridged "campus" >> could be used to tunnel packets from the two broadcast domains in order >> to merge them. Yes, agree. >> But in general an RBridge would not forward a native BPDU. It would >> recognize it as something >> it shouldn't forward. Because RBridges intend to make the spanning trees So we have to put special checks in the hardware forwarding plane? I would rather not put this in the architecture and just document that bridges should not send BPDUs on links where rBridges exist. Just like bridges don't generally send BPDUs on host ports today. Dino Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BNfsL24269 for <rbridge@postel.org>; Tue, 11 Oct 2005 16:41:54 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2005 16:41:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9BNfL9S006401 for <rbridge@postel.org>; Tue, 11 Oct 2005 16:41:47 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 16:41:45 -0700 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: Tue, 11 Oct 2005 16:41:44 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD68D4@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOt/n5RJ+JfoQcRGOsGAYTU7u9agABPETw From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 23:41:45.0608 (UTC) FILETIME=[57248880:01C5CEBD] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BNfsL24269 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 23:43:01 -0000 Status: RO Content-Length: 7884 Eric, Notice that in my example below, I am only talking about broadcast connectivity - not unicast. There is not MAC advertisements for broadcast. A broadcast must go to every edge port. In this case, a spanning tree must exist (across both the RBridge and 802.1d bridged network) or a broadcast loop will occur. - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric Sent: Tuesday, October 11, 2005 3:45 PM To: 'Developing a hybrid router/bridge.' Subject: Re: [rbridge] loops in trill networks Larry, You have to think of bridges and RBridges as existing at two layers. How frames are forwarded between RBridges will be determined by shortest path computation based on MAC advertisements in IS-IS. How frames are forwarded across 802.1 bridges between RBridges is based on STP. -- E --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Larry Kreeger (kreeger) --> Sent: Tuesday, October 11, 2005 5:08 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> Radia, --> --> How about the case where the two ports connected to the same bridged --> domain are on different RBridges? --> --> Consider, the following topology where A,B,C are hosts. --> --> A--RB1--Bridged-Domain--RB2--B --> | --> | --> RB3--C --> --> In this case, would all RB's forward a L2 broadcast to their --> respective edge ports? I was assuming, yes. If so, then RB1,RB2 --> and --> RB3 are all --> designated RBs in order to have broadcast connectivity between --> A,B,C. --> --> Now a new RB4 is added to the topology which connects RB1 and RB3, --> --> A--RB1--Bridged-Domain--RB2--B --> | | --> | | --> D--RB4-------RB3--C --> --> Are you saying that RB1 and RB3 detect that they now have new --> connectivity and battle to be a Designated RB to serve their side of --> the network? Assuming RB3 wins, all broadcasts must enter and leave --> the Bridged-Domain via RB3 to get between hosts A,C,D and B. --> RB2 must still --> be the Designated RB for traffic to reach B. --> --> I didn't think routers needed to deal with this since they don't --> forward broadcasts. Are you saying that routing protocols already --> deal with these types of scenarios? --> --> Thanks, Larry --> --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> Sent: Tuesday, October 11, 2005 12:46 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> The intention is that deployment not have to be careful. If two of --> an RBridge's ports are connected to the same bridged broadcast --> domain (i.e., there is a bridge-connected path between the two --> ports), then the RBridge will think it has two ports connected to --> the same link. Which is OK. --> It won't forward any packets, including not BPDUs, between those --> ports. --> At most one of --> its ports will become "designated" for sourcing/sinking --> unencapsulated traffic to/from that link. --> --> It would be just like a router having two ports connected to the --> same link, which should work with no problem. --> --> Radia --> --> --> --> Gray, Eric wrote: --> --> >Radia, --> > --> > If I am understanding what you are saying correctly, there are --> some --> >deployment issues with Rbridges into a 802.1 bridged environment. --> > --> > The deployment issues arise when individual RBridges are --> installed, if --> >this is not carefully planned in advance. --> >If an Rbridge is installed on a link where it is connected --> to two or --> >more 802.1 bridges and there is another L2 path between those two --> >bridges, the RBridge will either have to forward BPDUs or - like a --> >router - recognize that multiple ports are connected to --> the same LAN. --> > --> > Is there an intention that the latter would be the default case --> until --> >and unless the installed RBridge is able to discover a connected --> >RBridge peer? --> > --> >-- --> >Eric Gray --> > --> >--> -----Original Message----- --> >--> From: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org]On --> >--> Behalf Of Radia Perlman --> >--> Sent: Tuesday, October 11, 2005 12:44 PM --> >--> To: Developing a hybrid router/bridge. --> >--> Subject: Re: [rbridge] loops in trill networks --> >--> --> >--> --> >--> There's nothing an RBridge can do about loops --> consisting of just --> >--> bridges. --> >--> Which is why it's good to partition the spanning trees --> formed by --> >--> the bridges so that the remaining spanning trees are --> as small, and --> >--> therefore as stable, as possible. --> >--> --> >--> RBridges are like routers. They sit at a layer above --> bridges. The --> >--> bridges form what looks like a single link to the RBridges. If --> >--> there are a bunch of bridges connecting a bunch of --> segments, all --> >--> the RBridges attached to that portion of the network see that --> >--> bridged segment as a single link. --> >--> --> >--> Radia --> >--> --> >--> Loa Andersson wrote: --> >--> --> >--> >Oh, yes it is true ... --> >--> > --> >--> >but I thought that a trill network could consist of a --> mixed of --> >--> >rbridges and the type of bridges that exist today, if --> that is the --> >--> >case you can possibly form the loop over only non-rbridges --> >--> > --> >--> >but I'm not up to speed on this, there might be a way --> to handle --> >--> >this also --> >--> > --> >--> >/Loa --> >--> > --> >--> >Joe Touch wrote: --> >--> > --> >--> > --> >--> >>There is, and that's what it's there for. --> >--> >> --> >--> >>Joe --> >--> >> --> >--> >>Mike Hughes wrote: --> >--> >> --> >--> >> --> >--> >> --> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> --> wrote: --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>>>this might be an old discussion, but it is some --> time since it --> >--> >>>>look at it. What do we do in trill networks about --> transient --> >--> >>>>loops, i.e. if use link state protocols there is a --> possibility --> >--> >>>>that we have transient loops. With no TTL mechanisms --> >--> those looping --> >--> >>>>frames could cause quite a bit of problem. --> >--> >>>> --> >--> >>>> --> >--> >>>Unless I've missed something, or things have changed --> >--> overnight, there is a --> >--> >>>TTL provided in the SHIM header. --> >--> >>> --> >--> >>>Mike --> >--> >>> --> >--> >>> --> >--> >>>--------------------------------------------------------- --> >--> --------------- --> >--> >>> --> >--> >>>_______________________________________________ --> >--> >>>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 --> _______________________________________________ --> 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 j9BMioL05205 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:44:50 -0700 (PDT) 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 j9BMijUk027155 for <rbridge@postel.org>; Tue, 11 Oct 2005 18:44:45 -0400 (EDT) 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 SAA05687 for <rbridge@postel.org>; Tue, 11 Oct 2005 18:44:44 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPD75H>; Tue, 11 Oct 2005 19:44:44 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F62@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, 11 Oct 2005 19:44:35 -0300 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] loops in trill networks 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, 11 Oct 2005 22:46:15 -0000 Status: RO Content-Length: 7232 Larry, You have to think of bridges and RBridges as existing at two layers. How frames are forwarded between RBridges will be determined by shortest path computation based on MAC advertisements in IS-IS. How frames are forwarded across 802.1 bridges between RBridges is based on STP. -- E --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Larry Kreeger (kreeger) --> Sent: Tuesday, October 11, 2005 5:08 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> Radia, --> --> How about the case where the two ports connected to the same bridged --> domain are on different RBridges? --> --> Consider, the following topology where A,B,C are hosts. --> --> A--RB1--Bridged-Domain--RB2--B --> | --> | --> RB3--C --> --> In this case, would all RB's forward a L2 broadcast to --> their respective --> edge ports? I was assuming, yes. If so, then RB1,RB2 and --> RB3 are all --> designated RBs in order to have broadcast connectivity --> between A,B,C. --> --> Now a new RB4 is added to the topology which connects RB1 and RB3, --> --> A--RB1--Bridged-Domain--RB2--B --> | | --> | | --> D--RB4-------RB3--C --> --> Are you saying that RB1 and RB3 detect that they now have new --> connectivity and battle to be a Designated RB to serve --> their side of the --> network? Assuming RB3 wins, all broadcasts must enter and leave the --> Bridged-Domain via RB3 to get between hosts A,C,D and B. --> RB2 must still --> be the Designated RB for traffic to reach B. --> --> I didn't think routers needed to deal with this since they --> don't forward --> broadcasts. Are you saying that routing protocols already deal with --> these types of scenarios? --> --> Thanks, Larry --> --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Radia Perlman --> Sent: Tuesday, October 11, 2005 12:46 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> The intention is that deployment not have to be careful. If --> two of an --> RBridge's ports are connected to the same bridged broadcast domain --> (i.e., there is a bridge-connected path between the two --> ports), then the --> RBridge will think it has two ports connected to the same --> link. Which is --> OK. --> It won't forward any packets, including not BPDUs, between --> those ports. --> At most one of --> its ports will become "designated" for sourcing/sinking --> unencapsulated --> traffic to/from that link. --> --> It would be just like a router having two ports connected --> to the same --> link, which should work with no problem. --> --> Radia --> --> --> --> Gray, Eric wrote: --> --> >Radia, --> > --> > If I am understanding what you are saying correctly, there are --> some --> >deployment issues with Rbridges into a 802.1 bridged environment. --> > --> > The deployment issues arise when individual RBridges are --> installed, if --> >this is not carefully planned in advance. --> >If an Rbridge is installed on a link where it is connected --> to two or --> >more 802.1 bridges and there is another L2 path between those two --> >bridges, the RBridge will either have to forward BPDUs or - like a --> >router - recognize that multiple ports are connected to --> the same LAN. --> > --> > Is there an intention that the latter would be the default case --> until --> >and unless the installed RBridge is able to discover a connected --> >RBridge peer? --> > --> >-- --> >Eric Gray --> > --> >--> -----Original Message----- --> >--> From: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org]On --> >--> Behalf Of Radia Perlman --> >--> Sent: Tuesday, October 11, 2005 12:44 PM --> >--> To: Developing a hybrid router/bridge. --> >--> Subject: Re: [rbridge] loops in trill networks --> >--> --> >--> --> >--> There's nothing an RBridge can do about loops --> consisting of just --> >--> bridges. --> >--> Which is why it's good to partition the spanning trees --> formed by --> >--> the bridges so that the remaining spanning trees are --> as small, and --> >--> therefore as stable, as possible. --> >--> --> >--> RBridges are like routers. They sit at a layer above --> bridges. The --> >--> bridges form what looks like a single link to the RBridges. If --> >--> there are a bunch of bridges connecting a bunch of --> segments, all --> >--> the RBridges attached to that portion of the network see that --> >--> bridged segment as a single link. --> >--> --> >--> Radia --> >--> --> >--> Loa Andersson wrote: --> >--> --> >--> >Oh, yes it is true ... --> >--> > --> >--> >but I thought that a trill network could consist of a --> mixed of --> >--> >rbridges and the type of bridges that exist today, if --> that is the --> >--> >case you can possibly form the loop over only non-rbridges --> >--> > --> >--> >but I'm not up to speed on this, there might be a way --> to handle --> >--> >this also --> >--> > --> >--> >/Loa --> >--> > --> >--> >Joe Touch wrote: --> >--> > --> >--> > --> >--> >>There is, and that's what it's there for. --> >--> >> --> >--> >>Joe --> >--> >> --> >--> >>Mike Hughes wrote: --> >--> >> --> >--> >> --> >--> >> --> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> --> wrote: --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>> --> >--> >>>>this might be an old discussion, but it is some --> time since it --> >--> >>>>look at it. What do we do in trill networks about --> transient --> >--> >>>>loops, i.e. if use link state protocols there is a --> possibility --> >--> >>>>that we have transient loops. With no TTL mechanisms --> >--> those looping --> >--> >>>>frames could cause quite a bit of problem. --> >--> >>>> --> >--> >>>> --> >--> >>>Unless I've missed something, or things have changed --> >--> overnight, there is a --> >--> >>>TTL provided in the SHIM header. --> >--> >>> --> >--> >>>Mike --> >--> >>> --> >--> >>> --> >--> >>>--------------------------------------------------------- --> >--> --------------- --> >--> >>> --> >--> >>>_______________________________________________ --> >--> >>>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 --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> 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 j9BMeSL03198; Tue, 11 Oct 2005 15:40:28 -0700 (PDT) Message-ID: <434C3EE6.1000405@isi.edu> Date: Tue, 11 Oct 2005 15:38:30 -0700 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> References: <200510112125.j9BLPout011190@lion.seas.upenn.edu> <434C3537.6000101@sun.com> In-Reply-To: <434C3537.6000101@sun.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 22:40:51 -0000 Status: RO Content-Length: 1969 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radia Perlman wrote: > Let me try explaining it a different way. > > You start with one giant bridged campus. There is one spanning tree. > > Then you replace some of the bridges with RBridges. > > Pretend that the RBridges don't forward ANY packets. > > Now the campus is likely partitioned into several pieces, let's say 5, > with no connectivity > between the pieces. That's not necessarily likely. That would only occur if the network were wired as a spanning tree; if we could expect that, we wouldn't need to generate one. I.e., it's more likely that such partitioning might not occur - however, the rbridge system might not provide a benefit in those cases. AFAICT, an rbridge helps only where it does partition the bridges as above. Let's thus assume that's the case, as engineered: > Each piece computes its own spanning tree, with its own Root bridge. So you > have 5 independent, disconnected spanning trees. > > Now think of each of those 5 pieces as a single link. The fact that each > piece > is glued together with spanning tree with bridges is invisible outside > that piece. So we > can stop thinking about bridges, and now only look at the next layer > up...the RBridges. Those links can touch the rbridge in multiple places - there's no reason they necessarily connect to a single port. While this is OK for the rbridge egress (it picks one designated rbridge on that link to send things out), it's entirely possible that a broadcast will end up cycling back over that link to another ingress port. That's why the rbridge needs to be in the spanning tree protocol. Otherwise the 'links' outside can loop back onto the rbridge. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk UPKxoEu4qB+tJlVtDS8ylRo= =wc2h -----END PGP SIGNATURE----- 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 j9BMbAL01593 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:37:10 -0700 (PDT) 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 j9BMb4Uk027081 for <rbridge@postel.org>; Tue, 11 Oct 2005 18:37:05 -0400 (EDT) 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 SAA04975 for <rbridge@postel.org>; Tue, 11 Oct 2005 18:37:04 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPD7TP>; Tue, 11 Oct 2005 19:37:04 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F61@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, 11 Oct 2005 19:36:58 -0300 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] loops in trill networks 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, 11 Oct 2005 22:37:45 -0000 Status: RO Content-Length: 2130 I think what Radia is saying is that RBridges do not participate (originate or forward) BPDUs. In addition, an RBridge that determines it has more than one port in the same LAN/Broadcast domain does not forward between those ports. It does not need to directly participate in STP to know this and this behavior will prevent loop behavior. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Joe Touch --> Sent: Tuesday, October 11, 2005 5:02 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> -----BEGIN PGP SIGNED MESSAGE----- --> Hash: SHA1 --> --> --> --> Gray, Eric wrote: --> > Larry, --> > --> > You've got the sense of Radia's reply reversed. It's the --> > 802.1 bridges that look like a single link to the RBridges. --> > --> > This is pretty much how I expected this to work. A cloud --> > of 802.1 bridges MUST be completely enclosed in either RBridges --> > or routers. --> --> I was expecting that to say "or there will be little or no --> benefit from --> the rbridges" - i.e., topology restrictions can't be --> enforced per se if --> we're expecting plug-and-play. --> --> > Rbridges - like routers - do not forward BPDUs. --> --> Let me propose a question. Let's say an rbridge campus looks like a --> single giant bridge (humor me). --> --> There are two cases: --> --> - the bridge participates in BPDU --> --> - the bridge does not participate in BPDU --> --> Is it possible in existing systems to have a bridge that does not --> participate in BPDU? Wouldn't this end up creating loops? --> --> Joe --> -----BEGIN PGP SIGNATURE----- --> Version: GnuPG v1.2.4 (MingW32) --> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org --> --> iD8DBQFDTChhE5f5cImnZrsRAkAqAKCrkBhoqAYQsRB1/W1OlhWtuOlg0QCgyfj7 --> +kCndWeVdgjyigTPYUF4U3Y= --> =wt7Z --> -----END PGP SIGNATURE----- --> _______________________________________________ --> 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 j9BMNwL26711 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:23:58 -0700 (PDT) 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 j9BMNYUk026954 for <rbridge@postel.org>; Tue, 11 Oct 2005 18:23:37 -0400 (EDT) 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 SAA04069 for <rbridge@postel.org>; Tue, 11 Oct 2005 18:23:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPD7L2>; Tue, 11 Oct 2005 19:23:33 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F60@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, 11 Oct 2005 19:23:29 -0300 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] loops in trill networks 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, 11 Oct 2005 22:24:44 -0000 Status: RO Content-Length: 3378 Larry, During a bridge-level topology change, bridges only deal with BPDUs. Other traffic is held up until the ST is determined. Otherwise, traffic in a bridged network would be out of control and stay out of control. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Larry Kreeger (kreeger) --> Sent: Tuesday, October 11, 2005 4:45 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> Joe, --> --> The context was that during a topology change, there could be a --> temporary loop. While this temporary loop exists, --> multicast/broadcasts --> would duplicate to edge ports each time they came around - --> until the TTL --> reaches its limit. --> --> - Larry --> --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Joe Touch --> Sent: Tuesday, October 11, 2005 1:02 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> -----BEGIN PGP SIGNED MESSAGE----- --> Hash: SHA1 --> --> --> --> Larry Kreeger (kreeger) wrote: --> > OK, I can see how a TTL will stop loops, and would --> prevent duplicate --> > known unicasts from being delivered, but how does a TTL stop --> > broadcast/multicast/unknown unicast frames from being --> duplicated to --> > edge ports each time the frame comes round the loop? --> --> The multicast/broadcast packets are forwarded by one or --> more spanning --> trees. There should never be loops in those anyway as a result. --> --> Joe --> --> > Or is this considered --> > OK behavior in an RBridge network compared to an 802.1 bridged --> network? --> > --> > New to all this... - Larry --> > --> > -----Original Message----- --> > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 7:07 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > There is, and that's what it's there for. > > Joe > > Mike Hughes wrote: > >>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >> >> >> >>>this might be an old discussion, but it is some time since it look at >>>it. What do we do in trill networks about transient loops, i.e. if >>>use > > >>>link state protocols there is a possibility that we have transient >>>loops. With no TTL mechanisms those looping frames could cause quite >>>a > > >>>bit of problem. >> >> >>Unless I've missed something, or things have changed overnight, there >>is a TTL provided in the SHIM header. >> >>Mike > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTBpUE5f5cImnZrsRAk2EAKDUBLgyz1duwtVTZyrUE8t++Z381wCdFW4L OG6Pao5gsla9YrMI+qEdiNA= =dTLU -----END PGP SIGNATURE----- _______________________________________________ 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 sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BMM1L26155 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:22:01 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2005 15:21:56 -0700 X-IronPort-AV: i="3.97,202,1125903600"; d="scan'208"; a="350872885:sNHT34977088" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9BMLRv3017880 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:21:54 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 15:21:49 -0700 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: Tue, 11 Oct 2005 15:21:48 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD6844@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOruGeneDVD3aNT96QGDtb6ayvIgAAaG9w From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 22:21:49.0420 (UTC) FILETIME=[2C6452C0:01C5CEB2] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BMM1L26155 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 22:22:44 -0000 Status: RO Content-Length: 2986 Radia, I agree that loops happen within 802.1d bridged networks due to circumstances such as misconfiguration, HW bugs, SW bugs etc, and that these tend to cause the network to melt down. This is why a TTL is a good thing, and I have no objection to it. However, I'd like to separate out meltdown behavior (which is driven by events which happen less often), and temporary loops which can be caused by much more commonplace events (link up/down). In the case of simple link up/down events, 802.1d networks don't duplicate unicast frames. If we are calculating the RBridge bcast/mcast/unknown spanning tree using IS-IS, then unknown unicasts will get duplicated in some topologies. If this is deemed acceptable behavior for an RBridge network, it should be documented as a known behavior. If this causes problems for some protocols, users will be able to choose to either fix the protocol or not use RBridges. If it is not deemed acceptable behavior, then it should be fixed. I'm just trying to point out what I see as difference between the two technologies as defined. - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Tuesday, October 11, 2005 2:48 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks There was never a "guarantee" in STP that there not be loops. STP attempted to avoid them by waiting before turning ports on. RSTP, instead of waiting before turning on ports, attempts to avoid loops by using local information to turn some links on while turning others off. Although it's certainly good to try to avoid temporary loops, it's never possible to *guarantee* no temporary loops. These can be caused by misconfiguration (someone claiming a port will only have endnodes, whereas it actually does get connected to a switch), by bringing up a repeater, or having enough consecutive BPDUs lost for whatever reason (congestion on the link causing packets to not reach a bridge, or the bridge not being able to keep up with worst case wire speed). The thing that got me interested in this again is finding out that bridge meltdowns (due to temporary loops) do occur, and apparently with increasing frequency with new features that have been added to bridges that involve configuration that can be disastrous if set incorrectly, or with bridges deployed that can't keep up with wire speeds. So the idea is that although it's certainly good to try to avoid temporary loops, we want to make it not a disaster if they do occur. Radia Larry Kreeger (kreeger) wrote: >Joe, > >As far as I know, all variations of STP guaranteed that bridged >networks never have temporary loops, so existing bridges never have this problem. >If they did, then I'd agree that it is no different. > > - Larry > > > > _______________________________________________ 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 j9BMIbL25026 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:18:37 -0700 (PDT) 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 <0IO700H6GVAWXX00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 15:18:32 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700H2NVAV1610@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 15:18:32 -0700 (PDT) Date: Tue, 11 Oct 2005 15:18:33 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <582968a0510111453t409ccb66mac23f3e9903e56d@mail.gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C3A39.8010309@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <mailman.1.1128798001.23832.rbridge@postel.org> <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> <434C0C4D.6020904@sun.com> <582968a0510111453t409ccb66mac23f3e9903e56d@mail.gmail.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] rbridge Digest, Vol 17, Issue 5 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, 11 Oct 2005 22:19:11 -0000 Status: RO Content-Length: 3997 Actually, Stephen, you are right. The possibility you mention was also considered, and I left it off that list below. If I remember correctly, I think people didn't like it because it made the shim header larger on every packet, and it required learning while forwarding data packets. The arguments for it, though, are that inactive endnodes don't occupy space, and there's no explicit protocol necessary for learning endnode information. Perhaps there wasn't consensus on dropping that possibility. It would be good to restart a thread (with a subject line more descriptive than "rbridge Digest, Vol 17, Issue 5" probably), specifically just on this one issue...possibilities for learning endnode information, that has at least the three choices I put in below, plus the one Stephen added, which is to have both ingress and egress RBridges in the shim header, and have either all RBridges that forward the encapsulated packet, or just the egress RBridge, learn the mapping of (ingress RBridge, source MAC) for that packet. Radia ******************* Stephen Suryaputra wrote: On 10/11/05, *Radia Perlman* <Radia.Perlman@sun.com <mailto:Radia.Perlman@sun.com>> wrote: So...how should VLAN A endnode membership be passed around? There are various choices: a) in one instance of IS-IS, along with the RBridge topology information b) have an instance of IS-IS per VLAN, just for passing around the endnode information for that VLAN. This would be a fairly trivial subset of IS-IS, because there is no forwarding of link state information. The VLAN A instance of IS-IS would use the VLAN A broadcast domain created by the main IS-IS instance, to have each RBridge in VLAN A announce its directly attached VLAN A endnodes c) have some other protocol, simpler than IS-IS (because link state information never needs to be forwarded), that just sends out endnode information. This may have been discussed before. Since the first packet will go through the spanning tree due to multicast/broadcast/unknown, why not the shim header contain both ingress and egress Rbridge and let the egress Rbridge learn the original L2 source address to ingress Rbridge mapping (the same as bridge learning today with aging timer)? Rbridges on the path that are connected to the same VLAN can use the same information. Stephen. Stephen Suryaputra wrote: > > > On 10/11/05, *Radia Perlman* <Radia.Perlman@sun.com > <mailto:Radia.Perlman@sun.com>> wrote: > > > So...how should VLAN A endnode membership be passed around? There are > various choices: > a) in one instance of IS-IS, along with the RBridge topology > information > b) have an instance of IS-IS per VLAN, just for passing around the > endnode information for that VLAN. > This would be a fairly trivial subset of IS-IS, because there is no > forwarding of link state information. > The VLAN A instance of IS-IS would use the VLAN A broadcast domain > created by the main > IS-IS instance, to have each RBridge in VLAN A announce its directly > attached VLAN A endnodes > c) have some other protocol, simpler than IS-IS (because link state > information never needs to be forwarded), > that just sends out endnode information. > > > This may have been discussed before. Since the first packet will go > through the spanning tree due to multicast/broadcast/unknown, why not > the shim header contain both ingress and egress Rbridge and let the > egress Rbridge learn the original L2 source address to ingress Rbridge > mapping (the same as bridge learning today with aging timer)? Rbridges > on the path that are connected to the same VLAN can use the same > information. > > Stephen. > >------------------------------------------------------------------------ > >_______________________________________________ >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 j9BM5eL19775 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:05:40 -0700 (PDT) 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 <0IO700H6KUPAXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 15:05:34 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700H0IUPA1610@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 15:05:34 -0700 (PDT) Date: Tue, 11 Oct 2005 15:05:35 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9DD6802@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C372F.1060700@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: <A0A653F4CB702442BFBF2FAF02C031E9DD6802@xmb-sjc-21e.amer.cisco.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] loops in trill networks 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, 11 Oct 2005 22:06:12 -0000 Status: RO Content-Length: 5700 No. When Joe said "STP" he didn't mean the good old 802.1d STP that we all know and love... instead it's a spanning tree topology calcuated from the link state database distributed by IS-IS. Radia Larry Kreeger (kreeger) wrote: >Joe, > >Sorry, but I totally missed the fact that Spanning Tree Protocol is >being used within the RBridged network! All I had seen were references >to routing protocols such as IS-IS. > >Nevermind... > > - Larry > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Joe Touch >Sent: Tuesday, October 11, 2005 2:22 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] loops in trill networks > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Larry Kreeger (kreeger) wrote: > > >>Joe, >> >>As far as I know, all variations of STP guaranteed that bridged >>networks never have temporary loops, so existing bridges never have >> >> >this problem. > > >>If they did, then I'd agree that it is no different. >> >> > >I'm confused. We are using STP for multicast/broadcast inside the >campus. Why then will that STP cause loops whereas current bridges do >not? > >Joe > > > > >> - Larry >> >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>On Behalf Of Joe Touch >>Sent: Tuesday, October 11, 2005 1:47 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] loops in trill networks >> >>Yes - but I think Radia pointed out that this is no different than how >> >> > > > >>existing bridges would behave in that circumstance. >> >>joe >> >> >>Larry Kreeger (kreeger) wrote: >> >> >> >>>>Joe, >>>> >>>>The context was that during a topology change, there could be a >>>>temporary loop. While this temporary loop exists, >>>>multicast/broadcasts would duplicate to edge ports each time they >>>>came >>>> >>>> >> >> >>>>around - until the TTL reaches its limit. >>>> >>>>- Larry >>>> >>>>-----Original Message----- >>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>On Behalf Of Joe Touch >>>>Sent: Tuesday, October 11, 2005 1:02 PM >>>>To: Developing a hybrid router/bridge. >>>>Subject: Re: [rbridge] loops in trill networks >>>> >>>> >>>> >>>>Larry Kreeger (kreeger) wrote: >>>> >>>> >>>> >>>> >>>>>>OK, I can see how a TTL will stop loops, and would prevent >>>>>>duplicate known unicasts from being delivered, but how does a TTL >>>>>>stop broadcast/multicast/unknown unicast frames from being >>>>>>duplicated to edge ports each time the frame comes round the loop? >>>>>> >>>>>> >>>>The multicast/broadcast packets are forwarded by one or more spanning >>>> >>>> > > > >>>>trees. There should never be loops in those anyway as a result. >>>> >>>>Joe >>>> >>>> >>>> >>>> >>>> >>>>>>Or is this considered >>>>>>OK behavior in an RBridge network compared to an 802.1 bridged >>>>>> >>>>>> >>>>network? >>>> >>>> >>>> >>>> >>>>>>New to all this... - Larry >>>>>> >>>>>>-----Original Message----- >>>>>>From: rbridge-bounces@postel.org >>>>>>[mailto:rbridge-bounces@postel.org] >>>>>>On Behalf Of Joe Touch >>>>>>Sent: Tuesday, October 11, 2005 7:07 AM >>>>>>To: Developing a hybrid router/bridge. >>>>>>Subject: Re: [rbridge] loops in trill networks >>>>>> >>>>>>There is, and that's what it's there for. >>>>>> >>>>>>Joe >>>>>> >>>>>>Mike Hughes wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>this might be an old discussion, but it is some time since it >>>>>>>>look at >>>>>>>> >>>>>>>> >>>> >>>> >>>>>>>>it. What do we do in trill networks about transient loops, i.e. >>>>>>>>if use >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>>>>link state protocols there is a possibility that we have >>>>>>>>transient loops. With no TTL mechanisms those looping frames >>>>>>>>could cause quite a >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>>>>bit of problem. >>>>>>>> >>>>>>>> >>>>>>>Unless I've missed something, or things have changed overnight, >>>>>>>there is a TTL provided in the SHIM header. >>>>>>> >>>>>>>Mike >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>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 >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDTCz4E5f5cImnZrsRAupAAJ9uc9RO2M6nGvzxGY5UqzjYn0OafACgimKq >R8mFDeQMzN6IdleEU574J4c= >=F6gF >-----END PGP SIGNATURE----- >_______________________________________________ >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 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 j9BLvGL16157 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:57:16 -0700 (PDT) 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 <0IO700H5OUBAXX00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 14:57:11 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HZ4UBA1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 14:57:10 -0700 (PDT) Date: Tue, 11 Oct 2005 14:57:11 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <200510112125.j9BLPout011190@lion.seas.upenn.edu> To: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C3537.6000101@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: <200510112125.j9BLPout011190@lion.seas.upenn.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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:57:44 -0000 Status: RO Content-Length: 2520 Let me try explaining it a different way. You start with one giant bridged campus. There is one spanning tree. Then you replace some of the bridges with RBridges. Pretend that the RBridges don't forward ANY packets. Now the campus is likely partitioned into several pieces, let's say 5, with no connectivity between the pieces. Each piece computes its own spanning tree, with its own Root bridge. So you have 5 independent, disconnected spanning trees. Now think of each of those 5 pieces as a single link. The fact that each piece is glued together with spanning tree with bridges is invisible outside that piece. So we can stop thinking about bridges, and now only look at the next layer up...the RBridges. Now we have a topology of 5 links all interconnected in some rich topology (not necessarily a tree) using RBridges. The RBridges run a link state IGP. They know how to reach each other via shortest paths. They might even compute multiple paths to each other. Data packets can use all the links, so the actual topology for data packet forwarding need not be loop-free. Just like routing IP packets over the same topology, if you replaced the RBridges with IP routers and gave each of the 5 segments its own IP subnet prefix. Using the link state database, the RBridges also calculate a spanning tree among themselves, in order to forward multicasts/pkts to unknown destinations. This spanning tree, when forwarded from RBridge to RBridge, might transit a bridged segment with its own spanning tree. But it's a different tree. Somehow...I'm not sure this will illuminate anything. However, 5 minutes with interactive conversation and a whiteboard and I'm sure if there were any remaining confusion it could be resolved. Radia Saikat Ray wrote: >>What I mean by "n spanning trees that do not see each other" is that the >>RBridges don't glue the >>802.1d spanning tree together into a single 802.1d spanning >>tree with one Root Bridge, etc. >> >>They do, however, create a single broadcast domain, and ARPs go across >>the RBridges. So indeed an ARP is carried over a spanning tree, but it's >>not THE spanning tree >>calculated by the 802.1d spanning tree algorithm. >> >> > >Won't that create possible loops? > >Joe > >[Saikat] RBridges would broadcast over a spanning tree (of the graph >consisting of the RBridges), isn't it? > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BLr4L14877 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:53:04 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 36so735753wra for <rbridge@postel.org>; Tue, 11 Oct 2005 14:53:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fgj8SJt5RSor5jHZqjjbW6NrSSjGuQngFnKEgmw7AjwmFrXxUmROn76jUM0LCq3Ll2qfWKmnAoAy04ZtvzkvcznpTRaeDoBEO3bNWqWGPJbfJTNXlNI5ynCcl0vnby28kCsgmQ83WOmxx4vG+gMQYT2zlj7r5T049+Zhj+WnuQc= Received: by 10.54.130.2 with SMTP id c2mr31681wrd; Tue, 11 Oct 2005 14:53:03 -0700 (PDT) Received: by 10.54.118.20 with HTTP; Tue, 11 Oct 2005 14:53:03 -0700 (PDT) Message-ID: <582968a0510111453t409ccb66mac23f3e9903e56d@mail.gmail.com> Date: Tue, 11 Oct 2005 17:53:03 -0400 From: Stephen Suryaputra <ssuryaputra@gmail.com> To: Radia Perlman <Radia.Perlman@sun.com> In-Reply-To: <434C0C4D.6020904@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5220_26165615.1129067583611" References: <mailman.1.1128798001.23832.rbridge@postel.org> <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> <434C0C4D.6020904@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ssuryaputra@gmail.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ssurya@ieee.org, "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, 11 Oct 2005 21:53:43 -0000 Status: RO Content-Length: 3167 ------=_Part_5220_26165615.1129067583611 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/11/05, Radia Perlman <Radia.Perlman@sun.com> wrote: > > > So...how should VLAN A endnode membership be passed around? There are > various choices: > a) in one instance of IS-IS, along with the RBridge topology information > b) have an instance of IS-IS per VLAN, just for passing around the > endnode information for that VLAN. > This would be a fairly trivial subset of IS-IS, because there is no > forwarding of link state information. > The VLAN A instance of IS-IS would use the VLAN A broadcast domain > created by the main > IS-IS instance, to have each RBridge in VLAN A announce its directly > attached VLAN A endnodes > c) have some other protocol, simpler than IS-IS (because link state > information never needs to be forwarded), > that just sends out endnode information. This may have been discussed before. Since the first packet will go through the spanning tree due to multicast/broadcast/unknown, why not the shim header contain both ingress and egress Rbridge and let the egress Rbridge learn the original L2 source address to ingress Rbridge mapping (the same a= s bridge learning today with aging timer)? Rbridges on the path that are connected to the same VLAN can use the same information. Stephen. ------=_Part_5220_26165615.1129067583611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <br><br><div><span class=3D"gmail_quote">On 10/11/05, <b class=3D"gmail_sen= dername">Radia Perlman</b> <<a href=3D"mailto:Radia.Perlman@sun.com">Rad= ia.Perlman@sun.com</a>> wrote:</span><blockquote class=3D"gmail_quote" s= tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e= x; padding-left: 1ex;"> <br>So...how should VLAN A endnode membership be passed around? There are<b= r>various choices:<br>a) in one instance of IS-IS, along with the RBridge t= opology information<br>b) have an instance of IS-IS per VLAN, just for pass= ing around the <br>endnode information for that VLAN.<br>This would be a fairly trivial su= bset of IS-IS, because there is no<br>forwarding of link state information.= <br>The VLAN A instance of IS-IS would use the VLAN A broadcast domain<br> created by the main<br>IS-IS instance, to have each RBridge in VLAN A annou= nce its directly<br>attached VLAN A endnodes<br>c) have some other protocol= , simpler than IS-IS (because link state<br>information never needs to be f= orwarded), <br>that just sends out endnode information.</blockquote><div><br> This may have been discussed before. Since the first packet will go through the spanning tree due to multicast/broadcast/unknown, why not the shim header contain both ingress and egress Rbridge and let the egress Rbridge learn the original L2 source address to ingress Rbridge mapping (the same as bridge learning today with aging timer)? Rbridges on the path that are connected to the same VLAN can use the same information.<br> </div><br></div>Stephen.<br> ------=_Part_5220_26165615.1129067583611-- Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BLm3L12297 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:48:03 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2005 14:47:46 -0700 X-IronPort-AV: i="3.97,202,1125903600"; d="scan'208"; a="219217643:sNHT820958284" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9BLlM92012077 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:47:42 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 14:47:43 -0700 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: Tue, 11 Oct 2005 14:47:42 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD6802@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOq2LPgy46H7umRwm7VY12ce1AWAAAcaMg From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 21:47:43.0987 (UTC) FILETIME=[69380430:01C5CEAD] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BLm3L12297 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:48:47 -0000 Status: RO Content-Length: 4715 Joe, Sorry, but I totally missed the fact that Spanning Tree Protocol is being used within the RBridged network! All I had seen were references to routing protocols such as IS-IS. Nevermind... - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Tuesday, October 11, 2005 2:22 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Kreeger (kreeger) wrote: > Joe, > > As far as I know, all variations of STP guaranteed that bridged > networks never have temporary loops, so existing bridges never have this problem. > If they did, then I'd agree that it is no different. I'm confused. We are using STP for multicast/broadcast inside the campus. Why then will that STP cause loops whereas current bridges do not? Joe > > - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 1:47 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > Yes - but I think Radia pointed out that this is no different than how > existing bridges would behave in that circumstance. > > joe > > > Larry Kreeger (kreeger) wrote: > >>>Joe, >>> >>>The context was that during a topology change, there could be a >>>temporary loop. While this temporary loop exists, >>>multicast/broadcasts would duplicate to edge ports each time they >>>came > > >>>around - until the TTL reaches its limit. >>> >>> - Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Joe Touch >>>Sent: Tuesday, October 11, 2005 1:02 PM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] loops in trill networks >>> >>> >>> >>>Larry Kreeger (kreeger) wrote: >>> >>> >>>>>OK, I can see how a TTL will stop loops, and would prevent >>>>>duplicate known unicasts from being delivered, but how does a TTL >>>>>stop broadcast/multicast/unknown unicast frames from being >>>>>duplicated to edge ports each time the frame comes round the loop? >>> >>> >>>The multicast/broadcast packets are forwarded by one or more spanning >>>trees. There should never be loops in those anyway as a result. >>> >>>Joe >>> >>> >>> >>>>>Or is this considered >>>>>OK behavior in an RBridge network compared to an 802.1 bridged >>> >>>network? >>> >>> >>>>>New to all this... - Larry >>>>> >>>>>-----Original Message----- >>>>>From: rbridge-bounces@postel.org >>>>>[mailto:rbridge-bounces@postel.org] >>>>>On Behalf Of Joe Touch >>>>>Sent: Tuesday, October 11, 2005 7:07 AM >>>>>To: Developing a hybrid router/bridge. >>>>>Subject: Re: [rbridge] loops in trill networks >>>>> >>>>>There is, and that's what it's there for. >>>>> >>>>>Joe >>>>> >>>>>Mike Hughes wrote: >>>>> >>>>> >>>>> >>>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>this might be an old discussion, but it is some time since it >>>>>>>look at >>> >>> >>>>>>>it. What do we do in trill networks about transient loops, i.e. >>>>>>>if use >>>>> >>>>> >>>>>>>link state protocols there is a possibility that we have >>>>>>>transient loops. With no TTL mechanisms those looping frames >>>>>>>could cause quite a >>>>> >>>>> >>>>>>>bit of problem. >>>>>> >>>>>> >>>>>>Unless I've missed something, or things have changed overnight, >>>>>>there is a TTL provided in the SHIM header. >>>>>> >>>>>>Mike >>>>> >>>>>_______________________________________________ >>>>>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 _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCz4E5f5cImnZrsRAupAAJ9uc9RO2M6nGvzxGY5UqzjYn0OafACgimKq R8mFDeQMzN6IdleEU574J4c= =F6gF -----END PGP SIGNATURE----- _______________________________________________ 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 j9BLlmL12286 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:47:48 -0700 (PDT) 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 <0IO700H5WTVIXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 14:47:42 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HY4TVI1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 14:47:42 -0700 (PDT) Date: Tue, 11 Oct 2005 14:47:43 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9DD67CA@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C32FF.8010200@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: <A0A653F4CB702442BFBF2FAF02C031E9DD67CA@xmb-sjc-21e.amer.cisco.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] loops in trill networks 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, 11 Oct 2005 21:48:44 -0000 Status: RO Content-Length: 1521 There was never a "guarantee" in STP that there not be loops. STP attempted to avoid them by waiting before turning ports on. RSTP, instead of waiting before turning on ports, attempts to avoid loops by using local information to turn some links on while turning others off. Although it's certainly good to try to avoid temporary loops, it's never possible to *guarantee* no temporary loops. These can be caused by misconfiguration (someone claiming a port will only have endnodes, whereas it actually does get connected to a switch), by bringing up a repeater, or having enough consecutive BPDUs lost for whatever reason (congestion on the link causing packets to not reach a bridge, or the bridge not being able to keep up with worst case wire speed). The thing that got me interested in this again is finding out that bridge meltdowns (due to temporary loops) do occur, and apparently with increasing frequency with new features that have been added to bridges that involve configuration that can be disastrous if set incorrectly, or with bridges deployed that can't keep up with wire speeds. So the idea is that although it's certainly good to try to avoid temporary loops, we want to make it not a disaster if they do occur. Radia Larry Kreeger (kreeger) wrote: >Joe, > >As far as I know, all variations of STP guaranteed that bridged networks >never have temporary loops, so existing bridges never have this problem. >If they did, then I'd agree that it is no different. > > - Larry > > > > 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 j9BLcML08719 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:38:22 -0700 (PDT) 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 <0IO700H5LTFTXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 14:38:17 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HWNTFR1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 14:38:17 -0700 (PDT) Date: Tue, 11 Oct 2005 14:38:16 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <434C2861.4030207@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C30C8.7000503@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: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> <434C2861.4030207@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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:38:44 -0000 Status: RO Content-Length: 1680 RBridges will not participate in BPDUs. They will drop them. It is possible to have a bridge that "does not participate" (some bridges allow you to "turn off the spanning tree"), but in that case, the bridge would forward a BPDU without processing it. Bridges that do "participate in BPDUs" don't simply forward them. Instead they absorb them, and generate their own, on links for which they are Designated Bridge. RBridges will neither forward BPDUs, nor generate their own BPDUs. In contrast, a bridge will either have spanning tree turned off (in which case it will forward all BPDUs on all ports without processing them) or turned on (in which case it will process the BPDUs in order to determine its distance to the Root bridge, and in order to determine which links it should be DB on, and for those links, to generate its own BPDU). Radia > > > >>Rbridges - like routers - do not forward BPDUs. >> >> > >Let me propose a question. Let's say an rbridge campus looks like a >single giant bridge (humor me). > >There are two cases: > > - the bridge participates in BPDU > > - the bridge does not participate in BPDU > >Is it possible in existing systems to have a bridge that does not >participate in BPDU? Wouldn't this end up creating loops? > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDTChhE5f5cImnZrsRAkAqAKCrkBhoqAYQsRB1/W1OlhWtuOlg0QCgyfj7 >+kCndWeVdgjyigTPYUF4U3Y= >=wt7Z >-----END PGP SIGNATURE----- >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from lion.seas.upenn.edu (LION.SEAS.upenn.edu [158.130.12.194]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BLPqL02638 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:25:52 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by lion.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j9BLPout011190 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Tue, 11 Oct 2005 17:25:51 -0400 Message-Id: <200510112125.j9BLPout011190@lion.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Tue, 11 Oct 2005 17:25:53 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 thread-index: AcXOp9bjsB05VfX+RM6PIt+jBYU/tAAAk1DA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <434C2899.60907@isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] loops in trill networks X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 11 Oct 2005 21:26:44 -0000 Status: RO Content-Length: 576 > What I mean by "n spanning trees that do not see each other" is that the > RBridges don't glue the > 802.1d spanning tree together into a single 802.1d spanning > tree with one Root Bridge, etc. > > They do, however, create a single broadcast domain, and ARPs go across > the RBridges. So indeed an ARP is carried over a spanning tree, but it's > not THE spanning tree > calculated by the 802.1d spanning tree algorithm. Won't that create possible loops? Joe [Saikat] RBridges would broadcast over a spanning tree (of the graph consisting of the RBridges), isn't it? 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 j9BLNwL01917; Tue, 11 Oct 2005 14:23:58 -0700 (PDT) Message-ID: <434C2CF9.6070202@isi.edu> Date: Tue, 11 Oct 2005 14:22:01 -0700 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> References: <A0A653F4CB702442BFBF2FAF02C031E9DD67CA@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <A0A653F4CB702442BFBF2FAF02C031E9DD67CA@xmb-sjc-21e.amer.cisco.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:25:18 -0000 Status: RO Content-Length: 4115 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Kreeger (kreeger) wrote: > Joe, > > As far as I know, all variations of STP guaranteed that bridged networks > never have temporary loops, so existing bridges never have this problem. > If they did, then I'd agree that it is no different. I'm confused. We are using STP for multicast/broadcast inside the campus. Why then will that STP cause loops whereas current bridges do not? Joe > > - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 1:47 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > Yes - but I think Radia pointed out that this is no different than how > existing bridges would behave in that circumstance. > > joe > > > Larry Kreeger (kreeger) wrote: > >>>Joe, >>> >>>The context was that during a topology change, there could be a >>>temporary loop. While this temporary loop exists, >>>multicast/broadcasts would duplicate to edge ports each time they came > > >>>around - until the TTL reaches its limit. >>> >>> - Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Joe Touch >>>Sent: Tuesday, October 11, 2005 1:02 PM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] loops in trill networks >>> >>> >>> >>>Larry Kreeger (kreeger) wrote: >>> >>> >>>>>OK, I can see how a TTL will stop loops, and would prevent duplicate >>>>>known unicasts from being delivered, but how does a TTL stop >>>>>broadcast/multicast/unknown unicast frames from being duplicated to >>>>>edge ports each time the frame comes round the loop? >>> >>> >>>The multicast/broadcast packets are forwarded by one or more spanning >>>trees. There should never be loops in those anyway as a result. >>> >>>Joe >>> >>> >>> >>>>>Or is this considered >>>>>OK behavior in an RBridge network compared to an 802.1 bridged >>> >>>network? >>> >>> >>>>>New to all this... - Larry >>>>> >>>>>-----Original Message----- >>>>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>>>On Behalf Of Joe Touch >>>>>Sent: Tuesday, October 11, 2005 7:07 AM >>>>>To: Developing a hybrid router/bridge. >>>>>Subject: Re: [rbridge] loops in trill networks >>>>> >>>>>There is, and that's what it's there for. >>>>> >>>>>Joe >>>>> >>>>>Mike Hughes wrote: >>>>> >>>>> >>>>> >>>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>this might be an old discussion, but it is some time since it look >>>>>>>at >>> >>> >>>>>>>it. What do we do in trill networks about transient loops, i.e. if >>>>>>>use >>>>> >>>>> >>>>>>>link state protocols there is a possibility that we have transient >>>>>>>loops. With no TTL mechanisms those looping frames could cause >>>>>>>quite a >>>>> >>>>> >>>>>>>bit of problem. >>>>>> >>>>>> >>>>>>Unless I've missed something, or things have changed overnight, >>>>>>there is a TTL provided in the SHIM header. >>>>>> >>>>>>Mike >>>>> >>>>>_______________________________________________ >>>>>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 _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCz4E5f5cImnZrsRAupAAJ9uc9RO2M6nGvzxGY5UqzjYn0OafACgimKq R8mFDeQMzN6IdleEU574J4c= =F6gF -----END PGP SIGNATURE----- Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BLDGL27244 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:13:16 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2005 14:13:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9BLCR9a021064 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:13:08 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 14:13:02 -0700 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: Tue, 11 Oct 2005 14:13:01 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD67CA@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOps2v2kxBXWkiT5yQ+9DhThoQMQAARjkg From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 21:13:02.0619 (UTC) FILETIME=[90A076B0:01C5CEA8] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BLDGL27244 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:13:42 -0000 Status: RO Content-Length: 3571 Joe, As far as I know, all variations of STP guaranteed that bridged networks never have temporary loops, so existing bridges never have this problem. If they did, then I'd agree that it is no different. - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Tuesday, October 11, 2005 1:47 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes - but I think Radia pointed out that this is no different than how existing bridges would behave in that circumstance. joe Larry Kreeger (kreeger) wrote: > Joe, > > The context was that during a topology change, there could be a > temporary loop. While this temporary loop exists, > multicast/broadcasts would duplicate to edge ports each time they came > around - until the TTL reaches its limit. > > - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 1:02 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > > > Larry Kreeger (kreeger) wrote: > >>>OK, I can see how a TTL will stop loops, and would prevent duplicate >>>known unicasts from being delivered, but how does a TTL stop >>>broadcast/multicast/unknown unicast frames from being duplicated to >>>edge ports each time the frame comes round the loop? > > > The multicast/broadcast packets are forwarded by one or more spanning > trees. There should never be loops in those anyway as a result. > > Joe > > >>>Or is this considered >>>OK behavior in an RBridge network compared to an 802.1 bridged > > network? > >>>New to all this... - Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Joe Touch >>>Sent: Tuesday, October 11, 2005 7:07 AM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] loops in trill networks >>> >>>There is, and that's what it's there for. >>> >>>Joe >>> >>>Mike Hughes wrote: >>> >>> >>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>>> >>>> >>>> >>>> >>>>>this might be an old discussion, but it is some time since it look >>>>>at > > >>>>>it. What do we do in trill networks about transient loops, i.e. if >>>>>use >>> >>> >>>>>link state protocols there is a possibility that we have transient >>>>>loops. With no TTL mechanisms those looping frames could cause >>>>>quite a >>> >>> >>>>>bit of problem. >>>> >>>> >>>>Unless I've missed something, or things have changed overnight, >>>>there is a TTL provided in the SHIM header. >>>> >>>>Mike >>> >>>_______________________________________________ >>>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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCS6E5f5cImnZrsRAmwcAJ9fQtNoDy+F2QkBAVQZ7WYPU3b6TgCfYmAt OZr4d3M3P47EqUD1svFKTio= =wzac -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge 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 j9BLCEL26755; Tue, 11 Oct 2005 14:12:14 -0700 (PDT) Message-ID: <434C2A38.8060901@isi.edu> Date: Tue, 11 Oct 2005 14:10:16 -0700 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] steps towards the problem and architecture documents 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, 11 Oct 2005 21:13:10 -0000 Status: RO Content-Length: 1494 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, As promised, I've been working on the split of the existing rbridge document into a set of more typical IETF-style documents: problem and applicability (this isn't even in the charter, butseems necessary IMO) (we can, if desired, merge it with the design/arch doc below to have a single doc if preferred) defining the problem describing the solution based on desired benefits (leaving architecture open) explaining cases where it is expected to be useful design (I would call this the architecture doc; is that OK? that matches more what we call it in the charter) defining terms defining the basic components of the proposed solution describing the operation based on functional behavior (leaving implementation particulars open) specification (some would call this a protocol doc; is that preferred?) describe the details of a particular instance of the architecture, including specific headers, fields, etc. and processing expected this document may also specify the routing protocol (setting CFT entries) or protocol used to exchange egress info (CTT entries) Just so we know what belongs in which document before we all start. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCo4E5f5cImnZrsRAqyZAKDo6dUSwFDM2kLolhN0rGe5uqP32QCdE+xz 5C+/gc7wAD/RA0iVl4f7ga4= =zoTZ -----END PGP SIGNATURE----- Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BL82L24942 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:08:02 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2005 14:07:52 -0700 X-IronPort-AV: i="3.97,202,1125903600"; d="scan'208"; a="665197970:sNHT612693594" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9BL7D9c017964 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:07:50 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 14:07:49 -0700 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: Tue, 11 Oct 2005 14:07:47 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD67C4@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOnbewOSKOhYZkRbeZcN1iWBJa3wAChFLw From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 21:07:49.0096 (UTC) FILETIME=[D5C0A680:01C5CEA7] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BL82L24942 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:09:12 -0000 Status: RO Content-Length: 5625 Radia, How about the case where the two ports connected to the same bridged domain are on different RBridges? Consider, the following topology where A,B,C are hosts. A--RB1--Bridged-Domain--RB2--B | | RB3--C In this case, would all RB's forward a L2 broadcast to their respective edge ports? I was assuming, yes. If so, then RB1,RB2 and RB3 are all designated RBs in order to have broadcast connectivity between A,B,C. Now a new RB4 is added to the topology which connects RB1 and RB3, A--RB1--Bridged-Domain--RB2--B | | | | D--RB4-------RB3--C Are you saying that RB1 and RB3 detect that they now have new connectivity and battle to be a Designated RB to serve their side of the network? Assuming RB3 wins, all broadcasts must enter and leave the Bridged-Domain via RB3 to get between hosts A,C,D and B. RB2 must still be the Designated RB for traffic to reach B. I didn't think routers needed to deal with this since they don't forward broadcasts. Are you saying that routing protocols already deal with these types of scenarios? Thanks, Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Tuesday, October 11, 2005 12:46 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks The intention is that deployment not have to be careful. If two of an RBridge's ports are connected to the same bridged broadcast domain (i.e., there is a bridge-connected path between the two ports), then the RBridge will think it has two ports connected to the same link. Which is OK. It won't forward any packets, including not BPDUs, between those ports. At most one of its ports will become "designated" for sourcing/sinking unencapsulated traffic to/from that link. It would be just like a router having two ports connected to the same link, which should work with no problem. Radia Gray, Eric wrote: >Radia, > > If I am understanding what you are saying correctly, there are some >deployment issues with Rbridges into a 802.1 bridged environment. > > The deployment issues arise when individual RBridges are installed, if >this is not carefully planned in advance. >If an Rbridge is installed on a link where it is connected to two or >more 802.1 bridges and there is another L2 path between those two >bridges, the RBridge will either have to forward BPDUs or - like a >router - recognize that multiple ports are connected to the same LAN. > > Is there an intention that the latter would be the default case until >and unless the installed RBridge is able to discover a connected >RBridge peer? > >-- >Eric Gray > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Radia Perlman >--> Sent: Tuesday, October 11, 2005 12:44 PM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] loops in trill networks >--> >--> >--> There's nothing an RBridge can do about loops consisting of just >--> bridges. >--> Which is why it's good to partition the spanning trees formed by >--> the bridges so that the remaining spanning trees are as small, and >--> therefore as stable, as possible. >--> >--> RBridges are like routers. They sit at a layer above bridges. The >--> bridges form what looks like a single link to the RBridges. If >--> there are a bunch of bridges connecting a bunch of segments, all >--> the RBridges attached to that portion of the network see that >--> bridged segment as a single link. >--> >--> Radia >--> >--> Loa Andersson wrote: >--> >--> >Oh, yes it is true ... >--> > >--> >but I thought that a trill network could consist of a mixed of >--> >rbridges and the type of bridges that exist today, if that is the >--> >case you can possibly form the loop over only non-rbridges >--> > >--> >but I'm not up to speed on this, there might be a way to handle >--> >this also >--> > >--> >/Loa >--> > >--> >Joe Touch wrote: >--> > >--> > >--> >>There is, and that's what it's there for. >--> >> >--> >>Joe >--> >> >--> >>Mike Hughes wrote: >--> >> >--> >> >--> >> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >--> >>> >--> >>> >--> >>> >--> >>> >--> >>> >--> >>>>this might be an old discussion, but it is some time since it >--> >>>>look at it. What do we do in trill networks about transient >--> >>>>loops, i.e. if use link state protocols there is a possibility >--> >>>>that we have transient loops. With no TTL mechanisms >--> those looping >--> >>>>frames could cause quite a bit of problem. >--> >>>> >--> >>>> >--> >>>Unless I've missed something, or things have changed >--> overnight, there is a >--> >>>TTL provided in the SHIM header. >--> >>> >--> >>>Mike >--> >>> >--> >>> >--> >>>--------------------------------------------------------- >--> --------------- >--> >>> >--> >>>_______________________________________________ >--> >>>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 [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 j9BL5JL23663; Tue, 11 Oct 2005 14:05:19 -0700 (PDT) Message-ID: <434C2899.60907@isi.edu> Date: Tue, 11 Oct 2005 14:03:21 -0700 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> References: <A0A653F4CB702442BFBF2FAF02C031E9DD66DE@xmb-sjc-21e.amer.cisco.com> <434C0E56.7050108@sun.com> <434C21D0.4020702@isi.edu> <434C27D0.8040500@sun.com> In-Reply-To: <434C27D0.8040500@sun.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:05:44 -0000 Status: RO Content-Length: 970 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radia Perlman wrote: > Joe...you and I are not disagreeing about the technical intent...just > getting hung up on terminology I think. Which is important - because that's where I am in the docs ;-) > What I mean by "n spanning trees that do not see each other" is that the > RBridges don't glue the > 802.1d spanning tree together into a single 802.1d spanning > tree with one Root Bridge, etc. > > They do, however, create a single broadcast domain, and ARPs go across > the RBridges. So indeed an ARP is carried over a spanning tree, but it's > not THE spanning tree > calculated by the 802.1d spanning tree algorithm. Won't that create possible loops? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCiZE5f5cImnZrsRAnvlAKCMCM6W7k7Som+7/343c/UzDGf39wCdGzsY TPlp3Sy4mk8CERIn04GMI9c= =Wp3B -----END PGP SIGNATURE----- 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 j9BL4NL23254; Tue, 11 Oct 2005 14:04:23 -0700 (PDT) Message-ID: <434C2861.4030207@isi.edu> Date: Tue, 11 Oct 2005 14:02:25 -0700 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> References: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:04:47 -0000 Status: RO Content-Length: 1161 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gray, Eric wrote: > Larry, > > You've got the sense of Radia's reply reversed. It's the > 802.1 bridges that look like a single link to the RBridges. > > This is pretty much how I expected this to work. A cloud > of 802.1 bridges MUST be completely enclosed in either RBridges > or routers. I was expecting that to say "or there will be little or no benefit from the rbridges" - i.e., topology restrictions can't be enforced per se if we're expecting plug-and-play. > Rbridges - like routers - do not forward BPDUs. Let me propose a question. Let's say an rbridge campus looks like a single giant bridge (humor me). There are two cases: - the bridge participates in BPDU - the bridge does not participate in BPDU Is it possible in existing systems to have a bridge that does not participate in BPDU? Wouldn't this end up creating loops? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTChhE5f5cImnZrsRAkAqAKCrkBhoqAYQsRB1/W1OlhWtuOlg0QCgyfj7 +kCndWeVdgjyigTPYUF4U3Y= =wt7Z -----END PGP SIGNATURE----- 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 j9BL05L20991 for <rbridge@postel.org>; Tue, 11 Oct 2005 14:00:05 -0700 (PDT) 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 <0IO700H3ZRNZXX00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 13:59:59 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HR6RNZ1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 13:59:59 -0700 (PDT) Date: Tue, 11 Oct 2005 14:00:00 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <434C21D0.4020702@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C27D0.8040500@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: <A0A653F4CB702442BFBF2FAF02C031E9DD66DE@xmb-sjc-21e.amer.cisco.com> <434C0E56.7050108@sun.com> <434C21D0.4020702@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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 21:00:45 -0000 Status: RO Content-Length: 4479 Joe...you and I are not disagreeing about the technical intent...just getting hung up on terminology I think. What I mean by "n spanning trees that do not see each other" is that the RBridges don't glue the 802.1d spanning tree together into a single 802.1d spanning tree with one Root Bridge, etc. They do, however, create a single broadcast domain, and ARPs go across the RBridges. So indeed an ARP is carried over a spanning tree, but it's not THE spanning tree calculated by the 802.1d spanning tree algorithm. As far as IP nodes go, they can't tell whether what I call a campus is connected via bridges, RBridges, repeaters, or any combination. It's all just a single broadcast domain. All the IP nodes connected into this campus view it as a single link, a single IP subnet, where all IP nodes on that campus view each other as direct neighbors. The only message that is special to RBridges, in terms of layer 2 multicasts, is the BPDU. That is not forwarded by RBridges. But all other layer 2 multicasts get forwarded across the broadcast domain. The collection of RBridges, bridges, and links DO form a single broadcast domain, together with a spanning tree, but it's not the spanning tree calculated by 802.1d spanning tree. It's instead a spanning tree (or set of trees) calculated from the link state database. However, there might still be 802.1d spanning trees on what an RBridge would think of as single links. Radia Joe Touch wrote: > >>If you had a big 802.1d broadcast domain, and >>partitioned >>it into n pieces, with the pieces connected with RBridges (and not with >>bridges), >>you'd wind up with n spanning trees that did not see each other. >> >> > >That seems to cause the problem above, though. > >Joe > > > >>Radia >> >> >> >>Larry Kreeger (kreeger) wrote: >> >> >> >> >>>This brings up another question. >>> >>>What does the RBridge network look like to the 802.1 bridged network. >>>Does the RBridge network pretend it is a giant 802.1D bridge - >>>exchanging BPDUs at its edge ports with the 802.1 bridges and blocking >>>edge ports if it detects a loop? What happens to the BPDUs sent by >>>802.1 bridges to the RBridges? >>> >>>- Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >>>Behalf Of Joe Touch >>>Sent: Tuesday, October 11, 2005 8:26 AM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] loops in trill networks >>> >>> >>> >>Loa Andersson wrote: >> >> >> >> >> >>>Oh, yes it is true ... >>> >>> >>>but I thought that a trill network could consist of a mixed of >>>rbridges and the type of bridges that exist today, if that is the case >>> >>> >> >> >> >> >> >> >>>you can possibly form the loop over only non-rbridges >>> >>> >> >>The conventional bridges have a spanning tree, which is what already >>prevents such loops currently. >> >>Think of the path between two nodes (hosts, routers, etc. - anything >>that sources/sinks L2 frames) as having three components (at most): >> >>node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node >> >>the ingress (bridgepath1) and egress (bridgepath2) conventional bridge >>paths use spanning trees, so they can't have loops. >> >>The rbridge uses the TTL, so it can't have a loop at its layer. Even >>when it tunnels over conventional bridges ('inside' the rbridge, in a >>sense), those can't have loops because they're spanning-tree. >> >>The combination of spanning tree in all bridge paths and TTL in the >>rbridge logical path prevents loops in the node-node path. >> >>Joe >> >> >_______________________________________________ >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 >> >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDTCHQE5f5cImnZrsRAn/bAJ9mD1R9reyuHG9vECvNNVelOTva6ACfVJLk >50SX6s3uugIlvrf0O6DZnng= >=720Z >-----END PGP SIGNATURE----- >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > 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 j9BKmmL17529; Tue, 11 Oct 2005 13:48:48 -0700 (PDT) Message-ID: <434C24BA.1030505@isi.edu> Date: Tue, 11 Oct 2005 13:46:50 -0700 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> References: <A0A653F4CB702442BFBF2FAF02C031E9DD67A5@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <A0A653F4CB702442BFBF2FAF02C031E9DD67A5@xmb-sjc-21e.amer.cisco.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:49:45 -0000 Status: RO Content-Length: 2963 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes - but I think Radia pointed out that this is no different than how existing bridges would behave in that circumstance. joe Larry Kreeger (kreeger) wrote: > Joe, > > The context was that during a topology change, there could be a > temporary loop. While this temporary loop exists, multicast/broadcasts > would duplicate to edge ports each time they came around - until the TTL > reaches its limit. > > - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 1:02 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > > > Larry Kreeger (kreeger) wrote: > >>>OK, I can see how a TTL will stop loops, and would prevent duplicate >>>known unicasts from being delivered, but how does a TTL stop >>>broadcast/multicast/unknown unicast frames from being duplicated to >>>edge ports each time the frame comes round the loop? > > > The multicast/broadcast packets are forwarded by one or more spanning > trees. There should never be loops in those anyway as a result. > > Joe > > >>>Or is this considered >>>OK behavior in an RBridge network compared to an 802.1 bridged > > network? > >>>New to all this... - Larry >>> >>>-----Original Message----- >>>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >>>On Behalf Of Joe Touch >>>Sent: Tuesday, October 11, 2005 7:07 AM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] loops in trill networks >>> >>>There is, and that's what it's there for. >>> >>>Joe >>> >>>Mike Hughes wrote: >>> >>> >>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>>> >>>> >>>> >>>> >>>>>this might be an old discussion, but it is some time since it look at > > >>>>>it. What do we do in trill networks about transient loops, i.e. if >>>>>use >>> >>> >>>>>link state protocols there is a possibility that we have transient >>>>>loops. With no TTL mechanisms those looping frames could cause quite >>>>>a >>> >>> >>>>>bit of problem. >>>> >>>> >>>>Unless I've missed something, or things have changed overnight, there >>>>is a TTL provided in the SHIM header. >>>> >>>>Mike >>> >>>_______________________________________________ >>>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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCS6E5f5cImnZrsRAmwcAJ9fQtNoDy+F2QkBAVQZ7WYPU3b6TgCfYmAt OZr4d3M3P47EqUD1svFKTio= =wzac -----END PGP SIGNATURE----- Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BKjPL15810 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:45:25 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2005 13:45:10 -0700 X-IronPort-AV: i="3.97,202,1125903600"; d="scan'208"; a="219186244:sNHT28736297060" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9BKiqVA001875 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:45:07 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 13:45:06 -0700 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: Tue, 11 Oct 2005 13:45:05 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD67A5@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOoGQyJ4CRs1FyQ42pocEsYYtolwABBAdQ From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 20:45:06.0996 (UTC) FILETIME=[A9E0AF40:01C5CEA4] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BKjPL15810 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:45:44 -0000 Status: RO Content-Length: 2522 Joe, The context was that during a topology change, there could be a temporary loop. While this temporary loop exists, multicast/broadcasts would duplicate to edge ports each time they came around - until the TTL reaches its limit. - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Tuesday, October 11, 2005 1:02 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Kreeger (kreeger) wrote: > OK, I can see how a TTL will stop loops, and would prevent duplicate > known unicasts from being delivered, but how does a TTL stop > broadcast/multicast/unknown unicast frames from being duplicated to > edge ports each time the frame comes round the loop? The multicast/broadcast packets are forwarded by one or more spanning trees. There should never be loops in those anyway as a result. Joe > Or is this considered > OK behavior in an RBridge network compared to an 802.1 bridged network? > > New to all this... - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 7:07 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > There is, and that's what it's there for. > > Joe > > Mike Hughes wrote: > >>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >> >> >> >>>this might be an old discussion, but it is some time since it look at >>>it. What do we do in trill networks about transient loops, i.e. if >>>use > > >>>link state protocols there is a possibility that we have transient >>>loops. With no TTL mechanisms those looping frames could cause quite >>>a > > >>>bit of problem. >> >> >>Unless I've missed something, or things have changed overnight, there >>is a TTL provided in the SHIM header. >> >>Mike > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTBpUE5f5cImnZrsRAk2EAKDUBLgyz1duwtVTZyrUE8t++Z381wCdFW4L OG6Pao5gsla9YrMI+qEdiNA= =dTLU -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge 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 j9BKaML12069; Tue, 11 Oct 2005 13:36:22 -0700 (PDT) Message-ID: <434C21D0.4020702@isi.edu> Date: Tue, 11 Oct 2005 13:34:24 -0700 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> References: <A0A653F4CB702442BFBF2FAF02C031E9DD66DE@xmb-sjc-21e.amer.cisco.com> <434C0E56.7050108@sun.com> In-Reply-To: <434C0E56.7050108@sun.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:36:48 -0000 Status: RO Content-Length: 3109 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radia Perlman wrote: > RBridges do not participate in the 802.1d spanning tree. The neither > generate > nor forward spanning tree messages. > > They look to bridges > like routers do today. Routers stop broadcasts; if rbridges do, then ARP won't work. I was anticipating as Larry was - that a campus would act like a single giant bridge. > If you had a big 802.1d broadcast domain, and > partitioned > it into n pieces, with the pieces connected with RBridges (and not with > bridges), > you'd wind up with n spanning trees that did not see each other. That seems to cause the problem above, though. Joe > > Radia > > > > Larry Kreeger (kreeger) wrote: > > >>This brings up another question. >> >>What does the RBridge network look like to the 802.1 bridged network. >>Does the RBridge network pretend it is a giant 802.1D bridge - >>exchanging BPDUs at its edge ports with the 802.1 bridges and blocking >>edge ports if it detects a loop? What happens to the BPDUs sent by >>802.1 bridges to the RBridges? >> >>- Larry >> >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >>Behalf Of Joe Touch >>Sent: Tuesday, October 11, 2005 8:26 AM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] loops in trill networks >> > > > Loa Andersson wrote: > > > >>Oh, yes it is true ... > >>but I thought that a trill network could consist of a mixed of >>rbridges and the type of bridges that exist today, if that is the case > > > > > > >>you can possibly form the loop over only non-rbridges > > > > The conventional bridges have a spanning tree, which is what already > prevents such loops currently. > > Think of the path between two nodes (hosts, routers, etc. - anything > that sources/sinks L2 frames) as having three components (at most): > > node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node > > the ingress (bridgepath1) and egress (bridgepath2) conventional bridge > paths use spanning trees, so they can't have loops. > > The rbridge uses the TTL, so it can't have a loop at its layer. Even > when it tunnels over conventional bridges ('inside' the rbridge, in a > sense), those can't have loops because they're spanning-tree. > > The combination of spanning tree in all bridge paths and TTL in the > rbridge logical path prevents loops in the node-node path. > > Joe _______________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCHQE5f5cImnZrsRAn/bAJ9mD1R9reyuHG9vECvNNVelOTva6ACfVJLk 50SX6s3uugIlvrf0O6DZnng= =720Z -----END PGP SIGNATURE----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BKYDL10662 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:34:13 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id i7so737091wra for <rbridge@postel.org>; Tue, 11 Oct 2005 13:34:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=j8k8kgV8mGVH7SxR0dGMhOJJ7rsjthUCFGZrvBJUrI5SkQC7gKqzxlTGv71tDlInv0SjyLRvbAG1qrG/xD6ki9YQqfiF5cSPGkf1fWhbNhBrW9RYNwftXKRbeJGZ/mhMPyZapfGRWDo5AwPGjgJFfBq4lu1C+krOq/1rMegnJAw= Received: by 10.54.157.12 with SMTP id f12mr3441212wre; Tue, 11 Oct 2005 13:34:13 -0700 (PDT) Received: by 10.54.148.1 with HTTP; Tue, 11 Oct 2005 13:34:13 -0700 (PDT) Message-ID: <6280db520510111334w43889c8emdd2643c6524ba807@mail.gmail.com> Date: Tue, 11 Oct 2005 13:34:13 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <2F1B97FA2C3CF5C6E7E2F754@gloppen.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28831_16808081.1129062853030" References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> <434BEBD5.9040401@sun.com> <6280db520510111041h1c8be79fj63b43cc696e34643@mail.gmail.com> <434BFE55.7030002@sun.com> <6280db520510111117p4f6953d3w651a4e5d931bf60@mail.gmail.com> <2F1B97FA2C3CF5C6E7E2F754@gloppen.hjemme.alvestrand.no> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:34:43 -0000 Status: RO Content-Length: 3455 ------=_Part_28831_16808081.1129062853030 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/11/05, Harald Tveit Alvestrand <harald@alvestrand.no> wrote: > > > > --On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas > <akatlas@gmail.com> wrote: > > > All the IETF protocols, I believe, are designed to withstand some packe= t > > reordering (and should, in my opinion, any well designed protocol). > > > > > > > > Sure - anything on top of IP isn't an issue. My concern was other stuff= . > > > Reordering (anything that places a packet more than 3 places out of its > proper position in the TCP stream) will trigger TCP duplicate acks, and > therefore retransmissions. > > These play hell with performance. Sure. But we live with these issues today on IP networks during a network convergence event. Therefore, it seems reasonable that the IP traffic could live with the same issues between RBridges during a convergence event there= . The other aspect of this is having acceptable load-balancing such that micro-flows don't get reordered - but we beat that to death a while ago. Alia No numbers...... > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > ------=_Part_28831_16808081.1129062853030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <br><br><div><span class=3D"gmail_quote">On 10/11/05, <b class=3D"gmail_sen= dername">Harald Tveit Alvestrand</b> <<a href=3D"mailto:harald@alvestran= d.no">harald@alvestrand.no</a>> wrote:</span><blockquote class=3D"gmail_= quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt = 0pt 0.8ex; padding-left: 1ex;"> <br><br>--On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas<br><<a = href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com</a>> wrote:<br><br>&= gt; All the IETF protocols, I believe, are designed to withstand some packe= t <br>> reordering (and should, in my opinion, any well designed protocol)= .<br>><br>><br>><br>> Sure - anything on top of IP isn't an iss= ue. My concern was other stuff.<br><br><br>Reordering (anything = that places a packet more than 3 places out of its <br>proper position in the TCP stream) will trigger TCP duplicate acks, and= <br>therefore retransmissions.<br><br>These play hell with performance.</bl= ockquote><div><br> Sure. But we live with these issues today on IP networks during a net= work <br> convergence event. Therefore, it seems reasonable that the IP traffic= could<br> live with the same issues between RBridges during a convergence event there= .<br> <br> The other aspect of this is having acceptable load-balancing such tha= t micro-flows<br> don't get reordered - but we beat that to death a while ago.<br> <br> Alia<br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">No numb= ers......<br><br>_______________________________________________<br>rbridge= mailing list <br><a href=3D"mailto:rbridge@postel.org">rbridge@postel.org</a><br><a href= =3D"http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/m= ailman/listinfo/rbridge</a><br></blockquote></div><br> ------=_Part_28831_16808081.1129062853030-- 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 j9BKWhL10025 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:32:43 -0700 (PDT) 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 <0IO700H3HQEDXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 13:32:37 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HM4QED1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 13:32:37 -0700 (PDT) Date: Tue, 11 Oct 2005 13:32:38 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <200510112012.j9BKCoRY020573@dino-lnx.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C2166.1020309@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: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> <200510112012.j9BKCoRY020573@dino-lnx.cisco.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] loops in trill networks 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, 11 Oct 2005 20:33:44 -0000 Status: RO Content-Length: 1945 I don't think I'm disagreeing with what you're saying, Dino. Certainly if there is a layer 3 IGP running on top of the RBridged link, then the RBridges (like any bridges contained in that same IP subnet) would be forwarding the IGP messages, just like they'd be forwarding anything they see as data packets traversing the "link". As for providing glue to two broadcast domains in order to merge them...yes, an RBridged "campus" could be used to tunnel packets from the two broadcast domains in order to merge them. But in general an RBridge would not forward a native BPDU. It would recognize it as something it shouldn't forward. Because RBridges intend to make the spanning trees smaller. But if someone really wanted to glue the domains together, the BPDU could traverse the RBridges by being tunneled and directed, as a data packet, to something on the other side. Perhaps the right way to think of it is that a bunch of segments connected with any mixture of RBridges and bridges would provide the same functionality as today would be provided by those segments connected with bridges. But it would just be safer, and more efficient (better paths, allow for path splitting). Radia Dino Farinacci wrote: >>>or routers. Rbridges - like routers - do not forward BPDUs. >>> >>> > > For the same token, should two routers connected to an RBridge network > running IS-IS (at L3 for IP) not get their multicast frames to each other? > > Again, RBridges may be acting like routers, but they provide a single > subnet to the edge nodes. So in this case and the BPDU case, the frames > should be forwarded through the RBridge network. > > If this is not the case, then we are building solely a stub network. > Is this really what we want to do? > >Dino > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > 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 j9BKQmL07629; Tue, 11 Oct 2005 13:26:48 -0700 (PDT) Message-ID: <434C1F92.1060002@isi.edu> Date: Tue, 11 Oct 2005 13:24:50 -0700 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> References: <mailman.1.1128798001.23832.rbridge@postel.org> <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> <434C0C4D.6020904@sun.com> In-Reply-To: <434C0C4D.6020904@sun.com> 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] terminology question for drafts 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, 11 Oct 2005 20:27:54 -0000 Status: RO Content-Length: 3325 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radia Perlman wrote: > I was actually talking with Joe about a good name for that table. I was wondering if we might call it the Campus Transit Table (CTT), and the other one the Campus Forwarding Table (CFT) - to distinguish it from conventional IP router forwarding tables, or frame forwarding tables inside conventional bridges using spanning trees. Below is a cut of some proposed terminology, including the above. Discussion encouraged; please limit discussion to the definitions here; other topics will be raised in separate emails. Joe - ------------------------------------------------------------------------ Existing Terminology [THIS IS TRYING TO ENCODE EXISTING TERMS; NOT NEW DEFINITIONS] - - 802.1: IEEE Specification for Ethernet, i.e., including hubs (but excluding bridges??) - - 802.1D: IEEE Specification for switched Ethernet, i.e., including bridges (??) [WHAT?S THE DIFFERENCE BETWEEN 802.1, 802.1D, etc.? DOES IT MATTER?] - - Bridge: an Ethernet (L2, 802.1D) forwarding device that participates in the bridge spanning tree (BST). - - Bridge spanning tree (BST): an Ethernet (L2, 802.1D) forwarding protocol based on the topology of a spanning tree - - Bridge spanning tree protocol (BSTP): an Ethernet (802.1D) protocol for establishing and maintaining a single spanning tree among all the bridges on a logical segment. - - Frame: here refers to an Ethernet (L2) unit of transmission, including the header, data, and trailer. - - Frame forwarding table (FFT): forwarding table in existing bridges - - Hub: an Ethernet (L2, 802.1) - - Node: a device with an L2 address that sources and/or sinks L2 packets; nodes can occur outside the RBridge campus or be used as transits within the campus. - - Packet: here refers t- an IP (L3) unit of transmission, including header and data. - - Segment: an L2 link, either a single physical link or emulation thereof (e.g., via hubs) or a logical link or emulation thereof (e.g., via bridges). - - Router: an IP (L3) forwarding device; RBridges cannot span routers. ========================================================================== RBridge Terminology - - Campus: a set of RBridge devices inside the same L2 subnet, all of which participate as a group to forward ingress L2 frames across the campus via encapsulation. - - Campus Forwarding Table (CFT): the per-hop forwarding table populated by the rbridge IGP based on lookups of the CTH inside the outermost received L2 header, rather than that L2 header. - - Campus Transit Header (CTH): a ?shim? header that encapsulates the ingress L2 frame and persists throughout the transit of a campus, which is further encapsulated a hop-by-hop L2 header/trailer. - - Campus Transit Table (CTT): a table that maps ingress L2 destinations to egress RBridge addresses, used to encapsulate ingress frames for transit of the campus. - - RBridge: layer-2 devices that automatically aggregate into a virtual device that emulates a single bridge on a conventional 802.1 Ethernet. - -------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTB+SE5f5cImnZrsRAl4eAJ4jEp7KJRNezPztgcyAdCzOIOwmEwCfYG+9 qY5BsuivTinHXu/zIIGuMvU= =92hQ -----END PGP SIGNATURE----- Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BKCvL02197 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:12:57 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2005 13:12:52 -0700 Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9BKCk8k027426 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:12:46 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9BKCov7020577 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:12:50 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9BKCoRY020573; Tue, 11 Oct 2005 13:12:50 -0700 Date: Tue, 11 Oct 2005 13:12:50 -0700 Message-Id: <200510112012.j9BKCoRY020573@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> (Eric.Gray@marconi.com) References: <313680C9A886D511A06000204840E1CF0C885F5B@whq-msgusr-02.pit.comms.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:14:09 -0000 Status: RO Content-Length: 546 >> or routers. Rbridges - like routers - do not forward BPDUs. For the same token, should two routers connected to an RBridge network running IS-IS (at L3 for IP) not get their multicast frames to each other? Again, RBridges may be acting like routers, but they provide a single subnet to the edge nodes. So in this case and the BPDU case, the frames should be forwarded through the RBridge network. If this is not the case, then we are building solely a stub network. Is this really what we want to do? Dino Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BK9oL01095 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:09:52 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2005 13:09:45 -0700 X-IronPort-AV: i="3.97,201,1125903600"; d="scan'208"; a="219175200:sNHT21299112" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9BK9jUw017192 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:09:45 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9BK9h2v020497 for <rbridge@postel.org>; Tue, 11 Oct 2005 13:09:43 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9BK9hlJ020493; Tue, 11 Oct 2005 13:09:43 -0700 Date: Tue, 11 Oct 2005 13:09:43 -0700 Message-Id: <200510112009.j9BK9hlJ020493@dino-lnx.cisco.com> From: Dino Farinacci <dino@cisco.com> To: rbridge@postel.org CC: rbridge@postel.org In-reply-to: <434C0FAC.7090805@sun.com> (message from Radia Perlman on Tue, 11 Oct 2005 12:17:00 -0700) References: <A0A653F4CB702442BFBF2FAF02C031E9DD66EE@xmb-sjc-21e.amer.cisco.com> <434C0FAC.7090805@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@dino-lnx.cisco.com Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:11:09 -0000 Status: RO Content-Length: 345 >> RBridges neither forward nor generate BPDUs. Radia this implies that two bridges cannot use an RBridges network as transit? This is not true in the case where the two bridges were connected to a multi-access ethernet with real hosts on them. I think the model could be the same and think is desirable to be the same. Dino 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 j9BK6lL29935; Tue, 11 Oct 2005 13:06:47 -0700 (PDT) Message-ID: <434C1AE2.3090605@isi.edu> Date: Tue, 11 Oct 2005 13:04:50 -0700 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: ssurya@ieee.org, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.1.1128798001.23832.rbridge@postel.org> <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> In-Reply-To: <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> 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: Re: [rbridge] rbridge Digest, Vol 17, Issue 5 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, 11 Oct 2005 20:07:52 -0000 Status: RO Content-Length: 1854 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Suryaputra wrote: > > On 10/8/05, *rbridge-request@postel.org > <mailto:rbridge-request@postel.org>* <rbridge-request@postel.org > <mailto:rbridge-request@postel.org>> wrote: > > Joe Touch wrote: > > [ deleted ] > > As to the above,, here's a clarified version: > > There are three kinds of L2 devices in an rbridge: > > hosts: anything that sources/sinks L2 packets > e.g., RFC1122-style hosts, RFC1812-style routers > (routers act like hosts to L2) > > bridges: transit conventional L2 packets and source/sink/transit > spanning tree messages > > rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs > exchange routing via IS-IS, > exchange egress tables via some protocol (TBD) Hi, Stephen, > I have been following the discussion on and off recently, and am still > catching up. This is the first time I heard about egress table. Is it > the L2 address to egress Rbridge mapping? The L2 ingress address is mapped to rbridge egresses. > If yes, why do we need another > protocol to exchange those? I thought IS-IS was chosen because it is > easy to advertise those L2 addresses using its link state packet? Someone else can clarify; my understanding is that IS-IS will help with distributing the hop-by-hop forwarding tables inside the rbridge nodes (as an IGP), but doesn't have enough information to distribute egresses (that would be more what an EGP would do). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTBrhE5f5cImnZrsRAl35AKDmwxnUeLpv3RIbNGRQ/Y9fhmDNJwCeI+oY 6tQWUW7uSQG+Whv15+yx5F4= =ag4S -----END PGP SIGNATURE----- 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 j9BK4QL28870; Tue, 11 Oct 2005 13:04:26 -0700 (PDT) Message-ID: <434C1A54.2030902@isi.edu> Date: Tue, 11 Oct 2005 13:02:28 -0700 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> References: <A0A653F4CB702442BFBF2FAF02C031E9DD66D9@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <A0A653F4CB702442BFBF2FAF02C031E9DD66D9@xmb-sjc-21e.amer.cisco.com> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 20:05:23 -0000 Status: RO Content-Length: 1887 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Kreeger (kreeger) wrote: > OK, I can see how a TTL will stop loops, and would prevent duplicate > known unicasts from being delivered, but how does a TTL stop > broadcast/multicast/unknown unicast frames from being duplicated to edge > ports each time the frame comes round the loop? The multicast/broadcast packets are forwarded by one or more spanning trees. There should never be loops in those anyway as a result. Joe > Or is this considered > OK behavior in an RBridge network compared to an 802.1 bridged network? > > New to all this... - Larry > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Joe Touch > Sent: Tuesday, October 11, 2005 7:07 AM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] loops in trill networks > > There is, and that's what it's there for. > > Joe > > Mike Hughes wrote: > >>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >> >> >> >>>this might be an old discussion, but it is some time since it look at >>>it. What do we do in trill networks about transient loops, i.e. if use > > >>>link state protocols there is a possibility that we have transient >>>loops. With no TTL mechanisms those looping frames could cause quite a > > >>>bit of problem. >> >> >>Unless I've missed something, or things have changed overnight, there >>is a TTL provided in the SHIM header. >> >>Mike > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTBpUE5f5cImnZrsRAk2EAKDUBLgyz1duwtVTZyrUE8t++Z381wCdFW4L OG6Pao5gsla9YrMI+qEdiNA= =dTLU -----END PGP SIGNATURE----- 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 j9BJkWL21959 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:46:32 -0700 (PDT) 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 <0IO700H1RO9FXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:46:27 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HEBO9E1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:46:27 -0700 (PDT) Date: Tue, 11 Oct 2005 12:46:27 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <313680C9A886D511A06000204840E1CF0C885F5C@whq-msgusr-02.pit.comms.marconi.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C1693.9050509@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: <313680C9A886D511A06000204840E1CF0C885F5C@whq-msgusr-02.pit.comms.marconi.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] loops in trill networks 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, 11 Oct 2005 19:46:45 -0000 Status: RO Content-Length: 4129 The intention is that deployment not have to be careful. If two of an RBridge's ports are connected to the same bridged broadcast domain (i.e., there is a bridge-connected path between the two ports), then the RBridge will think it has two ports connected to the same link. Which is OK. It won't forward any packets, including not BPDUs, between those ports. At most one of its ports will become "designated" for sourcing/sinking unencapsulated traffic to/from that link. It would be just like a router having two ports connected to the same link, which should work with no problem. Radia Gray, Eric wrote: >Radia, > > If I am understanding what you are saying correctly, >there are some deployment issues with Rbridges into a 802.1 >bridged environment. > > The deployment issues arise when individual RBridges >are installed, if this is not carefully planned in advance. >If an Rbridge is installed on a link where it is connected >to two or more 802.1 bridges and there is another L2 path >between those two bridges, the RBridge will either have to >forward BPDUs or - like a router - recognize that multiple >ports are connected to the same LAN. > > Is there an intention that the latter would be the >default case until and unless the installed RBridge is able >to discover a connected RBridge peer? > >-- >Eric Gray > >--> -----Original Message----- >--> From: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org]On >--> Behalf Of Radia Perlman >--> Sent: Tuesday, October 11, 2005 12:44 PM >--> To: Developing a hybrid router/bridge. >--> Subject: Re: [rbridge] loops in trill networks >--> >--> >--> There's nothing an RBridge can do about loops consisting of >--> just bridges. >--> Which is why it's good to partition the spanning trees formed by the >--> bridges so that the remaining spanning trees are as small, >--> and therefore >--> as stable, as possible. >--> >--> RBridges are like routers. They sit at a layer above >--> bridges. The bridges >--> form what looks like a single link to the RBridges. If >--> there are a bunch >--> of bridges connecting a bunch of segments, all the RBridges >--> attached to >--> that portion of the network see that bridged segment as a >--> single link. >--> >--> Radia >--> >--> Loa Andersson wrote: >--> >--> >Oh, yes it is true ... >--> > >--> >but I thought that a trill network could consist of a mixed >--> >of rbridges and the type of bridges that exist today, if that >--> >is the case you can possibly form the loop over only non-rbridges >--> > >--> >but I'm not up to speed on this, there might be a way to handle >--> >this also >--> > >--> >/Loa >--> > >--> >Joe Touch wrote: >--> > >--> > >--> >>There is, and that's what it's there for. >--> >> >--> >>Joe >--> >> >--> >>Mike Hughes wrote: >--> >> >--> >> >--> >> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >--> >>> >--> >>> >--> >>> >--> >>> >--> >>> >--> >>>>this might be an old discussion, but it is some time since it >--> >>>>look at it. What do we do in trill networks about transient >--> >>>>loops, i.e. if use link state protocols there is a possibility >--> >>>>that we have transient loops. With no TTL mechanisms >--> those looping >--> >>>>frames could cause quite a bit of problem. >--> >>>> >--> >>>> >--> >>>Unless I've missed something, or things have changed >--> overnight, there is a >--> >>>TTL provided in the SHIM header. >--> >>> >--> >>>Mike >--> >>> >--> >>> >--> >>>--------------------------------------------------------- >--> --------------- >--> >>> >--> >>>_______________________________________________ >--> >>>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 j9BJVEL17288 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:31:14 -0700 (PDT) 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 j9BJV8Uk023528 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:31:08 -0400 (EDT) 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 PAA13338 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:31:08 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPDW33>; Tue, 11 Oct 2005 16:31:07 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F5C@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, 11 Oct 2005 16:31:05 -0300 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] loops in trill networks 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, 11 Oct 2005 19:31:46 -0000 Status: RO Content-Length: 3252 Radia, If I am understanding what you are saying correctly, there are some deployment issues with Rbridges into a 802.1 bridged environment. The deployment issues arise when individual RBridges are installed, if this is not carefully planned in advance. If an Rbridge is installed on a link where it is connected to two or more 802.1 bridges and there is another L2 path between those two bridges, the RBridge will either have to forward BPDUs or - like a router - recognize that multiple ports are connected to the same LAN. Is there an intention that the latter would be the default case until and unless the installed RBridge is able to discover a connected RBridge peer? -- Eric Gray --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Radia Perlman --> Sent: Tuesday, October 11, 2005 12:44 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> There's nothing an RBridge can do about loops consisting of --> just bridges. --> Which is why it's good to partition the spanning trees formed by the --> bridges so that the remaining spanning trees are as small, --> and therefore --> as stable, as possible. --> --> RBridges are like routers. They sit at a layer above --> bridges. The bridges --> form what looks like a single link to the RBridges. If --> there are a bunch --> of bridges connecting a bunch of segments, all the RBridges --> attached to --> that portion of the network see that bridged segment as a --> single link. --> --> Radia --> --> Loa Andersson wrote: --> --> >Oh, yes it is true ... --> > --> >but I thought that a trill network could consist of a mixed --> >of rbridges and the type of bridges that exist today, if that --> >is the case you can possibly form the loop over only non-rbridges --> > --> >but I'm not up to speed on this, there might be a way to handle --> >this also --> > --> >/Loa --> > --> >Joe Touch wrote: --> > --> > --> >>There is, and that's what it's there for. --> >> --> >>Joe --> >> --> >>Mike Hughes wrote: --> >> --> >> --> >> --> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: --> >>> --> >>> --> >>> --> >>> --> >>> --> >>>>this might be an old discussion, but it is some time since it --> >>>>look at it. What do we do in trill networks about transient --> >>>>loops, i.e. if use link state protocols there is a possibility --> >>>>that we have transient loops. With no TTL mechanisms --> those looping --> >>>>frames could cause quite a bit of problem. --> >>>> --> >>>> --> >>>Unless I've missed something, or things have changed --> overnight, there is a --> >>>TTL provided in the SHIM header. --> >>> --> >>>Mike --> >>> --> >>> --> >>>--------------------------------------------------------- --> --------------- --> >>> --> >>>_______________________________________________ --> >>>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 j9BJLXL13809 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:21:34 -0700 (PDT) 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 j9BJLRUk023313 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:21:28 -0400 (EDT) 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 PAA12140 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:21:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPDWC5>; Tue, 11 Oct 2005 16:21:26 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F5B@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, 11 Oct 2005 16:21:19 -0300 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] loops in trill networks 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, 11 Oct 2005 19:22:11 -0000 Status: RO Content-Length: 3963 Larry, You've got the sense of Radia's reply reversed. It's the 802.1 bridges that look like a single link to the RBridges. This is pretty much how I expected this to work. A cloud of 802.1 bridges MUST be completely enclosed in either RBridges or routers. Rbridges - like routers - do not forward BPDUs. -- Eric --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org]On --> Behalf Of Larry Kreeger (kreeger) --> Sent: Tuesday, October 11, 2005 3:01 PM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> --> OK, it looks like I asked my previous question prematurely. --> --> If I understand this response correctly, since an RBridge --> looks like a --> single link to the 802.1 bridges, this implies that an --> RBridge receiving --> a BPDU will flood the BPDU to all edge ports. --> --> Now back to the previous message I sent about loops and --> TTL. I think --> this means that during an RBridge topology change, these --> BPDUs could get --> duplicated as they loop around (before TTL expires). --> --> How kindly will 802.1 bridges react to receiving duplicate BPDUs? --> --> - Larry --> --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Radia Perlman --> Sent: Tuesday, October 11, 2005 9:44 AM --> To: Developing a hybrid router/bridge. --> Subject: Re: [rbridge] loops in trill networks --> --> There's nothing an RBridge can do about loops consisting of just --> bridges. --> Which is why it's good to partition the spanning trees formed by the --> bridges so that the remaining spanning trees are as small, --> and therefore --> as stable, as possible. --> --> RBridges are like routers. They sit at a layer above bridges. The --> bridges form what looks like a single link to the RBridges. --> If there are --> a bunch of bridges connecting a bunch of segments, all the RBridges --> attached to that portion of the network see that bridged --> segment as a --> single link. --> --> Radia --> --> Loa Andersson wrote: --> --> >Oh, yes it is true ... --> > --> >but I thought that a trill network could consist of a --> mixed of rbridges --> --> >and the type of bridges that exist today, if that is the --> case you can --> >possibly form the loop over only non-rbridges --> > --> >but I'm not up to speed on this, there might be a way to --> handle this --> >also --> > --> >/Loa --> > --> >Joe Touch wrote: --> > --> > --> >>There is, and that's what it's there for. --> >> --> >>Joe --> >> --> >>Mike Hughes wrote: --> >> --> >> --> >> --> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: --> >>> --> >>> --> >>> --> >>> --> >>> --> >>>>this might be an old discussion, but it is some time --> since it look --> >>>>at it. What do we do in trill networks about transient --> loops, i.e. --> >>>>if use link state protocols there is a possibility that we have --> >>>>transient loops. With no TTL mechanisms those looping --> frames could --> >>>>cause quite a bit of problem. --> >>>> --> >>>> --> >>>Unless I've missed something, or things have changed --> overnight, there --> --> >>>is a TTL provided in the SHIM header. --> >>> --> >>>Mike --> >>> --> >>> --> >>>--------------------------------------------------------- --> ------------ --> >>>--- --> >>> --> >>>_______________________________________________ --> >>>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 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 j9BJH5L12198 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:17:05 -0700 (PDT) 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 <0IO700H0VMWCXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:17:00 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700HA4MWB1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:17:00 -0700 (PDT) Date: Tue, 11 Oct 2005 12:17:00 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9DD66EE@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C0FAC.7090805@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: <A0A653F4CB702442BFBF2FAF02C031E9DD66EE@xmb-sjc-21e.amer.cisco.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] loops in trill networks 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, 11 Oct 2005 19:18:18 -0000 Status: RO Content-Length: 3393 No. I think I managed to confuse you (Larry Kreeger). Sorry about that. RBridges see a whole bridge-connected set of links as a single link. Bridges do not see RBridges that way. Bridges see RBridges as just endnodes. RBridges neither forward nor generate BPDUs. Radia Larry Kreeger (kreeger) wrote: >OK, it looks like I asked my previous question prematurely. > >If I understand this response correctly, since an RBridge looks like a >single link to the 802.1 bridges, this implies that an RBridge receiving >a BPDU will flood the BPDU to all edge ports. > >Now back to the previous message I sent about loops and TTL. I think >this means that during an RBridge topology change, these BPDUs could get >duplicated as they loop around (before TTL expires). > >How kindly will 802.1 bridges react to receiving duplicate BPDUs? > > - Larry > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Radia Perlman >Sent: Tuesday, October 11, 2005 9:44 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] loops in trill networks > >There's nothing an RBridge can do about loops consisting of just >bridges. >Which is why it's good to partition the spanning trees formed by the >bridges so that the remaining spanning trees are as small, and therefore >as stable, as possible. > >RBridges are like routers. They sit at a layer above bridges. The >bridges form what looks like a single link to the RBridges. If there are >a bunch of bridges connecting a bunch of segments, all the RBridges >attached to that portion of the network see that bridged segment as a >single link. > >Radia > >Loa Andersson wrote: > > > >>Oh, yes it is true ... >> >>but I thought that a trill network could consist of a mixed of rbridges >> >> > > > >>and the type of bridges that exist today, if that is the case you can >>possibly form the loop over only non-rbridges >> >>but I'm not up to speed on this, there might be a way to handle this >>also >> >>/Loa >> >>Joe Touch wrote: >> >> >> >> >>>There is, and that's what it's there for. >>> >>>Joe >>> >>>Mike Hughes wrote: >>> >>> >>> >>> >>> >>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>this might be an old discussion, but it is some time since it look >>>>>at it. What do we do in trill networks about transient loops, i.e. >>>>>if use link state protocols there is a possibility that we have >>>>>transient loops. With no TTL mechanisms those looping frames could >>>>>cause quite a bit of problem. >>>>> >>>>> >>>>> >>>>> >>>>Unless I've missed something, or things have changed overnight, there >>>> >>>> > > > >>>>is a TTL provided in the SHIM header. >>>> >>>>Mike >>>> >>>> >>>>--------------------------------------------------------------------- >>>>--- >>>> >>>>_______________________________________________ >>>>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 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 j9BJBML10597 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:11:22 -0700 (PDT) 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 <0IO700H0LMMTXY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:11:17 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700H9AMMS1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:11:17 -0700 (PDT) Date: Tue, 11 Oct 2005 12:11:18 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9DD66DE@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C0E56.7050108@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: <A0A653F4CB702442BFBF2FAF02C031E9DD66DE@xmb-sjc-21e.amer.cisco.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] loops in trill networks 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, 11 Oct 2005 19:11:43 -0000 Status: RO Content-Length: 2684 RBridges do not participate in the 802.1d spanning tree. The neither generate nor forward spanning tree messages. They look to bridges like routers do today. If you had a big 802.1d broadcast domain, and partitioned it into n pieces, with the pieces connected with RBridges (and not with bridges), you'd wind up with n spanning trees that did not see each other. Radia Larry Kreeger (kreeger) wrote: >This brings up another question. > >What does the RBridge network look like to the 802.1 bridged network. >Does the RBridge network pretend it is a giant 802.1D bridge - >exchanging BPDUs at its edge ports with the 802.1 bridges and blocking >edge ports if it detects a loop? What happens to the BPDUs sent by >802.1 bridges to the RBridges? > > - Larry > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Joe Touch >Sent: Tuesday, October 11, 2005 8:26 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] loops in trill networks > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Loa Andersson wrote: > > >>Oh, yes it is true ... >> >>but I thought that a trill network could consist of a mixed of >>rbridges and the type of bridges that exist today, if that is the case >> >> > > > >>you can possibly form the loop over only non-rbridges >> >> > >The conventional bridges have a spanning tree, which is what already >prevents such loops currently. > >Think of the path between two nodes (hosts, routers, etc. - anything >that sources/sinks L2 frames) as having three components (at most): > >node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node > >the ingress (bridgepath1) and egress (bridgepath2) conventional bridge >paths use spanning trees, so they can't have loops. > >The rbridge uses the TTL, so it can't have a loop at its layer. Even >when it tunnels over conventional bridges ('inside' the rbridge, in a >sense), those can't have loops because they're spanning-tree. > >The combination of spanning tree in all bridge paths and TTL in the >rbridge logical path prevents loops in the node-node path. > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDS9mbE5f5cImnZrsRAktMAJ9MjJKSh87vJbfpJ4K0i+VDGJVRAQCdEbOH >krcExxOH/y9ZuHOYMynTEIA= >=3VVZ >-----END PGP SIGNATURE----- >_______________________________________________ >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 eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BJA1L10253 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:10:01 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5601325808E for <rbridge@postel.org>; Tue, 11 Oct 2005 21:09:31 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22425-07 for <rbridge@postel.org>; Tue, 11 Oct 2005 21:09:28 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id EBF20258084 for <rbridge@postel.org>; Tue, 11 Oct 2005 21:09:27 +0200 (CEST) Date: Tue, 11 Oct 2005 21:09:54 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <2F1B97FA2C3CF5C6E7E2F754@gloppen.hjemme.alvestrand.no> In-Reply-To: <6280db520510111117p4f6953d3w651a4e5d931bf60@mail.gmail.com> References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> <434BEBD5.9040401@sun.com> <6280db520510111041h1c8be79fj63b43cc696e34643@mail.gmail.com> <434BFE55.7030002@sun.com> <6280db520510111117p4f6953d3w651a4e5d931bf60@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 19:10:43 -0000 Status: RO Content-Length: 544 --On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas <akatlas@gmail.com> wrote: > All the IETF protocols, I believe, are designed to withstand some packet > reordering (and should, in my opinion, any well designed protocol). > > > > Sure - anything on top of IP isn't an issue. My concern was other stuff. Reordering (anything that places a packet more than 3 places out of its proper position in the TCP stream) will trigger TCP duplicate acks, and therefore retransmissions. These play hell with performance. No numbers...... 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 j9BJ8XL09532 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:08:33 -0700 (PDT) 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 <0IO700H0HMI3XY00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:08:27 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700H8UMI31600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:08:27 -0700 (PDT) Date: Tue, 11 Oct 2005 12:08:28 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <BC468F3648F16146B9FA9123627514F8D6701C@xmb-sjc-217.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C0DAC.4060500@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: <BC468F3648F16146B9FA9123627514F8D6701C@xmb-sjc-217.amer.cisco.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] loops in trill networks 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, 11 Oct 2005 19:08:52 -0000 Status: RO Content-Length: 4658 Just like current bridges, if there were a temporary loop, would duplicate packets, RBridges would also, but more safely because of the hop count. Radia Michael Smith (michsmit) wrote: >How about packet duplication ? With unknown unicasts packets following >the spanning tree, there is the potential for unicast packets to be >duplicated and multiple copies received by the destination with or >without TTL. I don't believe current routing introduces packet >duplication for unicast packets. I'm not sure how non-IP protocols >would behave in this case. > >Michael > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >> >>I'm not sure what protocols there are that need absolute >>ordering guarantees. >>RSTP can reorder sometimes after a topology change, so >>apparently occasional reordering is not considered a problem. >>All the IETF protocols, I believe, are designed to withstand >>some packet reordering (and should, in my opinion, any well >>designed protocol). >> >>Radia >> >>Alia Atlas wrote: >> >> >> >>>What about potential frame reordering >>>during the routing convergence? Is this a concern? >>> >>>Alia >>> >>>On 10/11/05, *Radia Perlman* <Radia.Perlman@sun.com >>><mailto:Radia.Perlman@sun.com>> wrote: >>> >>> There's nothing an RBridge can do about loops consisting of just >>> bridges. >>> Which is why it's good to partition the spanning trees >>> >>> >>formed by the >> >> >>> bridges so that the remaining spanning trees are as small, and >>> therefore >>> as stable, as possible. >>> >>> RBridges are like routers. They sit at a layer above >>> >>> >>bridges. The >> >> >>> bridges >>> form what looks like a single link to the RBridges. If >>> >>> >>there are a >> >> >>> bunch >>> of bridges connecting a bunch of segments, all the RBridges >>> attached to >>> that portion of the network see that bridged segment as >>> >>> >>a single link. >> >> >>> Radia >>> >>> Loa Andersson wrote: >>> >>> >Oh, yes it is true ... >>> > >>> >but I thought that a trill network could consist of a mixed >>> >of rbridges and the type of bridges that exist today, if that >>> >is the case you can possibly form the loop over only >>> >>> >>non-rbridges >> >> >>> > >>> >but I'm not up to speed on this, there might be a way to handle >>> >this also >>> > >>> >/Loa >>> > >>> >Joe Touch wrote: >>> > >>> > >>> >>There is, and that's what it's there for. >>> >> >>> >>Joe >>> >> >>> >>Mike Hughes wrote: >>> >> >>> >> >>> >> >>> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se >>> <mailto:loa@pi.se>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>>this might be an old discussion, but it is some >>> >>> >>time since it >> >> >>> >>>>look at it. What do we do in trill networks about transient >>> >>>>loops, i.e. if use link state protocols there is a >>> >>> >>possibility >> >> >>> >>>>that we have transient loops. With no TTL >>> >>> >>mechanisms those looping >> >> >>> >>>>frames could cause quite a bit of problem. >>> >>>> >>> >>>> >>> >>>Unless I've missed something, or things have changed >>> >>> >>overnight, >> >> >>> there is a >>> >>>TTL provided in the SHIM header. >>> >>> >>> >>>Mike >>> >>> >>> >>> >>> >>> >>> >>>>>----------------------------------------------------------- >>>>> >>>>> >>------------- >> >> >>> >>> >>> >>>_______________________________________________ >>> >>>rbridge mailing list >>> >>>rbridge@postel.org <mailto:rbridge@postel.org> >>> >>> http://www.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >>> > >>> > >>> > >>> > >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org <mailto: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 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 j9BJ5DL08231 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:05:13 -0700 (PDT) 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 <0IO700H0EMCJXX00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:05:07 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700H8HMCJ1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:05:07 -0700 (PDT) Date: Tue, 11 Oct 2005 12:05:08 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <A0A653F4CB702442BFBF2FAF02C031E9DD66D9@xmb-sjc-21e.amer.cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C0CE4.5060409@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: <A0A653F4CB702442BFBF2FAF02C031E9DD66D9@xmb-sjc-21e.amer.cisco.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] loops in trill networks 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, 11 Oct 2005 19:06:10 -0000 Status: RO Content-Length: 1626 If there is a loop, then packets whether they are unicast or multicast, will be delivered multiple times, within the limit of the TTL. Radia Larry Kreeger (kreeger) wrote: >OK, I can see how a TTL will stop loops, and would prevent duplicate >known unicasts from being delivered, but how does a TTL stop >broadcast/multicast/unknown unicast frames from being duplicated to edge >ports each time the frame comes round the loop? Or is this considered >OK behavior in an RBridge network compared to an 802.1 bridged network? > >New to all this... - Larry > >-----Original Message----- >From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Joe Touch >Sent: Tuesday, October 11, 2005 7:07 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] loops in trill networks > >There is, and that's what it's there for. > >Joe > >Mike Hughes wrote: > > >>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >> >> >> >> >>>this might be an old discussion, but it is some time since it look at >>>it. What do we do in trill networks about transient loops, i.e. if use >>> >>> > > > >>>link state protocols there is a possibility that we have transient >>>loops. With no TTL mechanisms those looping frames could cause quite a >>> >>> > > > >>>bit of problem. >>> >>> >>Unless I've missed something, or things have changed overnight, there >>is a TTL provided in the SHIM header. >> >>Mike >> >> >_______________________________________________ >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 j9BJ2wL07474 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:02:58 -0700 (PDT) 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 j9BJ2qUk022722 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:02:52 -0400 (EDT) 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 PAA09524 for <rbridge@postel.org>; Tue, 11 Oct 2005 15:02:52 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <THFPDVLG>; Tue, 11 Oct 2005 16:02:51 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F5A@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, 11 Oct 2005 16:02:40 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE96.5A5318FE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 19:03:43 -0000 Status: RO Content-Length: 9792 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5CE96.5A5318FE Content-Type: text/plain; charset="iso-8859-1" Alia/Radia, Frame (re)ordering was a critical consideration back in the days of specifying LAN Emulation over ATM. There were - at that time - a few protocols, used for example in synchronizing sales or accounting data, that assumed in-order frame delivery. I'm not sure, but I think NetBios may have been one of those protocols. I do not know similar protocols no longer exist and, short of under- taking a major research project to verify that no such protocols do exist, I believe we should assume that in-order frame delivery may still be a requirement. In terms of critiqueing protocols in general for their (in)ability to deal with (re)ordering, there is an inefficiency inherent in assuming that all protocols at all levels can handle re-ordering. Many protocols designed to run over an essentially wire-like media assume things can't jump over each other on the wire. However, it's probably reasonable - at this point in technology usage - to define protocols that are optimized for _somewhat_ order independent frame delivery, relying on the fact that a majority of higher level protocols currently in use can deal with some frame re-ordering. BTW, I believe it's reasonably well-known that IP doesn't deal perfectly with re-ordering either because there's a cost associated with having to do so and IP - itself - is optimized for the assumption of in-order delivery. -- Eric -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]On Behalf Of Alia Atlas Sent: Tuesday, October 11, 2005 2:18 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks On 10/11/05, Radia Perlman < Radia.Perlman@sun.com <mailto:Radia.Perlman@sun.com> > wrote: I'm not sure what protocols there are that need absolute ordering guarantees. Likewise, but I thought that Ethernet had that constraint. RSTP can reorder sometimes after a topology change, so apparently occasional reordering is not considered a problem. It might be useful to have a small amount of text about that. All the IETF protocols, I believe, are designed to withstand some packet reordering (and should, in my opinion, any well designed protocol). Sure - anything on top of IP isn't an issue. My concern was other stuff. Alia Radia Alia Atlas wrote: > What about potential frame reordering > during the routing convergence? Is this a concern? > > Alia ------_=_NextPart_001_01C5CE96.5A5318FE Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>Alia/Radia,</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=513592818-11102005> <FONT face=Arial color=#0000ff size=2>Frame (re)ordering was a critical consideration back in the days of</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>specifying LAN Emulation over ATM. There were - at that time - a few</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>protocols, used for example in synchronizing sales or accounting data,</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>that assumed in-order frame delivery. I'm not sure, but I think NetBios</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>may have been one of those protocols.</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=513592818-11102005> <FONT face=Arial color=#0000ff size=2>I do not know similar protocols no longer exist and, short of under-</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>taking </FONT></SPAN><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>a major research project to verify that no such protocols do exist,</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>I believe we should assume that in-order frame delivery may still be a</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>requirement.</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=513592818-11102005> <FONT face=Arial color=#0000ff size=2>In terms of critiqueing protocols in general for their (in)ability to deal</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>with (re)ordering, there is an inefficiency inherent in assuming that all</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>protocols at all levels can handle re-ordering. Many protocols designed</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>to run over an essentially wire-like media assume things can't jump over</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>each other on the wire.</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=513592818-11102005> <FONT face=Arial color=#0000ff size=2>However, it's probably reasonable - at this point in technology usage -</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>to define protocols that are optimized for _somewhat_ order independent</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>frame delivery, relying on the fact that a majority of higher level protocols</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>currently in use can deal with some frame re-ordering.</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=513592818-11102005> <FONT face=Arial color=#0000ff size=2>BTW, I believe it's reasonably well-known that IP doesn't deal perfectly</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>with re-ordering either because there's a cost associated with having to</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>do so and IP - itself - is optimized for the assumption of in-order delivery.</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>--</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>Eric</FONT></SPAN></DIV> <DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]<B>On Behalf Of </B>Alia Atlas<BR><B>Sent:</B> Tuesday, October 11, 2005 2:18 PM<BR><B>To:</B> Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] loops in trill networks<BR><BR></FONT></DIV>On 10/11/05, <B class=gmail_sendername>Radia Perlman</B> <<A href="mailto:Radia.Perlman@sun.com">Radia.Perlman@sun.com</A>> wrote: <DIV><SPAN class=gmail_quote></SPAN> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">I'm not sure what protocols there are that need absolute ordering<BR>guarantees.</BLOCKQUOTE> <DIV><BR>Likewise, but I thought that Ethernet had that constraint. <BR></DIV><BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">RSTP can reorder sometimes after a topology change, so apparently<BR>occasional reordering is not considered a problem. </BLOCKQUOTE> <DIV><BR>It might be useful to have a small amount of text about that.<BR></DIV><BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">All the IETF protocols, I believe, are designed to withstand some packet<BR>reordering (and should, in my opinion, any well designed protocol). </BLOCKQUOTE> <DIV><BR>Sure - anything on top of IP isn't an issue. My concern was other stuff.<BR><BR>Alia <BR></DIV><BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Radia<BR><BR>Alia Atlas wrote:<BR><BR>> What about potential frame reordering<BR>> during the routing convergence? Is this a concern?<BR>><BR>> Alia</BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C5CE96.5A5318FE-- 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 j9BJ2gL07391 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:02:42 -0700 (PDT) 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 <0IO700H08M8CXX00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:02:36 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700H82M8C1600@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 12:02:36 -0700 (PDT) Date: Tue, 11 Oct 2005 12:02:37 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> To: ssurya@ieee.org, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434C0C4D.6020904@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: <mailman.1.1128798001.23832.rbridge@postel.org> <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.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] rbridge Digest, Vol 17, Issue 5 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, 11 Oct 2005 19:03:42 -0000 Status: RO Content-Length: 2953 I was actually talking with Joe about a good name for that table. There is the forwarding table, which maps egress RBridge to next hop. There is the link state database, which talks about connectivity between RBridges. Then there's what I'd call the endnode table (and Joe is calling the egress table), which maps endnode membership to egress RBridge. It would be nice to have an agreed-upon name for it that everyone will know what is being referred to. I don't care about names. But back to your question...why can't IS-IS advertise those addresses in link state packets? Yes, it is the obvious choice in the absence of VLANs, because in that case, all the RBridges would need to know about all the endnodes. If there are lots of VLANs, then if an RBridge is not attached to VLAN A (none of its ports source or sink packets for VLAN A, though they can be used as transit links for VLAN A packets), it does not need to know where the VLAN A endnodes are located. Only the ingress RBridge (which would be connected to a port on VLAN A) would look up the mapping from endnode to egress RBridge, and stick the egress RBridge in the shim header. So...how should VLAN A endnode membership be passed around? There are various choices: a) in one instance of IS-IS, along with the RBridge topology information b) have an instance of IS-IS per VLAN, just for passing around the endnode information for that VLAN. This would be a fairly trivial subset of IS-IS, because there is no forwarding of link state information. The VLAN A instance of IS-IS would use the VLAN A broadcast domain created by the main IS-IS instance, to have each RBridge in VLAN A announce its directly attached VLAN A endnodes c) have some other protocol, simpler than IS-IS (because link state information never needs to be forwarded), that just sends out endnode information. I believe the IS-IS people preferred multiple instances of IS-IS, one per VLAN. The advantage of not putting this information into the main instance is that if R is not attached to VLAN A, it will not need to store this information. In either case, R would not need to look at it, but if it's one instance, R needs to store it for the reliable link state flooding. If it's a VLAN A instance layered over, then R will be forwarding this endnode reachability information, but just as datagrams. This was discussed a couple of months ago. I'm not sure anyone had strong opinions about it, but hopefully people understand the issue. And hopefully somewhere in there I answered your question. Radia > I have been following the discussion on and off recently, and am still > catching up. This is the first time I heard about egress table. Is it > the L2 address to egress Rbridge mapping? If yes, why do we need > another protocol to exchange those? I thought IS-IS was chosen because > it is easy to advertise those L2 addresses using its link state packet? > > Thanks. > > > Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BJ1BL07030 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:01:11 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2005 12:01:03 -0700 X-IronPort-AV: i="3.97,199,1125903600"; d="scan'208"; a="665158966:sNHT34979760" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9BJ0Vv1003804 for <rbridge@postel.org>; Tue, 11 Oct 2005 12:01:01 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 12:01:00 -0700 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: Tue, 11 Oct 2005 12:00:59 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD66EE@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOhIJtBq/1iefBQICGEGXmBuOL6wAEN9VQ From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 19:01:00.0881 (UTC) FILETIME=[1EE72C10:01C5CE96] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BJ1BL07030 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 19:01:44 -0000 Status: RO Content-Length: 2717 OK, it looks like I asked my previous question prematurely. If I understand this response correctly, since an RBridge looks like a single link to the 802.1 bridges, this implies that an RBridge receiving a BPDU will flood the BPDU to all edge ports. Now back to the previous message I sent about loops and TTL. I think this means that during an RBridge topology change, these BPDUs could get duplicated as they loop around (before TTL expires). How kindly will 802.1 bridges react to receiving duplicate BPDUs? - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Tuesday, October 11, 2005 9:44 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks There's nothing an RBridge can do about loops consisting of just bridges. Which is why it's good to partition the spanning trees formed by the bridges so that the remaining spanning trees are as small, and therefore as stable, as possible. RBridges are like routers. They sit at a layer above bridges. The bridges form what looks like a single link to the RBridges. If there are a bunch of bridges connecting a bunch of segments, all the RBridges attached to that portion of the network see that bridged segment as a single link. Radia Loa Andersson wrote: >Oh, yes it is true ... > >but I thought that a trill network could consist of a mixed of rbridges >and the type of bridges that exist today, if that is the case you can >possibly form the loop over only non-rbridges > >but I'm not up to speed on this, there might be a way to handle this >also > >/Loa > >Joe Touch wrote: > > >>There is, and that's what it's there for. >> >>Joe >> >>Mike Hughes wrote: >> >> >> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>> >>> >>> >>> >>> >>>>this might be an old discussion, but it is some time since it look >>>>at it. What do we do in trill networks about transient loops, i.e. >>>>if use link state protocols there is a possibility that we have >>>>transient loops. With no TTL mechanisms those looping frames could >>>>cause quite a bit of problem. >>>> >>>> >>>Unless I've missed something, or things have changed overnight, there >>>is a TTL provided in the SHIM header. >>> >>>Mike >>> >>> >>>--------------------------------------------------------------------- >>>--- >>> >>>_______________________________________________ >>>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 sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BIqcL03680 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:52:38 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2005 11:52:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9BIqQuf028910 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:52:31 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 11:52:26 -0700 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: Tue, 11 Oct 2005 11:52:25 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD66DE@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOeZ/JT6ZD6w/HRfOYp24z2tKiBwAGuGHw From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 18:52:26.0192 (UTC) FILETIME=[EC1FDD00:01C5CE94] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BIqcL03680 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 18:52:41 -0000 Status: RO Content-Length: 2041 This brings up another question. What does the RBridge network look like to the 802.1 bridged network. Does the RBridge network pretend it is a giant 802.1D bridge - exchanging BPDUs at its edge ports with the 802.1 bridges and blocking edge ports if it detects a loop? What happens to the BPDUs sent by 802.1 bridges to the RBridges? - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Tuesday, October 11, 2005 8:26 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Loa Andersson wrote: > Oh, yes it is true ... > > but I thought that a trill network could consist of a mixed of > rbridges and the type of bridges that exist today, if that is the case > you can possibly form the loop over only non-rbridges The conventional bridges have a spanning tree, which is what already prevents such loops currently. Think of the path between two nodes (hosts, routers, etc. - anything that sources/sinks L2 frames) as having three components (at most): node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node the ingress (bridgepath1) and egress (bridgepath2) conventional bridge paths use spanning trees, so they can't have loops. The rbridge uses the TTL, so it can't have a loop at its layer. Even when it tunnels over conventional bridges ('inside' the rbridge, in a sense), those can't have loops because they're spanning-tree. The combination of spanning tree in all bridge paths and TTL in the rbridge logical path prevents loops in the node-node path. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDS9mbE5f5cImnZrsRAktMAJ9MjJKSh87vJbfpJ4K0i+VDGJVRAQCdEbOH krcExxOH/y9ZuHOYMynTEIA= =3VVZ -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BInRL02907 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:49:27 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2005 11:49:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9BIn99G006291 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:49:20 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 11:49:19 -0700 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: Tue, 11 Oct 2005 11:49:19 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E9DD66D9@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXObjwKwKpE11ZYTcqVPQeXkZQJlgAJcz6Q From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 18:49:19.0921 (UTC) FILETIME=[7D192A10:01C5CE94] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BInRL02907 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 18:49:43 -0000 Status: RO Content-Length: 1203 OK, I can see how a TTL will stop loops, and would prevent duplicate known unicasts from being delivered, but how does a TTL stop broadcast/multicast/unknown unicast frames from being duplicated to edge ports each time the frame comes round the loop? Or is this considered OK behavior in an RBridge network compared to an 802.1 bridged network? New to all this... - Larry -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Tuesday, October 11, 2005 7:07 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] loops in trill networks There is, and that's what it's there for. Joe Mike Hughes wrote: > --On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: > > >>this might be an old discussion, but it is some time since it look at >>it. What do we do in trill networks about transient loops, i.e. if use >>link state protocols there is a possibility that we have transient >>loops. With no TTL mechanisms those looping frames could cause quite a >>bit of problem. > > > Unless I've missed something, or things have changed overnight, there > is a TTL provided in the SHIM header. > > Mike Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BImrL02743 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:48:53 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2005 11:48:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9BImG9O005874 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:48:45 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 11:48:44 -0700 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: Tue, 11 Oct 2005 11:48:43 -0700 Message-ID: <BC468F3648F16146B9FA9123627514F8D6701C@xmb-sjc-217.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] loops in trill networks Thread-Index: AcXOj5CVErN31Ao/QDOUnRuBdgO+GQAA9k2g From: "Michael Smith \(michsmit\)" <michsmit@cisco.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 11 Oct 2005 18:48:44.0594 (UTC) FILETIME=[680AB120:01C5CE94] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: michsmit@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j9BImrL02743 Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 18:49:44 -0000 Status: RO Content-Length: 4073 How about packet duplication ? With unknown unicasts packets following the spanning tree, there is the potential for unicast packets to be duplicated and multiple copies received by the destination with or without TTL. I don't believe current routing introduces packet duplication for unicast packets. I'm not sure how non-IP protocols would behave in this case. Michael > -----Original Message----- > From: rbridge-bounces@postel.org > > I'm not sure what protocols there are that need absolute > ordering guarantees. > RSTP can reorder sometimes after a topology change, so > apparently occasional reordering is not considered a problem. > All the IETF protocols, I believe, are designed to withstand > some packet reordering (and should, in my opinion, any well > designed protocol). > > Radia > > Alia Atlas wrote: > > > What about potential frame reordering > > during the routing convergence? Is this a concern? > > > > Alia > > > > On 10/11/05, *Radia Perlman* <Radia.Perlman@sun.com > > <mailto:Radia.Perlman@sun.com>> wrote: > > > > There's nothing an RBridge can do about loops consisting of just > > bridges. > > Which is why it's good to partition the spanning trees > formed by the > > bridges so that the remaining spanning trees are as small, and > > therefore > > as stable, as possible. > > > > RBridges are like routers. They sit at a layer above > bridges. The > > bridges > > form what looks like a single link to the RBridges. If > there are a > > bunch > > of bridges connecting a bunch of segments, all the RBridges > > attached to > > that portion of the network see that bridged segment as > a single link. > > > > Radia > > > > Loa Andersson wrote: > > > > >Oh, yes it is true ... > > > > > >but I thought that a trill network could consist of a mixed > > >of rbridges and the type of bridges that exist today, if that > > >is the case you can possibly form the loop over only > non-rbridges > > > > > >but I'm not up to speed on this, there might be a way to handle > > >this also > > > > > >/Loa > > > > > >Joe Touch wrote: > > > > > > > > >>There is, and that's what it's there for. > > >> > > >>Joe > > >> > > >>Mike Hughes wrote: > > >> > > >> > > >> > > >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se > > <mailto:loa@pi.se>> wrote: > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>>this might be an old discussion, but it is some > time since it > > >>>>look at it. What do we do in trill networks about transient > > >>>>loops, i.e. if use link state protocols there is a > possibility > > >>>>that we have transient loops. With no TTL > mechanisms those looping > > >>>>frames could cause quite a bit of problem. > > >>>> > > >>>> > > >>>Unless I've missed something, or things have changed > overnight, > > there is a > > >>>TTL provided in the SHIM header. > > >>> > > >>>Mike > > >>> > > >>> > > > >>>----------------------------------------------------------- > ------------- > > >>> > > >>>_______________________________________________ > > >>>rbridge mailing list > > >>>rbridge@postel.org <mailto:rbridge@postel.org> > > >>> http://www.postel.org/mailman/listinfo/rbridge > > >>> > > >>> > > > > > > > > > > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org <mailto: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 wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BIZWL27875 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:35:32 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id i7so721794wra for <rbridge@postel.org>; Tue, 11 Oct 2005 11:35:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=h5jggIh/91/uhlvsDNQwaTQziKRjq8c2DeFI72RE+JybyRw519yTGkxRA397PgH3+2xW5iGTGZWGR9QINNduhw5lJDOysV+LsZf5oGGGihGBm1yOg3aTjLaW/u7/G4CF7PUqJaPsAtsIgtARCFAAg+uyjs8IjaMHuqVn4nshIaI= Received: by 10.54.86.1 with SMTP id j1mr3660897wrb; Tue, 11 Oct 2005 11:35:26 -0700 (PDT) Received: by 10.54.118.20 with HTTP; Tue, 11 Oct 2005 11:35:26 -0700 (PDT) Message-ID: <582968a0510111135h7349817fo35dd84f62739b2b4@mail.gmail.com> Date: Tue, 11 Oct 2005 14:35:26 -0400 From: Stephen Suryaputra <ssuryaputra@gmail.com> To: rbridge@postel.org In-Reply-To: <mailman.1.1128798001.23832.rbridge@postel.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2383_28051594.1129055726256" References: <mailman.1.1128798001.23832.rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ssuryaputra@gmail.com Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ssurya@ieee.org, "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, 11 Oct 2005 18:36:12 -0000 Status: RO Content-Length: 3455 ------=_Part_2383_28051594.1129055726256 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/8/05, rbridge-request@postel.org <rbridge-request@postel.org> wrote: > > Joe Touch wrote: [ deleted ] As to the above,, here's a clarified version: > > There are three kinds of L2 devices in an rbridge: > > hosts: anything that sources/sinks L2 packets > e.g., RFC1122-style hosts, RFC1812-style routers > (routers act like hosts to L2) > > bridges: transit conventional L2 packets and source/sink/transit > spanning tree messages > > rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs > exchange routing via IS-IS, > exchange egress tables via some protocol (TBD) I have been following the discussion on and off recently, and am still catching up. This is the first time I heard about egress table. Is it the L= 2 address to egress Rbridge mapping? If yes, why do we need another protocol to exchange those? I thought IS-IS was chosen because it is easy to advertise those L2 addresses using its link state packet? Thanks. ------=_Part_2383_28051594.1129055726256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <br><div><span class=3D"gmail_quote">On 10/8/05, <b class=3D"gmail_senderna= me"><a href=3D"mailto:rbridge-request@postel.org">rbridge-request@postel.or= g</a></b> <<a href=3D"mailto:rbridge-request@postel.org">rbridge-request= @postel.org </a>> wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-lef= t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1= ex;">Joe Touch wrote:</blockquote><div><br> [ deleted ] <br> </div><br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As to the above,,= here's a clarified version:<br><br>There are three kinds of L2 devices in = an rbridge: <br><br> hosts: anything tha= t sources/sinks L2 packets<br> &nb= sp; e.g., RFC1122-style hosts, RFC1812-style routers<br>  = ; (routers= act like hosts to L2)<br><br> &nb= sp;bridges: transit conventional L2 packets and source/sink/transit<br>&nbs= p; &= nbsp; spanning tree messages<br><br> rbridges: encapsulate/decap= sulate L2 packets with shim/L2 hdrs<br> = exchange routin= g via IS-IS,<br>  = ; exchange egress tables via some protocol (TBD)</blockquote><br></div>I have been following the discussion on and off recently, and am still catching up. This is the first time I heard about egress table. Is it the L2 address to egress Rbridge mapping? If yes, why do we need another protocol to exchange those? I thought IS-IS was chosen because it is easy to advertise those L2 addresses using its link state packet?<br> <br> Thanks.<br> <br> ------=_Part_2383_28051594.1129055726256-- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BIHsL20486 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:17:54 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id i7so719452wra for <rbridge@postel.org>; Tue, 11 Oct 2005 11:17:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Kw1iZRmLhEi2y+UZn32pwiuy2Mj/0lodPYcu1mx5qL4FV1aDnloOLe6gHrwoQMFX/UVLk20wrLwrdjwLcB5d6M/avl8sRo2l8yi7YcbjrUnaZ5g0uGiE/zNXryL783fZnIZ2nCn+6rplOsiwJCz7v09fm369DeJ3mpSU6ECtjF8= Received: by 10.54.129.5 with SMTP id b5mr3659881wrd; Tue, 11 Oct 2005 11:17:48 -0700 (PDT) Received: by 10.54.148.1 with HTTP; Tue, 11 Oct 2005 11:17:48 -0700 (PDT) Message-ID: <6280db520510111117p4f6953d3w651a4e5d931bf60@mail.gmail.com> Date: Tue, 11 Oct 2005 11:17:48 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <434BFE55.7030002@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27477_4853447.1129054668756" References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> <434BEBD5.9040401@sun.com> <6280db520510111041h1c8be79fj63b43cc696e34643@mail.gmail.com> <434BFE55.7030002@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 18:19:11 -0000 Status: RO Content-Length: 2729 ------=_Part_27477_4853447.1129054668756 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/11/05, Radia Perlman <Radia.Perlman@sun.com> wrote: > > I'm not sure what protocols there are that need absolute ordering > guarantees. Likewise, but I thought that Ethernet had that constraint. RSTP can reorder sometimes after a topology change, so apparently > occasional reordering is not considered a problem. It might be useful to have a small amount of text about that. All the IETF protocols, I believe, are designed to withstand some packet > reordering (and should, in my opinion, any well designed protocol). Sure - anything on top of IP isn't an issue. My concern was other stuff. Alia Radia > > Alia Atlas wrote: > > > What about potential frame reordering > > during the routing convergence? Is this a concern? > > > > Alia ------=_Part_27477_4853447.1129054668756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/11/05, <b class=3D"gmail_sendername">Radia Perlman</b> <<a href=3D= "mailto:Radia.Perlman@sun.com">Radia.Perlman@sun.com</a>> wrote:<div><sp= an class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote" style=3D"= border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi= ng-left: 1ex;"> I'm not sure what protocols there are that need absolute ordering<br>guaran= tees.</blockquote><div><br> Likewise, but I thought that Ethernet had that constraint. <br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">RSTP ca= n reorder sometimes after a topology change, so apparently<br>occasional re= ordering is not considered a problem. </blockquote><div><br> It might be useful to have a small amount of text about that.<br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">All the= IETF protocols, I believe, are designed to withstand some packet<br>reorde= ring (and should, in my opinion, any well designed protocol). </blockquote><div><br> Sure - anything on top of IP isn't an issue. My concern was other stu= ff.<br> <br> Alia <br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Radia<b= r><br>Alia Atlas wrote:<br><br>> What about potential frame reordering<b= r> > during the routing convergence? Is this a concern?<br>><= br>> Alia</blockquote></div><br> ------=_Part_27477_4853447.1129054668756-- 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 j9BI36L15980 for <rbridge@postel.org>; Tue, 11 Oct 2005 11:03:06 -0700 (PDT) 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 <0IO700H1QJH13910@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 11:03:01 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700GQHJH01M10@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 11:03:00 -0700 (PDT) Date: Tue, 11 Oct 2005 11:03:01 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <6280db520510111041h1c8be79fj63b43cc696e34643@mail.gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434BFE55.7030002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> <434BEBD5.9040401@sun.com> <6280db520510111041h1c8be79fj63b43cc696e34643@mail.gmail.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] loops in trill networks 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, 11 Oct 2005 18:03:41 -0000 Status: RO Content-Length: 3219 I'm not sure what protocols there are that need absolute ordering guarantees. RSTP can reorder sometimes after a topology change, so apparently occasional reordering is not considered a problem. All the IETF protocols, I believe, are designed to withstand some packet reordering (and should, in my opinion, any well designed protocol). Radia Alia Atlas wrote: > What about potential frame reordering > during the routing convergence? Is this a concern? > > Alia > > On 10/11/05, *Radia Perlman* <Radia.Perlman@sun.com > <mailto:Radia.Perlman@sun.com>> wrote: > > There's nothing an RBridge can do about loops consisting of just > bridges. > Which is why it's good to partition the spanning trees formed by the > bridges so that the remaining spanning trees are as small, and > therefore > as stable, as possible. > > RBridges are like routers. They sit at a layer above bridges. The > bridges > form what looks like a single link to the RBridges. If there are a > bunch > of bridges connecting a bunch of segments, all the RBridges > attached to > that portion of the network see that bridged segment as a single link. > > Radia > > Loa Andersson wrote: > > >Oh, yes it is true ... > > > >but I thought that a trill network could consist of a mixed > >of rbridges and the type of bridges that exist today, if that > >is the case you can possibly form the loop over only non-rbridges > > > >but I'm not up to speed on this, there might be a way to handle > >this also > > > >/Loa > > > >Joe Touch wrote: > > > > > >>There is, and that's what it's there for. > >> > >>Joe > >> > >>Mike Hughes wrote: > >> > >> > >> > >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se > <mailto:loa@pi.se>> wrote: > >>> > >>> > >>> > >>> > >>> > >>>>this might be an old discussion, but it is some time since it > >>>>look at it. What do we do in trill networks about transient > >>>>loops, i.e. if use link state protocols there is a possibility > >>>>that we have transient loops. With no TTL mechanisms those looping > >>>>frames could cause quite a bit of problem. > >>>> > >>>> > >>>Unless I've missed something, or things have changed overnight, > there is a > >>>TTL provided in the SHIM header. > >>> > >>>Mike > >>> > >>> > >>>------------------------------------------------------------------------ > >>> > >>>_______________________________________________ > >>>rbridge mailing list > >>>rbridge@postel.org <mailto:rbridge@postel.org> > >>> http://www.postel.org/mailman/listinfo/rbridge > >>> > >>> > > > > > > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org <mailto: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 wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BHfYL08011 for <rbridge@postel.org>; Tue, 11 Oct 2005 10:41:35 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 36so700736wra for <rbridge@postel.org>; Tue, 11 Oct 2005 10:41:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=S2SQ5xQtRRDXwSvcqm24gn0z2A/ZOxbFKiaoiAEBHG0x8Z9b+ZnXQZdr2s0LJn/OUGDw3rr4sgQ1GldbuQwbuGTOAqhvSXqbC82kBvCXx1tSjFdDwWUR74kvTg1k5fof/AWrRzZSSvUZF0ckkUR+zcbUD+x56vJDPhCgZpidW+g= Received: by 10.54.135.7 with SMTP id i7mr3328048wrd; Tue, 11 Oct 2005 10:41:29 -0700 (PDT) Received: by 10.54.148.1 with HTTP; Tue, 11 Oct 2005 10:41:29 -0700 (PDT) Message-ID: <6280db520510111041h1c8be79fj63b43cc696e34643@mail.gmail.com> Date: Tue, 11 Oct 2005 10:41:29 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <434BEBD5.9040401@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27101_23145533.1129052489164" References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> <434BEBD5.9040401@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 17:41:52 -0000 Status: RO Content-Length: 5838 ------=_Part_27101_23145533.1129052489164 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline What about potential frame reordering during the routing convergence? Is this a concern? Alia On 10/11/05, Radia Perlman <Radia.Perlman@sun.com> wrote: > > There's nothing an RBridge can do about loops consisting of just bridges. > Which is why it's good to partition the spanning trees formed by the > bridges so that the remaining spanning trees are as small, and therefore > as stable, as possible. > > RBridges are like routers. They sit at a layer above bridges. The bridges > form what looks like a single link to the RBridges. If there are a bunch > of bridges connecting a bunch of segments, all the RBridges attached to > that portion of the network see that bridged segment as a single link. > > Radia > > Loa Andersson wrote: > > >Oh, yes it is true ... > > > >but I thought that a trill network could consist of a mixed > >of rbridges and the type of bridges that exist today, if that > >is the case you can possibly form the loop over only non-rbridges > > > >but I'm not up to speed on this, there might be a way to handle > >this also > > > >/Loa > > > >Joe Touch wrote: > > > > > >>There is, and that's what it's there for. > >> > >>Joe > >> > >>Mike Hughes wrote: > >> > >> > >> > >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: > >>> > >>> > >>> > >>> > >>> > >>>>this might be an old discussion, but it is some time since it > >>>>look at it. What do we do in trill networks about transient > >>>>loops, i.e. if use link state protocols there is a possibility > >>>>that we have transient loops. With no TTL mechanisms those looping > >>>>frames could cause quite a bit of problem. > >>>> > >>>> > >>>Unless I've missed something, or things have changed overnight, there > is a > >>>TTL provided in the SHIM header. > >>> > >>>Mike > >>> > >>> > > >>>----------------------------------------------------------------------= -- > >>> > >>>_______________________________________________ > >>>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 > ------=_Part_27101_23145533.1129052489164 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline What about potential frame reordering<br> during the routing convergence? Is this a concern?<br> <br> Alia<br><br><div><span class=3D"gmail_quote">On 10/11/05, <b class=3D"gmail= _sendername">Radia Perlman</b> <<a href=3D"mailto:Radia.Perlman@sun.com"= >Radia.Perlman@sun.com</a>> wrote:</span><blockquote class=3D"gmail_quot= e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt = 0.8ex; padding-left: 1ex;"> There's nothing an RBridge can do about loops consisting of just bridges.<b= r>Which is why it's good to partition the spanning trees formed by the<br>b= ridges so that the remaining spanning trees are as small, and therefore <br>as stable, as possible.<br><br>RBridges are like routers. They sit at a= layer above bridges. The bridges<br>form what looks like a single link to = the RBridges. If there are a bunch<br>of bridges connecting a bunch of segm= ents, all the RBridges attached to <br>that portion of the network see that bridged segment as a single link.<= br><br>Radia<br><br>Loa Andersson wrote:<br><br>>Oh, yes it is true ...<= br>><br>>but I thought that a trill network could consist of a mixed <br>>of rbridges and the type of bridges that exist today, if that<br>&g= t;is the case you can possibly form the loop over only non-rbridges<br>>= <br>>but I'm not up to speed on this, there might be a way to handle <br>>this also<br>><br>>/Loa<br>><br>>Joe Touch wrote:<br>&g= t;<br>><br>>>There is, and that's what it's there for.<br>>>= <br>>>Joe<br>>><br>>>Mike Hughes wrote:<br>>><br> >><br>>><br>>>>--On 11 October 2005 15:23 +0200 Loa An= dersson <<a href=3D"mailto:loa@pi.se">loa@pi.se</a>> wrote:<br>>&g= t;><br>>>><br>>>><br>>>><br>>>><br> >>>>this might be an old discussion, but it is some time since = it<br>>>>>look at it. What do we do in trill networks about tra= nsient<br>>>>>loops, i.e. if use link state protocols there is = a possibility <br>>>>>that we have transient loops. With no TTL mechanisms th= ose looping<br>>>>>frames could cause quite a bit of problem.<b= r>>>>><br>>>>><br>>>>Unless I've missed so= mething, or things have changed overnight, there is a <br>>>>TTL provided in the SHIM header.<br>>>><br>>>= ;>Mike<br>>>><br>>>><br>>>>------------------= ------------------------------------------------------<br>>>><br> >>>_______________________________________________<br>>>>= rbridge mailing list<br>>>><a href=3D"mailto:rbridge@postel.org">r= bridge@postel.org</a><br>>>><a href=3D"http://www.postel.org/mailm= an/listinfo/rbridge"> http://www.postel.org/mailman/listinfo/rbridge</a><br>>>><br>>&= gt;><br>><br>><br>><br>><br><br>____________________________= ___________________<br>rbridge mailing list<br><a href=3D"mailto:rbridge@po= stel.org"> rbridge@postel.org</a><br><a href=3D"http://www.postel.org/mailman/listinfo= /rbridge">http://www.postel.org/mailman/listinfo/rbridge</a><br></blockquot= e></div><br> ------=_Part_27101_23145533.1129052489164-- 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 j9BGiCL18529 for <rbridge@postel.org>; Tue, 11 Oct 2005 09:44:12 -0700 (PDT) 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 <0IO700HVCFTG3900@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 09:44:04 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO700GBWFTG1M10@mail.sunlabs.com> for rbridge@postel.org; Tue, 11 Oct 2005 09:44:04 -0700 (PDT) Date: Tue, 11 Oct 2005 09:44:05 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <434BCAB1.6050605@pi.se> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <434BEBD5.9040401@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: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> 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] loops in trill networks 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, 11 Oct 2005 16:44:41 -0000 Status: RO Content-Length: 1794 There's nothing an RBridge can do about loops consisting of just bridges. Which is why it's good to partition the spanning trees formed by the bridges so that the remaining spanning trees are as small, and therefore as stable, as possible. RBridges are like routers. They sit at a layer above bridges. The bridges form what looks like a single link to the RBridges. If there are a bunch of bridges connecting a bunch of segments, all the RBridges attached to that portion of the network see that bridged segment as a single link. Radia Loa Andersson wrote: >Oh, yes it is true ... > >but I thought that a trill network could consist of a mixed >of rbridges and the type of bridges that exist today, if that >is the case you can possibly form the loop over only non-rbridges > >but I'm not up to speed on this, there might be a way to handle >this also > >/Loa > >Joe Touch wrote: > > >>There is, and that's what it's there for. >> >>Joe >> >>Mike Hughes wrote: >> >> >> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >>> >>> >>> >>> >>> >>>>this might be an old discussion, but it is some time since it >>>>look at it. What do we do in trill networks about transient >>>>loops, i.e. if use link state protocols there is a possibility >>>>that we have transient loops. With no TTL mechanisms those looping >>>>frames could cause quite a bit of problem. >>>> >>>> >>>Unless I've missed something, or things have changed overnight, there is a >>>TTL provided in the SHIM header. >>> >>>Mike >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>rbridge mailing list >>>rbridge@postel.org >>>http://www.postel.org/mailman/listinfo/rbridge >>> >>> > > > > 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 j9BFSHL23620; Tue, 11 Oct 2005 08:28:17 -0700 (PDT) Message-ID: <434BD99B.3060406@isi.edu> Date: Tue, 11 Oct 2005 08:26:19 -0700 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> References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> <434BCAB1.6050605@pi.se> In-Reply-To: <434BCAB1.6050605@pi.se> 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: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 15:28:42 -0000 Status: RO Content-Length: 1309 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Loa Andersson wrote: > Oh, yes it is true ... > > but I thought that a trill network could consist of a mixed > of rbridges and the type of bridges that exist today, if that > is the case you can possibly form the loop over only non-rbridges The conventional bridges have a spanning tree, which is what already prevents such loops currently. Think of the path between two nodes (hosts, routers, etc. - anything that sources/sinks L2 frames) as having three components (at most): node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node the ingress (bridgepath1) and egress (bridgepath2) conventional bridge paths use spanning trees, so they can't have loops. The rbridge uses the TTL, so it can't have a loop at its layer. Even when it tunnels over conventional bridges ('inside' the rbridge, in a sense), those can't have loops because they're spanning-tree. The combination of spanning tree in all bridge paths and TTL in the rbridge logical path prevents loops in the node-node path. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDS9mbE5f5cImnZrsRAktMAJ9MjJKSh87vJbfpJ4K0i+VDGJVRAQCdEbOH krcExxOH/y9ZuHOYMynTEIA= =3VVZ -----END PGP SIGNATURE----- Received: from smtp.testbed.se ([80.86.78.228]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BEOkL01576 for <rbridge@postel.org>; Tue, 11 Oct 2005 07:24:47 -0700 (PDT) Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.209]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EPL3O-0000N5-0L for rbridge@postel.org; Tue, 11 Oct 2005 16:24:40 +0200 Message-ID: <434BCAB1.6050605@pi.se> Date: Tue, 11 Oct 2005 16:22:41 +0200 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> <434BC70B.7000505@isi.edu> In-Reply-To: <434BC70B.7000505@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Spam-Report: Spam detection software, running on the system "fw.testbed.se", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Oh, yes it is true ... but I thought that a trill network could consist of a mixed of rbridges and the type of bridges that exist today, if that is the case you can possibly form the loop over only non-rbridges [...] Content analysis details: (-0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 AWL AWL: From: address is in the auto white-list X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: loa@pi.se Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 14:25:40 -0000 Status: RO Content-Length: 1424 Oh, yes it is true ... but I thought that a trill network could consist of a mixed of rbridges and the type of bridges that exist today, if that is the case you can possibly form the loop over only non-rbridges but I'm not up to speed on this, there might be a way to handle this also /Loa Joe Touch wrote: > There is, and that's what it's there for. > > Joe > > Mike Hughes wrote: > >>--On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: >> >> >> >>>this might be an old discussion, but it is some time since it >>>look at it. What do we do in trill networks about transient >>>loops, i.e. if use link state protocols there is a possibility >>>that we have transient loops. With no TTL mechanisms those looping >>>frames could cause quite a bit of problem. >> >> >>Unless I've missed something, or things have changed overnight, there is a >>TTL provided in the SHIM header. >> >>Mike >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>rbridge mailing list >>rbridge@postel.org >>http://www.postel.org/mailman/listinfo/rbridge -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BE7DL26578; Tue, 11 Oct 2005 07:07:13 -0700 (PDT) Message-ID: <434BC70B.7000505@isi.edu> Date: Tue, 11 Oct 2005 07:07:07 -0700 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> References: <434BBCBD.1050704@pi.se> <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> In-Reply-To: <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD47B57C67923AF3281D7201" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 14:07:42 -0000 Status: RO Content-Length: 1266 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD47B57C67923AF3281D7201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There is, and that's what it's there for. Joe Mike Hughes wrote: > --On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: > > >>this might be an old discussion, but it is some time since it >>look at it. What do we do in trill networks about transient >>loops, i.e. if use link state protocols there is a possibility >>that we have transient loops. With no TTL mechanisms those looping >>frames could cause quite a bit of problem. > > > Unless I've missed something, or things have changed overnight, there is a > TTL provided in the SHIM header. > > Mike --------------enigBD47B57C67923AF3281D7201 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDS8cLE5f5cImnZrsRAtjNAJ4iaqoc7sqY+cYaPr4D76cfS4x6SgCg9A9V q7fK3NsTtSBq49aqbRFOvJM= =Qjq0 -----END PGP SIGNATURE----- --------------enigBD47B57C67923AF3281D7201-- Received: from weathered.linx.net (weathered.linx.net [195.66.232.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BDV0L12968 for <rbridge@postel.org>; Tue, 11 Oct 2005 06:31:01 -0700 (PDT) Received: from [193.0.9.174] (helo=Mike_HP.smashing.net) by weathered.linx.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 1EPKDT-0006e8-00 for rbridge@postel.org; Tue, 11 Oct 2005 14:30:51 +0100 Date: Tue, 11 Oct 2005 14:30:44 +0100 From: Mike Hughes <mike@linx.net> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <BB300E3BBDF0B1E5B45034B5@Mike_HP.ripemtg.ripe.net> In-Reply-To: <434BBCBD.1050704@pi.se> References: <434BBCBD.1050704@pi.se> X-Mailer: Mulberry/3.1.6 (Win32) X-NCC-RegID: uk.linx MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mike@linx.net Subject: Re: [rbridge] loops in trill networks 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, 11 Oct 2005 13:32:03 -0000 Status: RO Content-Length: 656 --On 11 October 2005 15:23 +0200 Loa Andersson <loa@pi.se> wrote: > this might be an old discussion, but it is some time since it > look at it. What do we do in trill networks about transient > loops, i.e. if use link state protocols there is a possibility > that we have transient loops. With no TTL mechanisms those looping > frames could cause quite a bit of problem. Unless I've missed something, or things have changed overnight, there is a TTL provided in the SHIM header. Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" Received: from smtp.testbed.se ([80.86.78.228]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9BDPAL10492 for <rbridge@postel.org>; Tue, 11 Oct 2005 06:25:10 -0700 (PDT) Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.209]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EPK7k-0000Ao-RU for rbridge@postel.org; Tue, 11 Oct 2005 15:25:01 +0200 Message-ID: <434BBCBD.1050704@pi.se> Date: Tue, 11 Oct 2005 15:23:09 +0200 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Spam-Report: Spam detection software, running on the system "fw.testbed.se", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: All, this might be an old discussion, but it is some time since it look at it. What do we do in trill networks about transient loops, i.e. if use link state protocols there is a possibility that we have transient loops. With no TTL mechanisms those looping frames could cause quite a bit of problem. [...] Content analysis details: (-0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 AWL AWL: From: address is in the auto white-list X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: loa@pi.se Subject: [rbridge] loops in trill networks 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, 11 Oct 2005 13:25:38 -0000 Status: RO Content-Length: 597 All, this might be an old discussion, but it is some time since it look at it. What do we do in trill networks about transient loops, i.e. if use link state protocols there is a possibility that we have transient loops. With no TTL mechanisms those looping frames could cause quite a bit of problem. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se 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 j9ALMlL29769; Mon, 10 Oct 2005 14:22:47 -0700 (PDT) Message-ID: <434ADB30.5010501@isi.edu> Date: Mon, 10 Oct 2005 14:20:48 -0700 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> References: <43413A48.1020100@sun.com> <8FA5CF2938B9E05595D0C48E@gloppen.hjemme.alvestrand.no> <4347086E.5070706@isi.edu> <43499A23.5090100@sun.com> In-Reply-To: <43499A23.5090100@sun.com> 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: Re: [rbridge] Call for agenda items 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, 10 Oct 2005 21:23:53 -0000 Status: RO Content-Length: 1148 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Nordmark wrote: > Joe Touch wrote: > > >>Yes. The general plan we discussed at the last meeting started with >>factoring out the current document into three: >> >> 1. problem statement >> 2. architecture >> 3. protocol >> >>The current doc encompasses most of #1 and #2, but only a little of #3. >> >>I expect we will have drafts of the first two by the cutoff (where >>preliminary versions will be ready for help from contributors in a few >>days). >> >>Question: should these be individual submissions at this time, or issued >>as WG docs (since they're not listed in the charter, it's hard to see >>which way to go, though either should be fine). > > > It makes sense to keep them as individual and then we can ask the WG for > each one of them whether the WG wants to adopt them as the basis for the > WG deliverables. AOK. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDStswE5f5cImnZrsRAn5IAJ9s05QwMDZXZ+fkhqAAiI24SF0vcQCdGW0x GBWXygo2tZHequTKuz9Nso8= =zo+w -----END PGP SIGNATURE----- Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j99MUYL15052 for <rbridge@postel.org>; Sun, 9 Oct 2005 15:30:34 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j99MUUHT003087; Sun, 9 Oct 2005 15:30:31 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j99MUSet127942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 9 Oct 2005 15:30:30 -0700 (PDT) Message-ID: <43499A23.5090100@sun.com> Date: Sun, 09 Oct 2005 15:30:59 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <43413A48.1020100@sun.com> <8FA5CF2938B9E05595D0C48E@gloppen.hjemme.alvestrand.no> <4347086E.5070706@isi.edu> In-Reply-To: <4347086E.5070706@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] Call for agenda items 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: Sun, 09 Oct 2005 22:31:18 -0000 Status: RO Content-Length: 1228 Joe Touch wrote: > Yes. The general plan we discussed at the last meeting started with > factoring out the current document into three: > > 1. problem statement > 2. architecture > 3. protocol > > The current doc encompasses most of #1 and #2, but only a little of #3. > > I expect we will have drafts of the first two by the cutoff (where > preliminary versions will be ready for help from contributors in a few > days). > > Question: should these be individual submissions at this time, or issued > as WG docs (since they're not listed in the charter, it's hard to see > which way to go, though either should be fine). It makes sense to keep them as individual and then we can ask the WG for each one of them whether the WG wants to adopt them as the basis for the WG deliverables. To answer Harald's question: there is also a "trill requirements on routing protocols" draft in the works. But if there is additional things of interest (for instance, if the IS-IS extensions to support trill like things show up as an I-D), then it would be good to know since we should at least have such a thing as a FYI on the agenda (even though it would be the ISIS WG that would deal with any such extensions.) Erik 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 j97NklL25861; Fri, 7 Oct 2005 16:46:47 -0700 (PDT) Message-ID: <4347086E.5070706@isi.edu> Date: Fri, 07 Oct 2005 16:44:46 -0700 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: Harald Tveit Alvestrand <harald@alvestrand.no> References: <43413A48.1020100@sun.com> <8FA5CF2938B9E05595D0C48E@gloppen.hjemme.alvestrand.no> In-Reply-To: <8FA5CF2938B9E05595D0C48E@gloppen.hjemme.alvestrand.no> 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 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Call for agenda items 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, 07 Oct 2005 23:47:12 -0000 Status: RO Content-Length: 1641 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harald Tveit Alvestrand wrote: > Erik, Joe: > > from one of Joe's messages I get the impression that there is a > short-term plan for what documents will be written and when they will be > published. Yes. The general plan we discussed at the last meeting started with factoring out the current document into three: 1. problem statement 2. architecture 3. protocol The current doc encompasses most of #1 and #2, but only a little of #3. I expect we will have drafts of the first two by the cutoff (where preliminary versions will be ready for help from contributors in a few days). Question: should these be individual submissions at this time, or issued as WG docs (since they're not listed in the charter, it's hard to see which way to go, though either should be fine). Joe > > I assume that you as chair know what they're doing, Erik. > > Perhaps you could keep us updated on that plan, so that you can instead > call for "any OTHER items"? > > Harald > > --On mandag, oktober 03, 2005 07:03:52 -0700 Erik Nordmark > <erik.nordmark@sun.com> wrote: > >> >> What drafts and other issues will there be to discuss at Vancouver? >> >> Erik >> >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://www.postel.org/mailman/listinfo/rbridge >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRwhtE5f5cImnZrsRAk2mAJ9cIfTdlBSEgOhQZ6HAnrf/8XLNiQCgs/pE dPveMg/G5fjbuG0xpYT+PV4= =8ict -----END PGP SIGNATURE----- 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 j97Ni0L25272 for <rbridge@postel.org>; Fri, 7 Oct 2005 16:44:01 -0700 (PDT) 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 <0IO000E7JKL7NS00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 16:43:55 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO000D2EKL5EV10@mail.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 16:43:55 -0700 (PDT) Date: Fri, 07 Oct 2005 16:43:55 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4346DCB5.3010009@it.uc3m.es> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4347083B.7060607@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> <4346C0B5.4020600@isi.edu> <4346D557.6070801@sun.com> <4346DCB5.3010009@it.uc3m.es> 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] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 23:44:10 -0000 Status: RO Content-Length: 3465 RBridges are not intended to replace routers. If an organization is willing to do the configuration necessary to partition their intranet into IP subnets, partitioned with routers, then they can/should continue doing so. TRILL is really for more efficient/robust interconnection of links within an IP subnet. Radia Guillermo Ib??ez wrote: >Besides the reasons provided by Radia, there is the issue of a single >and common IP subnet for the rbridge campus. If several campuses are >connected by Rbridges instead of routers, all campuses will share the >same IP subnet. This does not seem a recommendable scenario, specially >if different authorities own/manage the different campuses networks. I >am not sure we use the term campus with the same meaning as Joe. >Guillermo > >Radia Perlman wrote: > > > >>No. I think the wording is correct as is. There aren't explicitly >>"internal" and "external" RBridges. What you >>are proposing would involve telling an RBridge which of its ports are >>"external" and which are "internal". At >>any rate, it's not necessary. In a campus, there might happen to be a >>link which is a leaf, but if one were >>to connect another RBridge to that link, you could grow the campus from >>that link. >> >>So maybe we aren't disagreeing, since there certainly might be leaf >>links. But one could imagine a topology >>in which there were no leaf links...every link has multiple RBridges and >>is used for transit, in addition to >>possibly having endnodes on it. So trying to think of which links are >>termination links would just be confusing. >> >>So RBridges do not terminate the campus. A router does, though, since >>the RBridges do not see anything >>happening on the other side of the router. >> >>Radia >> >> >> >> >> >>Joe Touch wrote: >> >> >> >> >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>> >>> >>>Saikat Ray wrote: >>> >>> >>> >>> >>> >>> >>>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A >>>>campus refers to a set of links connected by either RBridges or bridges. In >>>>other words, the campus is terminated by traditional IP routers." >>>> >>>> >>>> >>>> >>>> >>>> >>>Yeah - that seems like a bug. It seems like an rbridge campus is a set >>>of links connecting either bridges or rbridges, terminated by rbridges. >>> >>>i.e., >>> rbridges connected to internal bridges or rbridges >>> internal bridges connected to internal bridges or rbridges >>> all external links connected to rbridges only >>> (declare these 'edge' rbridges') >>> all nodes (hosts) connected via the external links >>> >>>But there don't need to be IP routers per se. >>> >>>Joe >>>-----BEGIN PGP SIGNATURE----- >>>Version: GnuPG v1.2.4 (MingW32) >>>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >>> >>>iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm >>>c7AvMwnmVQu4jfUc6hv6nlo= >>>=wdXB >>>-----END PGP SIGNATURE----- >>>_______________________________________________ >>>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 [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 j97NX5L22886; Fri, 7 Oct 2005 16:33:05 -0700 (PDT) Message-ID: <43470538.50109@isi.edu> Date: Fri, 07 Oct 2005 16:31:04 -0700 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: Joe Touch <touch@ISI.EDU> References: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> <4346C0B5.4020600@isi.edu> In-Reply-To: <4346C0B5.4020600@isi.edu> 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 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 23:33:23 -0000 Status: RO Content-Length: 2044 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: > > > Saikat Ray wrote: > >>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A >>>campus refers to a set of links connected by either RBridges or bridges. In >>>other words, the campus is terminated by traditional IP routers." > > > Yeah - that seems like a bug. It seems like an rbridge campus is a set > of links connecting either bridges or rbridges, terminated by rbridges. > > i.e., > rbridges connected to internal bridges or rbridges > internal bridges connected to internal bridges or rbridges > all external links connected to rbridges only > (declare these 'edge' rbridges') > all nodes (hosts) connected via the external links > > But there don't need to be IP routers per se. > > Joe FWIW, I did clarify this with Radia off-line. Rbridges campuses are terminated at the rbridge, largely because of an IP router or host, but it is at the rbridge that the termination exists. As to the above,, here's a clarified version: There are three kinds of L2 devices in an rbridge: hosts: anything that sources/sinks L2 packets e.g., RFC1122-style hosts, RFC1812-style routers (routers act like hosts to L2) bridges: transit conventional L2 packets and source/sink/transit spanning tree messages rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs exchange routing via IS-IS, exchange egress tables via some protocol (TBD) host-host and host-rbridge traffic may transit bridges is conventional L2 this is known as EXTERNAL TRAFFIC rbridge-rbridge traffic may transit bridges (since it looks like L2 on the outside) is shim/L2 encapsulated this is known as INTERNAL TRAFFIC I hope this helps; it's a preview of the architecture doc ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRwU3E5f5cImnZrsRAsifAJwIF++ts/oO/9EqBFQ+JXK98wUHpwCePdWb Deb50k5SnsIq6M5vgFXubTU= =yhlV -----END PGP SIGNATURE----- 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 j97KcKL00322 for <rbridge@postel.org>; Fri, 7 Oct 2005 13:38:21 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B35959D119 for <rbridge@postel.org>; Fri, 7 Oct 2005 22:38:14 +0200 (CEST) Received: from [163.117.203.219] (unknown [163.117.203.219]) by smtp01.uc3m.es (Postfix) with ESMTP id B18729D0FD for <rbridge@postel.org>; Fri, 7 Oct 2005 22:38:13 +0200 (CEST) Message-ID: <4346DCB5.3010009@it.uc3m.es> Date: Fri, 07 Oct 2005 22:38:13 +0200 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: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> <4346C0B5.4020600@isi.edu> <4346D557.6070801@sun.com> In-Reply-To: <4346D557.6070801@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gibanez@it.uc3m.es Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 20:39:12 -0000 Status: RO Content-Length: 2819 Besides the reasons provided by Radia, there is the issue of a single and common IP subnet for the rbridge campus. If several campuses are connected by Rbridges instead of routers, all campuses will share the same IP subnet. This does not seem a recommendable scenario, specially if different authorities own/manage the different campuses networks. I am not sure we use the term campus with the same meaning as Joe. Guillermo Radia Perlman wrote: >No. I think the wording is correct as is. There aren't explicitly >"internal" and "external" RBridges. What you >are proposing would involve telling an RBridge which of its ports are >"external" and which are "internal". At >any rate, it's not necessary. In a campus, there might happen to be a >link which is a leaf, but if one were >to connect another RBridge to that link, you could grow the campus from >that link. > >So maybe we aren't disagreeing, since there certainly might be leaf >links. But one could imagine a topology >in which there were no leaf links...every link has multiple RBridges and >is used for transit, in addition to >possibly having endnodes on it. So trying to think of which links are >termination links would just be confusing. > >So RBridges do not terminate the campus. A router does, though, since >the RBridges do not see anything >happening on the other side of the router. > >Radia > > > > > >Joe Touch wrote: > > > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >> >> >>Saikat Ray wrote: >> >> >> >> >>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A >>>campus refers to a set of links connected by either RBridges or bridges. In >>>other words, the campus is terminated by traditional IP routers." >>> >>> >>> >>> >>Yeah - that seems like a bug. It seems like an rbridge campus is a set >>of links connecting either bridges or rbridges, terminated by rbridges. >> >>i.e., >> rbridges connected to internal bridges or rbridges >> internal bridges connected to internal bridges or rbridges >> all external links connected to rbridges only >> (declare these 'edge' rbridges') >> all nodes (hosts) connected via the external links >> >>But there don't need to be IP routers per se. >> >>Joe >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.2.4 (MingW32) >>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >>iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm >>c7AvMwnmVQu4jfUc6hv6nlo= >>=wdXB >>-----END PGP SIGNATURE----- >>_______________________________________________ >>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 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 j97K6rL21370 for <rbridge@postel.org>; Fri, 7 Oct 2005 13:06:53 -0700 (PDT) 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 <0IO000E2IAJANS00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 13:06:46 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO000DDCAJ9EV00@mail.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 13:06:46 -0700 (PDT) Date: Fri, 07 Oct 2005 13:06:47 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4346C0B5.4020600@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4346D557.6070801@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: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> <4346C0B5.4020600@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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 20:07:09 -0000 Status: RO Content-Length: 2113 No. I think the wording is correct as is. There aren't explicitly "internal" and "external" RBridges. What you are proposing would involve telling an RBridge which of its ports are "external" and which are "internal". At any rate, it's not necessary. In a campus, there might happen to be a link which is a leaf, but if one were to connect another RBridge to that link, you could grow the campus from that link. So maybe we aren't disagreeing, since there certainly might be leaf links. But one could imagine a topology in which there were no leaf links...every link has multiple RBridges and is used for transit, in addition to possibly having endnodes on it. So trying to think of which links are termination links would just be confusing. So RBridges do not terminate the campus. A router does, though, since the RBridges do not see anything happening on the other side of the router. Radia Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Saikat Ray wrote: > > >>I am not sure how Joe is defining "campus". The page 3 of the draft says "A >>campus refers to a set of links connected by either RBridges or bridges. In >>other words, the campus is terminated by traditional IP routers." >> >> > >Yeah - that seems like a bug. It seems like an rbridge campus is a set >of links connecting either bridges or rbridges, terminated by rbridges. > >i.e., > rbridges connected to internal bridges or rbridges > internal bridges connected to internal bridges or rbridges > all external links connected to rbridges only > (declare these 'edge' rbridges') > all nodes (hosts) connected via the external links > >But there don't need to be IP routers per se. > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm >c7AvMwnmVQu4jfUc6hv6nlo= >=wdXB >-----END PGP SIGNATURE----- >_______________________________________________ >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 j97InFL27572 for <rbridge@postel.org>; Fri, 7 Oct 2005 11:49:15 -0700 (PDT) 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 <0IO000E0G6XYNS00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 11:49:10 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO000D4D6XXEV00@mail.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 11:49:10 -0700 (PDT) Date: Fri, 07 Oct 2005 11:49:10 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <200510071806.j97I6iVd030100@stag.seas.upenn.edu> To: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4346C326.1020605@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200510071806.j97I6iVd030100@stag.seas.upenn.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: Re: [rbridge] FW: Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 18:50:11 -0000 Status: RO Content-Length: 1712 Saikat Ray wrote: > >[Saikat] Okay. Is this "RBridge election" process similar to the "designated >bridge election" process of the standard Ethernet? Of course the designation >can also be done after RBridges collect all the LSPs. > It is the same as the IS-IS "Designated Router" election on a link. IS-IS already has an election to determine exactly one router to be what it calls "Designated Router". The IS-IS DR is the one that names the link, advertises membership of the link, etc. This is exactly the same thing happening when IS-IS is running with RBridges. One RBridge on the link will be elected. It is not the same as the "designated bridge election" in the spanning tree. That's based on which bridge is closest to the Root bridge, with ID of bridge breaking ties. And that's for a different purpose than IS-IS Designated Router election. The IS-IS thing is totally local to a link, i.e., factors outside the link will not determine who is elected...it is only a function of IDs and priorities of the routers on the link. In contrast, the DB thing depends on outside things...if the location of the Root bridge changes, a different bridge will become DB. > > >W is the only RBridge on that link that listens to unencapsulated >packets, and the only one that decapsulates >packets when forwarding onto that link. > > >[Saikat] $X$ will however use the "link" for connectivity reasons (sending >encapsulated packets), right? > Correct. X will still use the link for forwarding encapsulated packets. So I think we understand each other now (assuming I was coherent in the explanation of how "Designated Bridge" selection differs from "Designated Router" election in IS-IS). Radia 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 j97IekL25276; Fri, 7 Oct 2005 11:40:46 -0700 (PDT) Message-ID: <4346C0B5.4020600@isi.edu> Date: Fri, 07 Oct 2005 11:38:45 -0700 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: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> In-Reply-To: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> 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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 18:41:36 -0000 Status: RO Content-Length: 995 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Saikat Ray wrote: > I am not sure how Joe is defining "campus". The page 3 of the draft says "A > campus refers to a set of links connected by either RBridges or bridges. In > other words, the campus is terminated by traditional IP routers." Yeah - that seems like a bug. It seems like an rbridge campus is a set of links connecting either bridges or rbridges, terminated by rbridges. i.e., rbridges connected to internal bridges or rbridges internal bridges connected to internal bridges or rbridges all external links connected to rbridges only (declare these 'edge' rbridges') all nodes (hosts) connected via the external links But there don't need to be IP routers per se. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm c7AvMwnmVQu4jfUc6hv6nlo= =wdXB -----END PGP SIGNATURE----- Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j97I6jL14352 for <rbridge@postel.org>; Fri, 7 Oct 2005 11:06:45 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j97I6iVd030100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Fri, 7 Oct 2005 14:06:44 -0400 Message-Id: <200510071806.j97I6iVd030100@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 7 Oct 2005 14:07:19 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXLYvUkz6RK+X8YSl+hf+/pzFWnNgABdazgAAA9tWA= X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: [rbridge] FW: Discovering endnodes directly connected to an RBridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 07 Oct 2005 18:07:17 -0000 Status: RO Content-Length: 4517 Previously sent to the wrong address: courtesy outlook :( -----Original Message----- From: Saikat Ray [mailto:saikat@seas.upenn.edu] Sent: Friday, October 07, 2005 2:04 PM To: 'Radia Perlman' Subject: RE: [rbridge] Discovering endnodes directly connected to an RBridge I think I need a picture, but I think the question is what happens if there are two RBridges, W and X, connected to the same link. [Saikat] Yes, that was precisely the question. If that's the question, then the answer is that only one of them gets elected "Designated RBridge", say W. Then W is the only one that learns endnode information (from listening to unencapsulated packets, whether they be data packets or ARP/ND replies). W announces the endnodes on that link in W's link state information. [Saikat] Okay. Is this "RBridge election" process similar to the "designated bridge election" process of the standard Ethernet? Of course the designation can also be done after RBridges collect all the LSPs. W is the only RBridge on that link that listens to unencapsulated packets, and the only one that decapsulates packets when forwarding onto that link. [Saikat] $X$ will however use the "link" for connectivity reasons (sending encapsulated packets), right? I'm confused about the "separate campuses" comment. If you connect RBridges, they'll all form one campus. The only way to make it separate campuses is to partition them and only connect them through routers. [Saikat] I also do not quite follow how Joe defines a "campus". Radia Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Saikat Ray wrote: > > >>>>>Thanks for your answers. You have properly understood the question. >>>>>However, I still have some doubts. Suppose a legacy bridge is connected >>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>>>$X$ will think that the new endnode $A$ is "directly" connected to >>>>>itself? >>>>> >>>>> >>>>Yes. Which is why both will forward packets addressed to $A$ they >>>>receive via other ports to the port they each have that attaches to the >>>>legacy bridge $Z$, which ought to push that traffic - regardless of how >>>>received - directly toward endnode $A$. >>>> >>>>I don't see the problem yet. >>>> >>>> >>>Two questions come to my mind: >>> >>>- Which node ends up in the routing tables of the other RBridges? >>> >>> >>All external nodes potentially end up in the edge encapsulation tables. >>Only the egress nodes within a particular rbridge campus will end up in >>the edge and interior IS-IS routing tables, however, since only >>encapsulated packets need be forwarded. >> >> >>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question >>was that in this example both $X$ and $W$ will advertise "direct >>connectivity" to endnode $A$ to the rest of the RBridges. Then if some other >>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will >>it send the packet to? >> >>Could you also kindly answer the next question assuming that $X$ and $W$ are >>individual RBridge Devices? >> >> > >I did: > > if they're in different campuses, there's no conflict > > if they're in the same campus, the external bridge $A$ is > effectively connected twice to the same rbridge campus; > this is out of spec. > >I'm not sure how existing bridges handle this; I would expect that the >spanning tree ought to pick only one of those ports, i.e., there would >never be a case where any traffic would flow from $A$ to one of $X$ or >$Y$, at which point only one of ($X$,$Y$) would advertize any node >connected to $A$ anyway. > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDRqi+E5f5cImnZrsRAm3jAKDoHTx2dj/hyUTh1VcBPMXkLScYgwCglOqC >+NhyO76PXRZqIXW6x6P9q7U= >=tG3e >-----END PGP SIGNATURE----- >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j97HrcL09748 for <rbridge@postel.org>; Fri, 7 Oct 2005 10:53:38 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j97HrbWV029654 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Fri, 7 Oct 2005 13:53:37 -0400 Message-Id: <200510071753.j97HrbWV029654@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 7 Oct 2005 13:54:12 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4346B0C8.4010302@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXLZW/vIEj2Cbd9T0mHSzdhyWyETQAAWOGA X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 07 Oct 2005 17:54:10 -0000 Status: RO Content-Length: 5292 I am not sure how Joe is defining "campus". The page 3 of the draft says "A campus refers to a set of links connected by either RBridges or bridges. In other words, the campus is terminated by traditional IP routers." The way I interpret it: if a connected set of links is "campus A" and another set of connected links (disjoint from the previous set) is "campus B", then the only way from sending packets from an endnode in "campus A" to an endnode in "campus B" is through an IP router. Am I misunderstanding something? If my interpretation is correct, then I do not understand what is meant by "a campus behaves like a single bridge"... By the way, in my example, $A$ was an endnode, not an Rbridge or a Bridge. Radia Perlman wrote: > I think I need a picture, but I think the question is what happens if > there are two RBridges, W and X, > connected to the same link. > > If that's the question, then the answer is that only one of them gets > elected "Designated RBridge", say W. I.e., the rbridge campus connects to A via only one link, as per spanning tree rules (on the outside, a campus behaves like a single bridge). > Then W > is the only one that learns endnode information (from listening to > unencapsulated packets, whether they > be data packets or ARP/ND replies). W announces the endnodes on that > link in W's link state information. > > W is the only RBridge on that link that listens to unencapsulated > packets, and the only one that decapsulates > packets when forwarding onto that link. > > I'm confused about the "separate campuses" comment. If you connect > RBridges, they'll all form one campus. > The only way to make it separate campuses is to partition them and only > connect them through routers. I am presuming that rbridges know which campus they belong to. Which means we can deploy two sets of rbridges in separate campuses that are either directly connected or connected via bridges. We don't need a router to connect them. Or shouldn't, IMO. Is there some reason that's a desirable property? Joe > > Radia > > Joe Touch wrote: > > > > > Saikat Ray wrote: > > > >>>>>Thanks for your answers. You have properly understood the question. >>>>>However, I still have some doubts. Suppose a legacy bridge is connected >>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>>>$X$ will think that the new endnode $A$ is "directly" connected to >>>>>itself? >>>>> >>>>> >>>> >>>>Yes. Which is why both will forward packets addressed to $A$ they >>>>receive via other ports to the port they each have that attaches to the >>>>legacy bridge $Z$, which ought to push that traffic - regardless of how >>>>received - directly toward endnode $A$. >>>> >>>>I don't see the problem yet. >>>> >>>> > >>>Two questions come to my mind: > >>>- Which node ends up in the routing tables of the other RBridges? >>> > > >>All external nodes potentially end up in the edge encapsulation tables. >>Only the egress nodes within a particular rbridge campus will end up in >>the edge and interior IS-IS routing tables, however, since only >>encapsulated packets need be forwarded. > > >>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question >>was that in this example both $X$ and $W$ will advertise "direct >>connectivity" to endnode $A$ to the rest of the RBridges. Then if some other >>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will >>it send the packet to? > >>Could you also kindly answer the next question assuming that $X$ and $W$ are >>individual RBridge Devices? > > > > I did: > > if they're in different campuses, there's no conflict > > if they're in the same campus, the external bridge $A$ is > effectively connected twice to the same rbridge campus; > this is out of spec. > > I'm not sure how existing bridges handle this; I would expect that the > spanning tree ought to pick only one of those ports, i.e., there would > never be a case where any traffic would flow from $A$ to one of $X$ or > $Y$, at which point only one of ($X$,$Y$) would advertize any node > connected to $A$ anyway. > > Joe _______________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRrDIE5f5cImnZrsRAjJPAKCEBoC0I/1QAHlqKLyADDrrx6TgYQCg+f4Q Q7EUvOVqch4QCrmrFh3Rhjo= =EhbX -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge 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 j97HWoL03291; Fri, 7 Oct 2005 10:32:50 -0700 (PDT) Message-ID: <4346B0C8.4010302@isi.edu> Date: Fri, 07 Oct 2005 10:30:48 -0700 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> References: <200510071635.j97GZEYt026943@stag.seas.upenn.edu> <4346A8BF.8060001@isi.edu> <4346AD89.4090400@sun.com> In-Reply-To: <4346AD89.4090400@sun.com> 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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 17:33:15 -0000 Status: RO Content-Length: 4488 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radia Perlman wrote: > I think I need a picture, but I think the question is what happens if > there are two RBridges, W and X, > connected to the same link. > > If that's the question, then the answer is that only one of them gets > elected "Designated RBridge", say W. I.e., the rbridge campus connects to A via only one link, as per spanning tree rules (on the outside, a campus behaves like a single bridge). > Then W > is the only one that learns endnode information (from listening to > unencapsulated packets, whether they > be data packets or ARP/ND replies). W announces the endnodes on that > link in W's link state information. > > W is the only RBridge on that link that listens to unencapsulated > packets, and the only one that decapsulates > packets when forwarding onto that link. > > I'm confused about the "separate campuses" comment. If you connect > RBridges, they'll all form one campus. > The only way to make it separate campuses is to partition them and only > connect them through routers. I am presuming that rbridges know which campus they belong to. Which means we can deploy two sets of rbridges in separate campuses that are either directly connected or connected via bridges. We don't need a router to connect them. Or shouldn't, IMO. Is there some reason that's a desirable property? Joe > > Radia > > Joe Touch wrote: > > > > > Saikat Ray wrote: > > > >>>>>Thanks for your answers. You have properly understood the question. >>>>>However, I still have some doubts. Suppose a legacy bridge is connected >>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>>>$X$ will think that the new endnode $A$ is "directly" connected to >>>>>itself? >>>>> >>>>> >>>> >>>>Yes. Which is why both will forward packets addressed to $A$ they >>>>receive via other ports to the port they each have that attaches to the >>>>legacy bridge $Z$, which ought to push that traffic - regardless of how >>>>received - directly toward endnode $A$. >>>> >>>>I don't see the problem yet. >>>> >>>> > >>>Two questions come to my mind: > >>>- Which node ends up in the routing tables of the other RBridges? >>> > > >>All external nodes potentially end up in the edge encapsulation tables. >>Only the egress nodes within a particular rbridge campus will end up in >>the edge and interior IS-IS routing tables, however, since only >>encapsulated packets need be forwarded. > > >>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question >>was that in this example both $X$ and $W$ will advertise "direct >>connectivity" to endnode $A$ to the rest of the RBridges. Then if some other >>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will >>it send the packet to? > >>Could you also kindly answer the next question assuming that $X$ and $W$ are >>individual RBridge Devices? > > > > I did: > > if they're in different campuses, there's no conflict > > if they're in the same campus, the external bridge $A$ is > effectively connected twice to the same rbridge campus; > this is out of spec. > > I'm not sure how existing bridges handle this; I would expect that the > spanning tree ought to pick only one of those ports, i.e., there would > never be a case where any traffic would flow from $A$ to one of $X$ or > $Y$, at which point only one of ($X$,$Y$) would advertize any node > connected to $A$ anyway. > > Joe _______________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRrDIE5f5cImnZrsRAjJPAKCEBoC0I/1QAHlqKLyADDrrx6TgYQCg+f4Q Q7EUvOVqch4QCrmrFh3Rhjo= =EhbX -----END PGP SIGNATURE----- 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 j97HH2L28285 for <rbridge@postel.org>; Fri, 7 Oct 2005 10:17:02 -0700 (PDT) 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 <0IO000DUY2O8SE00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 10:16:56 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IO000CQH2O7FF20@mail.sunlabs.com> for rbridge@postel.org; Fri, 07 Oct 2005 10:16:56 -0700 (PDT) Date: Fri, 07 Oct 2005 10:16:57 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4346A8BF.8060001@isi.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4346AD89.4090400@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: <200510071635.j97GZEYt026943@stag.seas.upenn.edu> <4346A8BF.8060001@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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 17:17:34 -0000 Status: RO Content-Length: 3811 I think I need a picture, but I think the question is what happens if there are two RBridges, W and X, connected to the same link. If that's the question, then the answer is that only one of them gets elected "Designated RBridge", say W. Then W is the only one that learns endnode information (from listening to unencapsulated packets, whether they be data packets or ARP/ND replies). W announces the endnodes on that link in W's link state information. W is the only RBridge on that link that listens to unencapsulated packets, and the only one that decapsulates packets when forwarding onto that link. I'm confused about the "separate campuses" comment. If you connect RBridges, they'll all form one campus. The only way to make it separate campuses is to partition them and only connect them through routers. Radia Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Saikat Ray wrote: > > >>>>>Thanks for your answers. You have properly understood the question. >>>>>However, I still have some doubts. Suppose a legacy bridge is connected >>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>>>$X$ will think that the new endnode $A$ is "directly" connected to >>>>>itself? >>>>> >>>>> >>>>Yes. Which is why both will forward packets addressed to $A$ they >>>>receive via other ports to the port they each have that attaches to the >>>>legacy bridge $Z$, which ought to push that traffic - regardless of how >>>>received - directly toward endnode $A$. >>>> >>>>I don't see the problem yet. >>>> >>>> >>>Two questions come to my mind: >>> >>>- Which node ends up in the routing tables of the other RBridges? >>> >>> >>All external nodes potentially end up in the edge encapsulation tables. >>Only the egress nodes within a particular rbridge campus will end up in >>the edge and interior IS-IS routing tables, however, since only >>encapsulated packets need be forwarded. >> >> >>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question >>was that in this example both $X$ and $W$ will advertise "direct >>connectivity" to endnode $A$ to the rest of the RBridges. Then if some other >>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will >>it send the packet to? >> >>Could you also kindly answer the next question assuming that $X$ and $W$ are >>individual RBridge Devices? >> >> > >I did: > > if they're in different campuses, there's no conflict > > if they're in the same campus, the external bridge $A$ is > effectively connected twice to the same rbridge campus; > this is out of spec. > >I'm not sure how existing bridges handle this; I would expect that the >spanning tree ought to pick only one of those ports, i.e., there would >never be a case where any traffic would flow from $A$ to one of $X$ or >$Y$, at which point only one of ($X$,$Y$) would advertize any node >connected to $A$ anyway. > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (MingW32) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDRqi+E5f5cImnZrsRAm3jAKDoHTx2dj/hyUTh1VcBPMXkLScYgwCglOqC >+NhyO76PXRZqIXW6x6P9q7U= >=tG3e >-----END PGP SIGNATURE----- >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > 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 j97GwWL22432; Fri, 7 Oct 2005 09:58:33 -0700 (PDT) Message-ID: <4346A8BF.8060001@isi.edu> Date: Fri, 07 Oct 2005 09:56:31 -0700 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: saikat@seas.upenn.edu, "Developing a hybrid router/bridge." <rbridge@postel.org> References: <200510071635.j97GZEYt026943@stag.seas.upenn.edu> In-Reply-To: <200510071635.j97GZEYt026943@stag.seas.upenn.edu> 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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 16:59:31 -0000 Status: RO Content-Length: 2713 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Saikat Ray wrote: >>>>Thanks for your answers. You have properly understood the question. >>>>However, I still have some doubts. Suppose a legacy bridge is connected >>>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>>$X$ will think that the new endnode $A$ is "directly" connected to >>>>itself? >>> >>>Yes. Which is why both will forward packets addressed to $A$ they >>>receive via other ports to the port they each have that attaches to the >>>legacy bridge $Z$, which ought to push that traffic - regardless of how >>>received - directly toward endnode $A$. >>> >>>I don't see the problem yet. >> >> >>Two questions come to my mind: >> >>- Which node ends up in the routing tables of the other RBridges? > > > All external nodes potentially end up in the edge encapsulation tables. > Only the egress nodes within a particular rbridge campus will end up in > the edge and interior IS-IS routing tables, however, since only > encapsulated packets need be forwarded. > > > [Saikat] $X$ and $W$ are individual RBridge Devices. I think the question > was that in this example both $X$ and $W$ will advertise "direct > connectivity" to endnode $A$ to the rest of the RBridges. Then if some other > RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will > it send the packet to? > > Could you also kindly answer the next question assuming that $X$ and $W$ are > individual RBridge Devices? I did: if they're in different campuses, there's no conflict if they're in the same campus, the external bridge $A$ is effectively connected twice to the same rbridge campus; this is out of spec. I'm not sure how existing bridges handle this; I would expect that the spanning tree ought to pick only one of those ports, i.e., there would never be a case where any traffic would flow from $A$ to one of $X$ or $Y$, at which point only one of ($X$,$Y$) would advertize any node connected to $A$ anyway. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRqi+E5f5cImnZrsRAm3jAKDoHTx2dj/hyUTh1VcBPMXkLScYgwCglOqC +NhyO76PXRZqIXW6x6P9q7U= =tG3e -----END PGP SIGNATURE----- Received: from stag.seas.upenn.edu (stag.seas.upenn.edu [158.130.70.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j97GZFL16473 for <rbridge@postel.org>; Fri, 7 Oct 2005 09:35:15 -0700 (PDT) Received: from Abacas (PONDNET21.SEAS.upenn.edu [158.130.21.22]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j97GZEYt026943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Fri, 7 Oct 2005 12:35:14 -0400 Message-Id: <200510071635.j97GZEYt026943@stag.seas.upenn.edu> From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Date: Fri, 7 Oct 2005 12:35:48 -0400 Organization: University of Pennsylvania MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <43469F4D.5010608@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXLWzC7TM0Aa81YTVi+pLK5dNOtfAAARsOw X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu, "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, 07 Oct 2005 16:36:08 -0000 Status: RO Content-Length: 3015 >>>Thanks for your answers. You have properly understood the question. >>>However, I still have some doubts. Suppose a legacy bridge is connected >>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>$X$ will think that the new endnode $A$ is "directly" connected to >>>itself? >> >>Yes. Which is why both will forward packets addressed to $A$ they >>receive via other ports to the port they each have that attaches to the >>legacy bridge $Z$, which ought to push that traffic - regardless of how >>received - directly toward endnode $A$. >> >>I don't see the problem yet. > > > Two questions come to my mind: > > - Which node ends up in the routing tables of the other RBridges? All external nodes potentially end up in the edge encapsulation tables. Only the egress nodes within a particular rbridge campus will end up in the edge and interior IS-IS routing tables, however, since only encapsulated packets need be forwarded. [Saikat] $X$ and $W$ are individual RBridge Devices. I think the question was that in this example both $X$ and $W$ will advertise "direct connectivity" to endnode $A$ to the rest of the RBridges. Then if some other RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will it send the packet to? Could you also kindly answer the next question assuming that $X$ and $W$ are individual RBridge Devices? > - Once the route is announced, will $X$ and $W$ believe the route or their > directly acquired knowledge? And for how long? I'm not sure whether $X$ and $W$ represent individual rbridge devices or rbridge campuses. Up to this point in the thread, I had assumed campuses, or devices on different campuses. If they're on the same campus, what you have is what amounts to a loop (remember - an rbridge campus acts like a single bridge to the outside world). In that case, you have a misconfigured ethernet, since you're connecting two bridges with two links. Joe > (the first may be totally obvious to people who understand IS-IS....) > > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRp9NE5f5cImnZrsRAs9QAJ0f99xq98ZkNNidHhYgNizX5D7gWACg/vxo u5d9T8V4cFxmq0mYfQ3CiK0= =UqMs -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge 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 j97GIFL10925; Fri, 7 Oct 2005 09:18:15 -0700 (PDT) Message-ID: <43469F4D.5010608@isi.edu> Date: Fri, 07 Oct 2005 09:16:13 -0700 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> References: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> <4345BE14.60202@sun.com> <Pine.GSO.4.58.0510062035410.23672@blue.seas.upenn.edu> <4345EA26.103@isi.edu> <1BEE02D692F2F81B45838869@gloppen.hjemme.alvestrand.no> In-Reply-To: <1BEE02D692F2F81B45838869@gloppen.hjemme.alvestrand.no> 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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 16:19:35 -0000 Status: RO Content-Length: 2629 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harald Tveit Alvestrand wrote: > > --On torsdag, oktober 06, 2005 20:23:18 -0700 Joe Touch <touch@ISI.EDU> > wrote: > > >>>Thanks for your answers. You have properly understood the question. >>>However, I still have some doubts. Suppose a legacy bridge is connected >>>to (perhaps through a LAN segment) two RBridges. To use my example: the >>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the >>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >>>and $X$ receives this packet. Then isn't it the case that both $W$ and >>>$X$ will think that the new endnode $A$ is "directly" connected to >>>itself? >> >>Yes. Which is why both will forward packets addressed to $A$ they >>receive via other ports to the port they each have that attaches to the >>legacy bridge $Z$, which ought to push that traffic - regardless of how >>received - directly toward endnode $A$. >> >>I don't see the problem yet. > > > Two questions come to my mind: > > - Which node ends up in the routing tables of the other RBridges? All external nodes potentially end up in the edge encapsulation tables. Only the egress nodes within a particular rbridge campus will end up in the edge and interior IS-IS routing tables, however, since only encapsulated packets need be forwarded. > - Once the route is announced, will $X$ and $W$ believe the route or their > directly acquired knowledge? And for how long? I'm not sure whether $X$ and $W$ represent individual rbridge devices or rbridge campuses. Up to this point in the thread, I had assumed campuses, or devices on different campuses. If they're on the same campus, what you have is what amounts to a loop (remember - an rbridge campus acts like a single bridge to the outside world). In that case, you have a misconfigured ethernet, since you're connecting two bridges with two links. Joe > (the first may be totally obvious to people who understand IS-IS....) > > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRp9NE5f5cImnZrsRAs9QAJ0f99xq98ZkNNidHhYgNizX5D7gWACg/vxo u5d9T8V4cFxmq0mYfQ3CiK0= =UqMs -----END PGP SIGNATURE----- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9792hL21373 for <rbridge@postel.org>; Fri, 7 Oct 2005 02:02:43 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 373D12596BF for <rbridge@postel.org>; Fri, 7 Oct 2005 11:02:16 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06587-01 for <rbridge@postel.org>; Fri, 7 Oct 2005 11:02:11 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FD93258077 for <rbridge@postel.org>; Fri, 7 Oct 2005 11:02:10 +0200 (CEST) Date: Fri, 07 Oct 2005 11:02:36 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-ID: <1BEE02D692F2F81B45838869@gloppen.hjemme.alvestrand.no> In-Reply-To: <4345EA26.103@isi.edu> References: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> <4345BE14.60202@sun.com> <Pine.GSO.4.58.0510062035410.23672@blue.seas.upenn.edu> <4345EA26.103@isi.edu> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 09:03:02 -0000 Status: RO Content-Length: 1424 --On torsdag, oktober 06, 2005 20:23:18 -0700 Joe Touch <touch@ISI.EDU> wrote: >> Thanks for your answers. You have properly understood the question. >> However, I still have some doubts. Suppose a legacy bridge is connected >> to (perhaps through a LAN segment) two RBridges. To use my example: the >> legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports >> that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. >> Now suppose a new endnode, $A$, joins a LAN segment connected only to the >> legacy bridge $Z$, and the endnode sends out an ARP query. The legacy >> bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ >> and $X$ receives this packet. Then isn't it the case that both $W$ and >> $X$ will think that the new endnode $A$ is "directly" connected to >> itself? > > Yes. Which is why both will forward packets addressed to $A$ they > receive via other ports to the port they each have that attaches to the > legacy bridge $Z$, which ought to push that traffic - regardless of how > received - directly toward endnode $A$. > > I don't see the problem yet. Two questions come to my mind: - Which node ends up in the routing tables of the other RBridges? - Once the route is announced, will $X$ and $W$ believe the route or their directly acquired knowledge? And for how long? (the first may be totally obvious to people who understand IS-IS....) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j978tsL19126 for <rbridge@postel.org>; Fri, 7 Oct 2005 01:55:55 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E97262596BE; Fri, 7 Oct 2005 10:55:26 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06047-02; Fri, 7 Oct 2005 10:55:16 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id E35E02596BD; Fri, 7 Oct 2005 10:55:14 +0200 (CEST) Date: Fri, 07 Oct 2005 10:55:40 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: "Developing a hybrid router/bridge." <rbridge@postel.org>, Joe Touch <touch@ISI.EDU> Message-ID: <8FA5CF2938B9E05595D0C48E@gloppen.hjemme.alvestrand.no> In-Reply-To: <43413A48.1020100@sun.com> References: <43413A48.1020100@sun.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Subject: Re: [rbridge] Call for agenda items 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, 07 Oct 2005 08:56:02 -0000 Status: RO Content-Length: 677 Erik, Joe: from one of Joe's messages I get the impression that there is a short-term plan for what documents will be written and when they will be published. I assume that you as chair know what they're doing, Erik. Perhaps you could keep us updated on that plan, so that you can instead call for "any OTHER items"? Harald --On mandag, oktober 03, 2005 07:03:52 -0700 Erik Nordmark <erik.nordmark@sun.com> wrote: > > What drafts and other issues will there be to discuss at Vancouver? > > Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge > Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j973NSL29146; Thu, 6 Oct 2005 20:23:28 -0700 (PDT) Message-ID: <4345EA26.103@isi.edu> Date: Thu, 06 Oct 2005 20:23:18 -0700 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> References: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> <4345BE14.60202@sun.com> <Pine.GSO.4.58.0510062035410.23672@blue.seas.upenn.edu> In-Reply-To: <Pine.GSO.4.58.0510062035410.23672@blue.seas.upenn.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7FBA0523FB498A3A0197C848" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 03:24:05 -0000 Status: RO Content-Length: 4269 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7FBA0523FB498A3A0197C848 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > (I am hoping that this post will go into the proper thread. I apologize > in advance if it starts a new thread.) > > Thanks for your answers. You have properly understood the question. > However, I still have some doubts. Suppose a legacy bridge is connected to > (perhaps through a LAN segment) two RBridges. To use my example: the > legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports > that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. > Now suppose a new endnode, $A$, joins a LAN segment connected only to the > legacy bridge $Z$, and the endnode sends out an ARP query. The legacy > bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ > and $X$ receives this packet. Then isn't it the case that both $W$ and $X$ > will think that the new endnode $A$ is "directly" connected to itself? Yes. Which is why both will forward packets addressed to $A$ they receive via other ports to the port they each have that attaches to the legacy bridge $Z$, which ought to push that traffic - regardless of how received - directly toward endnode $A$. I don't see the problem yet. Joe > > > On Thu, 6 Oct 2005, Radia Perlman wrote: > > >>A legacy bridge would not remove the encapsulation header. >> >>If there are two RBridges, only one is allowed to encapsulate from, and >>decapsulate onto, that link. >> >>So therefore if an RBridge sees a packet without an encapsulation >>header, and that RBridge is the >>Designated RBridge, then it knows the packet came from an endnode. >> >>If the packet came from an endnode but was forwarded by a legacy bridge >>before reaching the first RBridge, >>that's OK. It's the same as coming directly from the endnode. A "link" >>to an RBridge is a bunch of >>Ethernet segments connected by legacy bridges. >> >>Hopefully I understood your question. If not, please re-ask. >> >>Radia >> >> >> >>Saikat Ray wrote: >> >> >>>Hi All, >>> >>>I am confused over a basic (probably a trivial) problem described below. I >>>would much appreciate if someone can answer. >>> >>>Thanks in advance. >>> >>>Saikat >>> >>>%%%%%%%%%%%%%%%%%%% >>> >>>In the RBridge draft, page 4, it is written that "Once an RBridge learns >>>the location of a directly attached endnode, it informs the other RBridges >>>in its link state information." But how does an RBridge learn which >>>endnodes are directly connected to it using only promiscuous listening? >>>Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$ >>>of an RBridge $X$. Also assume that there is one another legacy bridge, >>>$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$ >>>that connects it to the LAN segment $Y$ is in forwarding state, hence the >>>bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$ >>>receives two types of packets on port $p$: (i) packets that are sent by >>>the endnodes that are directly connected to the LAN segment $Y$, and (ii) >>>packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does >>>the RBridge $X$ distinguish between these two types of packets? >>>_______________________________________________ >>>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 --------------enig7FBA0523FB498A3A0197C848 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDReoqE5f5cImnZrsRAtFKAJ0YcrqgQirK52PGr998gbSCa2fwIgCbBdh3 qTtXyRc5tcXIwvb0IMrvww0= =oInX -----END PGP SIGNATURE----- --------------enig7FBA0523FB498A3A0197C848-- Received: from psychopathy.seas.upenn.edu (psychopathy.seas.upenn.edu [158.130.65.164]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j970pLL23388 for <rbridge@postel.org>; Thu, 6 Oct 2005 17:51:21 -0700 (PDT) Received: from blue.seas.upenn.edu (BLUE.seas.upenn.edu [158.130.64.177]) by psychopathy.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j970pGDt007050 for <rbridge@postel.org>; Thu, 6 Oct 2005 20:51:16 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.10/8.12.9) with ESMTP id j970pG8D024037 for <rbridge@postel.org>; Thu, 6 Oct 2005 20:51:16 -0400 (EDT) Received: from localhost (saikat@localhost) by blue.seas.upenn.edu (8.12.10/8.12.9/Submit) with ESMTP id j970pG8c024033 for <rbridge@postel.org>; Thu, 6 Oct 2005 20:51:16 -0400 (EDT) Date: Thu, 6 Oct 2005 20:51:16 -0400 (EDT) From: Saikat Ray <saikat@seas.upenn.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <4345BE14.60202@sun.com> Message-ID: <Pine.GSO.4.58.0510062035410.23672@blue.seas.upenn.edu> References: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> <4345BE14.60202@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: -2.82 ALL_TRUSTED X-Scanned-By: MIMEDefang 2.49 on 158.130.65.164 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 00:52:01 -0000 Status: RO Content-Length: 3073 (I am hoping that this post will go into the proper thread. I apologize in advance if it starts a new thread.) Thanks for your answers. You have properly understood the question. However, I still have some doubts. Suppose a legacy bridge is connected to (perhaps through a LAN segment) two RBridges. To use my example: the legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports that connect $Z$ to $X$ and $W$, respectively, are in forwarding state. Now suppose a new endnode, $A$, joins a LAN segment connected only to the legacy bridge $Z$, and the endnode sends out an ARP query. The legacy bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$ and $X$ receives this packet. Then isn't it the case that both $W$ and $X$ will think that the new endnode $A$ is "directly" connected to itself? On Thu, 6 Oct 2005, Radia Perlman wrote: > A legacy bridge would not remove the encapsulation header. > > If there are two RBridges, only one is allowed to encapsulate from, and > decapsulate onto, that link. > > So therefore if an RBridge sees a packet without an encapsulation > header, and that RBridge is the > Designated RBridge, then it knows the packet came from an endnode. > > If the packet came from an endnode but was forwarded by a legacy bridge > before reaching the first RBridge, > that's OK. It's the same as coming directly from the endnode. A "link" > to an RBridge is a bunch of > Ethernet segments connected by legacy bridges. > > Hopefully I understood your question. If not, please re-ask. > > Radia > > > > Saikat Ray wrote: > > >Hi All, > > > >I am confused over a basic (probably a trivial) problem described below. I > >would much appreciate if someone can answer. > > > >Thanks in advance. > > > >Saikat > > > >%%%%%%%%%%%%%%%%%%% > > > >In the RBridge draft, page 4, it is written that "Once an RBridge learns > >the location of a directly attached endnode, it informs the other RBridges > >in its link state information." But how does an RBridge learn which > >endnodes are directly connected to it using only promiscuous listening? > >Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$ > >of an RBridge $X$. Also assume that there is one another legacy bridge, > >$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$ > >that connects it to the LAN segment $Y$ is in forwarding state, hence the > >bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$ > >receives two types of packets on port $p$: (i) packets that are sent by > >the endnodes that are directly connected to the LAN segment $Y$, and (ii) > >packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does > >the RBridge $X$ distinguish between these two types of packets? > >_______________________________________________ > >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 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 j970FSL14028 for <rbridge@postel.org>; Thu, 6 Oct 2005 17:15:28 -0700 (PDT) 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 <0INY00D78RDIS800@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 06 Oct 2005 17:15:18 -0700 (PDT) Received: from sun.com ([129.150.29.181]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0INY00CBPRDEFF10@mail.sunlabs.com> for rbridge@postel.org; Thu, 06 Oct 2005 17:15:16 -0700 (PDT) Date: Thu, 06 Oct 2005 17:15:16 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4345BE14.60202@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: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.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: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 07 Oct 2005 00:16:00 -0000 Status: RO Content-Length: 1963 A legacy bridge would not remove the encapsulation header. If there are two RBridges, only one is allowed to encapsulate from, and decapsulate onto, that link. So therefore if an RBridge sees a packet without an encapsulation header, and that RBridge is the Designated RBridge, then it knows the packet came from an endnode. If the packet came from an endnode but was forwarded by a legacy bridge before reaching the first RBridge, that's OK. It's the same as coming directly from the endnode. A "link" to an RBridge is a bunch of Ethernet segments connected by legacy bridges. Hopefully I understood your question. If not, please re-ask. Radia Saikat Ray wrote: >Hi All, > >I am confused over a basic (probably a trivial) problem described below. I >would much appreciate if someone can answer. > >Thanks in advance. > >Saikat > >%%%%%%%%%%%%%%%%%%% > >In the RBridge draft, page 4, it is written that "Once an RBridge learns >the location of a directly attached endnode, it informs the other RBridges >in its link state information." But how does an RBridge learn which >endnodes are directly connected to it using only promiscuous listening? >Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$ >of an RBridge $X$. Also assume that there is one another legacy bridge, >$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$ >that connects it to the LAN segment $Y$ is in forwarding state, hence the >bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$ >receives two types of packets on port $p$: (i) packets that are sent by >the endnodes that are directly connected to the LAN segment $Y$, and (ii) >packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does >the RBridge $X$ distinguish between these two types of packets? >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j96NlUL06755; Thu, 6 Oct 2005 16:47:30 -0700 (PDT) Message-ID: <4345B791.8020605@isi.edu> Date: Thu, 06 Oct 2005 16:47:29 -0700 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> References: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> In-Reply-To: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34681233A25003A6B9F78DCE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge 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, 06 Oct 2005 23:48:28 -0000 Status: RO Content-Length: 2290 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34681233A25003A6B9F78DCE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saikat Ray wrote: > Hi All, > > I am confused over a basic (probably a trivial) problem described below. I > would much appreciate if someone can answer. > > Thanks in advance. > > Saikat > > %%%%%%%%%%%%%%%%%%% > > In the RBridge draft, page 4, it is written that "Once an RBridge learns > the location of a directly attached endnode, it informs the other RBridges > in its link state information." But how does an RBridge learn which > endnodes are directly connected to it using only promiscuous listening? Looking for source addresses it has not seen yet, e.g, via broadcast ARP requests. > Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$ > of an RBridge $X$. Also assume that there is one another legacy bridge, > $Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$ > that connects it to the LAN segment $Y$ is in forwarding state, hence the > bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$ > receives two types of packets on port $p$: (i) packets that are sent by > the endnodes that are directly connected to the LAN segment $Y$, and (ii) > packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does > the RBridge $X$ distinguish between these two types of packets? It doesn't care; both are effectively accessible off that egress of the rbrige campus. The term 'directly connected' above should probably be replaced with 'connected', since there's no way to distinguish. This will be addressed in the new version of the doc which is split into separate problem statement and arch docs. Joe --------------enig34681233A25003A6B9F78DCE 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 Thunderbird - http://enigmail.mozdev.org iD8DBQFDRbeRE5f5cImnZrsRAux3AJ43CsddOMH3ftqMVQNNOs2eDtD/XwCfd/9d JpJFoYeERAj5vhCMYLLbwak= =uDlJ -----END PGP SIGNATURE----- --------------enig34681233A25003A6B9F78DCE-- Received: from psychopathy.seas.upenn.edu (psychopathy.seas.upenn.edu [158.130.65.164]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j96NcKL03792 for <rbridge@postel.org>; Thu, 6 Oct 2005 16:38:20 -0700 (PDT) Received: from blue.seas.upenn.edu (BLUE.seas.upenn.edu [158.130.64.177]) by psychopathy.seas.upenn.edu (8.13.3/8.12.10) with ESMTP id j96NcIEH031053 for <rbridge@postel.org>; Thu, 6 Oct 2005 19:38:18 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.10/8.12.9) with ESMTP id j96NcI8D021633 for <rbridge@postel.org>; Thu, 6 Oct 2005 19:38:18 -0400 (EDT) Received: from localhost (saikat@localhost) by blue.seas.upenn.edu (8.12.10/8.12.9/Submit) with ESMTP id j96NcHtb021630 for <rbridge@postel.org>; Thu, 6 Oct 2005 19:38:17 -0400 (EDT) Date: Thu, 6 Oct 2005 19:38:17 -0400 (EDT) From: Saikat Ray <saikat@seas.upenn.edu> To: rbridge@postel.org Message-ID: <Pine.GSO.4.58.0510061929460.21386@blue.seas.upenn.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: -2.82 ALL_TRUSTED X-Scanned-By: MIMEDefang 2.49 on 158.130.65.164 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Subject: [rbridge] Discovering endnodes directly connected to an RBridge 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, 06 Oct 2005 23:39:01 -0000 Status: RO Content-Length: 1117 Hi All, I am confused over a basic (probably a trivial) problem described below. I would much appreciate if someone can answer. Thanks in advance. Saikat %%%%%%%%%%%%%%%%%%% In the RBridge draft, page 4, it is written that "Once an RBridge learns the location of a directly attached endnode, it informs the other RBridges in its link state information." But how does an RBridge learn which endnodes are directly connected to it using only promiscuous listening? Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$ of an RBridge $X$. Also assume that there is one another legacy bridge, $Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$ that connects it to the LAN segment $Y$ is in forwarding state, hence the bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$ receives two types of packets on port $p$: (i) packets that are sent by the endnodes that are directly connected to the LAN segment $Y$, and (ii) packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does the RBridge $X$ distinguish between these two types of packets? Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j93E3HL16201 for <rbridge@postel.org>; Mon, 3 Oct 2005 07:03:17 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j93E3GvD022105 for <rbridge@postel.org>; Mon, 3 Oct 2005 08:03:16 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j93E3Fd9130179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Oct 2005 07:03:16 -0700 (PDT) Message-ID: <43413A48.1020100@sun.com> Date: Mon, 03 Oct 2005 07:03:52 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: [rbridge] Call for agenda items 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, 03 Oct 2005 14:03:36 -0000 Status: RO Content-Length: 79 What drafts and other issues will there be to discuss at Vancouver? Erik
- [rbridge] How should RBridges recognize spanning … Vishwas Manral
- [rbridge] How should RBridges recognize spanning … Guillermo Ibáñez
- [rbridge] Plea for references (Re: How should...) Harald Tveit Alvestrand
- [rbridge] Plea for references (Re: How should...) Guillermo Ibáñez