[rbridge] Separating DRB election from encapsulator/decapsulator
Radia.Perlman at sun.com (Radia Perlman) Thu, 01 November 2007 04:01 UTC
From: "Radia.Perlman at sun.com"
Date: Wed, 31 Oct 2007 21:01:13 -0700
Subject: [rbridge] Separating DRB election from encapsulator/decapsulator
Message-ID: <47294F89.4050905@sun.com>
When trying to carefully write up all the rules with respect to RBridges and VLANs, it occurs to me that one place in which things can be simplified is to separate the function of the DRB on a layer 2 cloud from the selection of data packet encapsulator/decapsulator for each VLAN. What I mean is that instead of having n different DRB elections with different priorities for different, possibly overlapping sets of VLANs for that cloud, we instead have a single DRB election for that cloud, and as a result, a single pseudonode associated with the cloud that would be visible to any RBridges not on the cloud. The DRB on a cloud has the following duties: a) names the pseudonode associated with the cloud b) reports an LSP on behalf of the pseudonode c) issues IS-IS CSNPs (a way of acknowledging LSPs that have been sent on the cloud) d) specifies, for each VLAN supported on that cloud, which RBridge on the cloud will be doing encapsulation/decapsulation for that VLAN e) chooses a VLAN tag with which all RBridge-RBridge communication on that cloud will be tagged in the outer header (explanation of this will be in a future email). For now, does anyone see any problem with this? It's unfortunately a bit entwined with the other hairy discussion going on, but I think that we're going to converge for that. Radia Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA13xnX9017020 for <rbridge@postel.org>; Wed, 31 Oct 2007 20:59:49 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQT00CCL73L4Y00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 31 Oct 2007 20:59:45 -0700 (PDT) Received: from [129.150.22.40] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQT006V573JZHI0@mail.sunlabs.com> for rbridge@postel.org; Wed, 31 Oct 2007 20:59:44 -0700 (PDT) Date: Wed, 31 Oct 2007 21:01:13 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <47294F89.4050905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Separating DRB election from encapsulator/decapsulator X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 01 Nov 2007 04:00:14 -0000 Status: RO Content-Length: 1331 When trying to carefully write up all the rules with respect to RBridges and VLANs, it occurs to me that one place in which things can be simplified is to separate the function of the DRB on a layer 2 cloud from the selection of data packet encapsulator/decapsulator for each VLAN. What I mean is that instead of having n different DRB elections with different priorities for different, possibly overlapping sets of VLANs for that cloud, we instead have a single DRB election for that cloud, and as a result, a single pseudonode associated with the cloud that would be visible to any RBridges not on the cloud. The DRB on a cloud has the following duties: a) names the pseudonode associated with the cloud b) reports an LSP on behalf of the pseudonode c) issues IS-IS CSNPs (a way of acknowledging LSPs that have been sent on the cloud) d) specifies, for each VLAN supported on that cloud, which RBridge on the cloud will be doing encapsulation/decapsulation for that VLAN e) chooses a VLAN tag with which all RBridge-RBridge communication on that cloud will be tagged in the outer header (explanation of this will be in a future email). For now, does anyone see any problem with this? It's unfortunately a bit entwined with the other hairy discussion going on, but I think that we're going to converge for that. Radia Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id lA117ZK5029192 for <Rbridge@postel.org>; Wed, 31 Oct 2007 18:07:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1193879254!19261479!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19246 invoked from network); 1 Nov 2007 01:07:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 1 Nov 2007 01:07:34 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lA117VSJ016684 for <Rbridge@postel.org>; Wed, 31 Oct 2007 18:07:34 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lA117VtY029693 for <Rbridge@postel.org>; Wed, 31 Oct 2007 20:07:31 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lA117B0O029608 for <Rbridge@postel.org>; Wed, 31 Oct 2007 20:07:11 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 31 Oct 2007 21:07:09 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900332B671@de01exm64.ds.mot.com> In-Reply-To: <471F8DC7.2040203@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TRILL meeting in Vancouver Thread-Index: AcgWayFJYVNt3x1TSmueCxpsAEQVbQFt/mGA References: <3870C46029D1F945B1472F170D2D9790032E6447@de01exm64.ds.mot.com> <471F8DC7.2040203@isi.edu> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id lA117ZK5029192 Subject: [rbridge] TRILL meeting in Vancouver X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 01 Nov 2007 01:07:43 -0000 Status: RO Content-Length: 912 We have succeeded in having the TRILL meeting in Vancouver moved to Tuesday morning (at least for now). Donald Eastlake III Donald-LDE008 wrote: > A draft agenda for the 70th IETF meeting in Vancouver, British Columbia, > has been posted a few days ahead of schedule on the www.ietf.org web > site. It shows TRILL as being Thursday morning. However, a couple of our > working group draft authors have requested that we attempt to have the > meeting move to Tuesday. Although it is not clear that we can do this, > keeping in mind other working group and meeting space constraints (for > example, as an Internet Area WG we can't conflict with the INTAREA > meeting Tuesday afternoon), we plan to request such a move to Tuesday. > > Thanks, > Erik and Donald > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VLnIFc019757 for <rbridge@postel.org>; Wed, 31 Oct 2007 14:49:18 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQS00C52PXW4Z00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 31 Oct 2007 14:49:08 -0700 (PDT) Received: from [129.150.22.40] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQS006EUPXVZKI0@mail.sunlabs.com> for rbridge@postel.org; Wed, 31 Oct 2007 14:49:08 -0700 (PDT) Date: Wed, 31 Oct 2007 14:50:36 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <941D5DCD8C42014FAF70FB7424686DCF01DDF347@eusrcmw721.eamcs.ericsson.se> To: Eric Gray <eric.gray@ericsson.com> Message-id: <4728F8AC.8080506@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> <941D5DCD8C42014FAF70FB7424686DCF01DDF347@eusrcmw721.eamcs.ericsson.se> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 21:50:05 -0000 Status: RO Content-Length: 9098 Eric....if I understand your concern... Having all RBridge-RBridge traffic between neighbor RBridges (RBridges on a single layer 2 cloud) take place on a single VLAN (whether the VLAN used be configurable for that cloud, or whether it's always VLAN 1), does not preclude load splitting. "VLAN 1" as the VLAN tag in the outer header is just used in order to get a packet from one RBridge to a neighbor RBridge. Layer 3 techniques for load splitting, traffic engineering, etc., can be used for having RBridges choose paths across the campus. When doing load splitting, a smart RBridge, just like a router, could choose anything it can see in order to decide which path to send a frame on, or which traffic to drop when there is congestion, including the inner VLAN tag. And although some might consider it architecturally impure, there isn't anything precluding an RBridge from looking even further into the packet and making forwarding/traffic splitting/traffic dropping decisions based on things like the diffsrv field in the IP header, or the TCP ports. The outer VLAN tag is just how to wrap up the frame when forwarding to the next hop RBridge that the RBridge forwarding decision has selected for this frame. Radia Eric Gray wrote: > Anoop, > > This is a generic VLAN bridging problem, commonly > dealt with using VLAN bridges today. Clearly, it is not > the case that all VLAN bridges are required to use a > common VLAN for frame forwarding. > > In addition, as I understand it (in part based on > James' reply), we are NOT saying that the common VLAN > you mention must be used for all frame forwarding - > hence it is likely that the existence of a common VLAN > does not necessarily fix the problem. > > Just to be clear, if we were saying that a common > VLAN must be used for all forwarding between RBridges, > it quickly becomes obvious that load-sharing based on > VLAN separation becomes useless in practice. If load > sharing based on VID is not useful, then MSTP already > provides L2 forwarding that makes more efficient use of > links than would be possible using RBridges (unless all > RBridge-to-RBridge connections are via P2P links). > > -- > Eric Gray > Principal Engineer > Ericsson > > >> -----Original Message----- >> From: Anoop Ghanwani [mailto:anoop@brocade.com] >> Sent: Wednesday, October 31, 2007 1:33 PM >> To: Zhi-Hern Loh; Eric Gray >> Cc: Developing a hybrid router/bridge. >> Subject: RE: [rbridge] RBridge: a case of study >> Importance: High >> >> >> Hern, >> >> That's one of the problems that we're trying to avoid >> by forcing all RBridges on a bridged LAN to be configured >> such that they are all reachable and see one another on >> a single VLAN. >> >> Anoop >> >> >>> -----Original Message----- >>> From: rbridge-bounces@postel.org >>> [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh >>> Sent: Wednesday, October 31, 2007 10:17 AM >>> To: Eric Gray >>> Cc: Developing a hybrid router/bridge. >>> Subject: Re: [rbridge] RBridge: a case of study >>> >>> Donald, >>> >>> In addition to Eric's questions, could you (or anyone else) >>> explain what would happen in the following scenario? >>> >>> Toplogy: >>> >>> RBa >>> / >>> VID a >>> / >>> RBn-link X-----VID b------RBb >>> >>> Problem: >>> >>> RBn is connected to 2 VLANs on link/port X. Connectivity to >>> RBa is via VLAN a, and connectivity to RBb is via VLAN b. >>> >>> Suppose that RBa and RBb are in the multi-destination >>> distribution tree from RBn. For a multi-destination frame >>> going out link/port X on RBn to RBa and RBb, what is the VID >>> on the outer VLAN tag? Or could there be need to send 2 >>> frames, one with VID a and another with VID b? >>> >>> >>> >>> Thanks, >>> Hern >>> Fulcrum Microsystems >>> >>> >>> ----- Original Message ----- >>> From: "Eric Gray" <eric.gray@ericsson.com> >>> To: "Eastlake III Donald-LDE008" >>> <Donald.Eastlake@motorola.com>, "Zhi-Hern Loh" >>> >> <zloh@fulcrummicro.com> >> >>> Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> >>> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) >>> America/Los_Angeles >>> Subject: RE: [rbridge] RBridge: a case of study >>> >>> Donald, >>> >>> When you say "would all have the same Outer [VID]" >>> - do you mean: >>> >>> 1) all frames MUST have the same VID within the an RBridge >>> campus, >>> 2) all frames forwarded from a (physical) port on one RBridge >>> to a (physical) port on another RBridge MUST have the same >>> VID, or >>> 3) something else? >>> >>> -- >>> Eric Gray >>> Principal Engineer >>> Ericsson >>> >>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org >>>> [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III >>>> Donald-LDE008 >>>> Sent: Wednesday, October 31, 2007 12:22 AM >>>> To: Zhi-Hern Loh >>>> Cc: Developing a hybrid router/bridge. >>>> Subject: Re: [rbridge] RBridge: a case of study >>>> >>>> Hi, >>>> >>>> Yes, as noted in protocol draft -05, the pseudo code was >>>> >> unchanged >> >>>> from >>>> -04 and is out of date. >>>> >>>> As currently being discussed, the TRILL encapsulated data being >>>> forwarded out a particular physical port would all have the >>>> >>> same Outer >>> >>>> VLAN ID. >>>> >>>> Thanks, >>>> Donald >>>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org >>>> [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh >>>> Sent: Tuesday, October 30, 2007 10:54 PM >>>> To: Anoop Ghanwani >>>> Cc: Developing a hybrid router/bridge.; Radia Perlman; >>>> >> James Carlson >> >>>> Subject: Re: [rbridge] RBridge: a case of study >>>> >>>> >>>> ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: >>>> >>>>>> -----Original Message----- >>>>>> From: rbridge-bounces@postel.org >>>>>> [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson >>>>>> Sent: Tuesday, October 30, 2007 2:37 PM >>>>>> To: Silvano Gai >>>>>> Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM >>>>>> Subject: Re: [rbridge] RBridge: a case of study >>>>>> >>>>>> Silvano Gai writes: >>>>>> >>>>>>> Radia, >>>>>>> >>>>>>> I have added few slides to the example and I suggest that >>>>>>> >>>>>> we use it as >>>>>> >>>>>>> a possible case of study for TRILL (of course, not the >>>>>>> >>>> only one). >>>> >>>>>>> Let's see if the solutions we have discussed work on this >>>>>>> >>>>> example. >>>>> >>>>>>> The complete case of study is at: >>>>>>> >>>>>>> http://www.ip6.com/acme-example-v1.ppt >>>>>>> >>>>>> I have a few narrow questions that I think might help me >>>>>> understand this picture a bit better. (I probably have more >>>>>> questions once I know the narrow answers. ;-}) >>>>>> >>>>> Let me take a shot at answering these. >>>>> >>>>> >>>>>> 1. After the proposed fix, should VLAN 3 on Cloud L >>>>>> >>> be bridged >>> >>>>>> together with VLAN 3 on Cloud R, even though >>>>>> >> the backbone >> >>>>> itself >>>>> >>>>>> doesn't directly carry VLAN 3? (I.e., are TRILL >>>>>> >>>> packets with >>>> >>>>>> outer VLAN ID 7 or 8 and with inner VLAN 3 >>>>>> >> present on the >> >>>>>> backbone?) >>>>>> >>>>> Yes, that's pretty much what ends up happening. >>>>> We have effectively extended the bridged LAN. >>>>> >>>>> >>>> Anoop, I'm reading the RBridge protocol specification >>>> >>> version 5 and it >>> >>>> seems to me that your comment is inconsistent with the spec. >>>> In section, >>>> 5.2.2.3, the spec says that the outer VLAN tag of TRILL data >>>> frames has >>>> the same VID as the inner tag. Is this section going to >>>> >> be changed? >> >>>> Futhermore, if we were to use different VIDs on outer VLAN >>>> tags then we >>>> would need to handle the multi-destination case where one >>>> would need to >>>> send a multi-destination frame per outer VID to communicate >>>> with the RBs >>>> in the distribution tree which are using different VIDs. Is this >>>> correct? >>>> >>>> Thanks, >>>> Hern >>>> Fulcrum Microsystems >>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge@postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge@postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VJOiQJ026146 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Wed, 31 Oct 2007 12:24:44 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9VJOTLS000631 for <rbridge@postel.org>; Wed, 31 Oct 2007 19:24:40 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9VJOTIe048294 for <rbridge@postel.org>; Wed, 31 Oct 2007 15:24:29 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9VIciEl005293; Wed, 31 Oct 2007 14:38:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9VIcdqS005288; Wed, 31 Oct 2007 14:38:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18216.52143.204420.651638@gargle.gargle.HOWL> Date: Wed, 31 Oct 2007 14:38:39 -0400 From: James Carlson <james.d.carlson@sun.com> To: Eric Gray <eric.gray@ericsson.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01DDF2DB@eusrcmw721.eamcs.ericsson.se> References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> <3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <18216.36269.214404.179226@gargle.gargle.HOWL> <941D5DCD8C42014FAF70FB7424686DCF01DDF2DB@eusrcmw721.eamcs.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 19:25:11 -0000 Status: RO Content-Length: 2342 Eric Gray writes: > What we would be saying - if we specify what you suggest - is > that the VID cannot change in going from A to B (or B to A). Effectively, yes. > This ability to change VID values is consistent with > existing device capabilities. There may be an administrative > domain boundary at this device, or the device may provide a > Q-in-Q function. If we are not saying this implementation > will be non-conformant, it's unreasonable to disallow this. I think there's a distinction to draw here. If an implementation has some sort of VLAN mapping function beyond the typical tagged/untagged distinction, that seems fine to me. The rule should be written to allow such a thing, because it's trivial to show that you could construct the same device out of a series of cascaded devices. That's not what I was understanding Silvano Gai to say. Instead, I was understanding his proposal as a sort of "pernicious bridging." By "pernicious bridging," I mean that the RBridge detects that it has disjoint groups of interfaces in the network that have the same VLAN ID configured. Based on this detection alone, it then finds shortest paths between those locations. Where those paths cross an interface that doesn't support the desired VLAN ID, we simply use a different one -- perhaps chosen at random (Silvano's slides don't describe this) -- and drive on. If it's based on administratively-configured mappings ("VLAN 3 can appear on this interface using VLAN ID 7"), then it doesn't sound at all like a problem to me, because the algorithms and administrative entries still make sense if you change all the numbers. If it just "happens" by virtue of discovering disjoint VLANs, then I think it's a problem. > What I thought Donald meant by "the same" was not with > respect to the "inner" VLAN ID - but with respect to all of > the frames sent using a particular physical interface. That > would be REALLY BAD. It would - for example - make it very > hard to do as good a job with link utilization using RBridges > as it is already possible to do using MSTP bridges. Yes; that'd be bad. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VHm0bq018411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 31 Oct 2007 10:48:01 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l9VHlvQu002220; Wed, 31 Oct 2007 11:47:57 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 12:47:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 12:47:47 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DDF347@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: Acgb48G1MhOQV4+OTEqyts4Xo9TpTwAAC0pgAAAn0xA= References: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "Zhi-Hern Loh" <zloh@fulcrummicro.com> X-OriginalArrivalTime: 31 Oct 2007 17:47:52.0560 (UTC) FILETIME=[29130700:01C81BE6] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9VHm0bq018411 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 17:48:45 -0000 Status: RO Content-Length: 7327 Anoop, This is a generic VLAN bridging problem, commonly dealt with using VLAN bridges today. Clearly, it is not the case that all VLAN bridges are required to use a common VLAN for frame forwarding. In addition, as I understand it (in part based on James' reply), we are NOT saying that the common VLAN you mention must be used for all frame forwarding - hence it is likely that the existence of a common VLAN does not necessarily fix the problem. Just to be clear, if we were saying that a common VLAN must be used for all forwarding between RBridges, it quickly becomes obvious that load-sharing based on VLAN separation becomes useless in practice. If load sharing based on VID is not useful, then MSTP already provides L2 forwarding that makes more efficient use of links than would be possible using RBridges (unless all RBridge-to-RBridge connections are via P2P links). -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Wednesday, October 31, 2007 1:33 PM > To: Zhi-Hern Loh; Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] RBridge: a case of study > Importance: High > > > Hern, > > That's one of the problems that we're trying to avoid > by forcing all RBridges on a bridged LAN to be configured > such that they are all reachable and see one another on > a single VLAN. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh > > Sent: Wednesday, October 31, 2007 10:17 AM > > To: Eric Gray > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] RBridge: a case of study > > > > Donald, > > > > In addition to Eric's questions, could you (or anyone else) > > explain what would happen in the following scenario? > > > > Toplogy: > > > > RBa > > / > > VID a > > / > > RBn-link X-----VID b------RBb > > > > Problem: > > > > RBn is connected to 2 VLANs on link/port X. Connectivity to > > RBa is via VLAN a, and connectivity to RBb is via VLAN b. > > > > Suppose that RBa and RBb are in the multi-destination > > distribution tree from RBn. For a multi-destination frame > > going out link/port X on RBn to RBa and RBb, what is the VID > > on the outer VLAN tag? Or could there be need to send 2 > > frames, one with VID a and another with VID b? > > > > > > > > Thanks, > > Hern > > Fulcrum Microsystems > > > > > > ----- Original Message ----- > > From: "Eric Gray" <eric.gray@ericsson.com> > > To: "Eastlake III Donald-LDE008" > > <Donald.Eastlake@motorola.com>, "Zhi-Hern Loh" > <zloh@fulcrummicro.com> > > Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> > > Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) > > America/Los_Angeles > > Subject: RE: [rbridge] RBridge: a case of study > > > > Donald, > > > > When you say "would all have the same Outer [VID]" > > - do you mean: > > > > 1) all frames MUST have the same VID within the an RBridge > > campus, > > 2) all frames forwarded from a (physical) port on one RBridge > > to a (physical) port on another RBridge MUST have the same > > VID, or > > 3) something else? > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > > Donald-LDE008 > > > Sent: Wednesday, October 31, 2007 12:22 AM > > > To: Zhi-Hern Loh > > > Cc: Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > Hi, > > > > > > Yes, as noted in protocol draft -05, the pseudo code was > unchanged > > > from > > > -04 and is out of date. > > > > > > As currently being discussed, the TRILL encapsulated data being > > > forwarded out a particular physical port would all have the > > same Outer > > > VLAN ID. > > > > > > Thanks, > > > Donald > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh > > > Sent: Tuesday, October 30, 2007 10:54 PM > > > To: Anoop Ghanwani > > > Cc: Developing a hybrid router/bridge.; Radia Perlman; > James Carlson > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > > > > ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > > > > > -----Original Message----- > > > > > From: rbridge-bounces@postel.org > > > > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > > > > Sent: Tuesday, October 30, 2007 2:37 PM > > > > > To: Silvano Gai > > > > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > > > > > Silvano Gai writes: > > > > > > Radia, > > > > > > > > > > > > I have added few slides to the example and I suggest that > > > > > we use it as > > > > > > a possible case of study for TRILL (of course, not the > > > only one). > > > > > > > > > > > > Let's see if the solutions we have discussed work on this > > > > example. > > > > > > > > > > > > The complete case of study is at: > > > > > > > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > > > > > > > I have a few narrow questions that I think might help me > > > > > understand this picture a bit better. (I probably have more > > > > > questions once I know the narrow answers. ;-}) > > > > > > > > Let me take a shot at answering these. > > > > > > > > > 1. After the proposed fix, should VLAN 3 on Cloud L > > be bridged > > > > > together with VLAN 3 on Cloud R, even though > the backbone > > > > itself > > > > > doesn't directly carry VLAN 3? (I.e., are TRILL > > > packets with > > > > > outer VLAN ID 7 or 8 and with inner VLAN 3 > present on the > > > > > backbone?) > > > > > > > > Yes, that's pretty much what ends up happening. > > > > We have effectively extended the bridged LAN. > > > > > > > > > > Anoop, I'm reading the RBridge protocol specification > > version 5 and it > > > seems to me that your comment is inconsistent with the spec. > > > In section, > > > 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > > > frames has > > > the same VID as the inner tag. Is this section going to > be changed? > > > > > > Futhermore, if we were to use different VIDs on outer VLAN > > > tags then we > > > would need to handle the multi-destination case where one > > > would need to > > > send a multi-destination frame per outer VID to communicate > > > with the RBs > > > in the distribution tree which are using different VIDs. Is this > > > correct? > > > > > > Thanks, > > > Hern > > > Fulcrum Microsystems > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VHXJ8b012190 for <rbridge@postel.org>; Wed, 31 Oct 2007 10:33:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,352,1188802800"; d="scan'208";a="20798327" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 31 Oct 2007 10:33:16 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 3C6A723846A; Wed, 31 Oct 2007 10:33:15 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 10:33:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 10:33:07 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E920442@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: Acgb48G1MhOQV4+OTEqyts4Xo9TpTwAAC0pg References: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Zhi-Hern Loh" <zloh@fulcrummicro.com>, "Eric Gray" <eric.gray@ericsson.com> X-OriginalArrivalTime: 31 Oct 2007 17:33:15.0855 (UTC) FILETIME=[1E8475F0:01C81BE4] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9VHXJ8b012190 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 17:34:01 -0000 Status: RO Content-Length: 5732 Hern, That's one of the problems that we're trying to avoid by forcing all RBridges on a bridged LAN to be configured such that they are all reachable and see one another on a single VLAN. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh > Sent: Wednesday, October 31, 2007 10:17 AM > To: Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > > Donald, > > In addition to Eric's questions, could you (or anyone else) > explain what would happen in the following scenario? > > Toplogy: > > RBa > / > VID a > / > RBn-link X-----VID b------RBb > > Problem: > > RBn is connected to 2 VLANs on link/port X. Connectivity to > RBa is via VLAN a, and connectivity to RBb is via VLAN b. > > Suppose that RBa and RBb are in the multi-destination > distribution tree from RBn. For a multi-destination frame > going out link/port X on RBn to RBa and RBb, what is the VID > on the outer VLAN tag? Or could there be need to send 2 > frames, one with VID a and another with VID b? > > > > Thanks, > Hern > Fulcrum Microsystems > > > ----- Original Message ----- > From: "Eric Gray" <eric.gray@ericsson.com> > To: "Eastlake III Donald-LDE008" > <Donald.Eastlake@motorola.com>, "Zhi-Hern Loh" <zloh@fulcrummicro.com> > Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> > Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) > America/Los_Angeles > Subject: RE: [rbridge] RBridge: a case of study > > Donald, > > When you say "would all have the same Outer [VID]" > - do you mean: > > 1) all frames MUST have the same VID within the an RBridge > campus, > 2) all frames forwarded from a (physical) port on one RBridge > to a (physical) port on another RBridge MUST have the same > VID, or > 3) something else? > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Wednesday, October 31, 2007 12:22 AM > > To: Zhi-Hern Loh > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] RBridge: a case of study > > > > Hi, > > > > Yes, as noted in protocol draft -05, the pseudo code was unchanged > > from > > -04 and is out of date. > > > > As currently being discussed, the TRILL encapsulated data being > > forwarded out a particular physical port would all have the > same Outer > > VLAN ID. > > > > Thanks, > > Donald > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh > > Sent: Tuesday, October 30, 2007 10:54 PM > > To: Anoop Ghanwani > > Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > > > > -----Original Message----- > > > > From: rbridge-bounces@postel.org > > > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > > > Sent: Tuesday, October 30, 2007 2:37 PM > > > > To: Silvano Gai > > > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > > > Silvano Gai writes: > > > > > Radia, > > > > > > > > > > I have added few slides to the example and I suggest that > > > > we use it as > > > > > a possible case of study for TRILL (of course, not the > > only one). > > > > > > > > > > Let's see if the solutions we have discussed work on this > > > example. > > > > > > > > > > The complete case of study is at: > > > > > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > > > > > I have a few narrow questions that I think might help me > > > > understand this picture a bit better. (I probably have more > > > > questions once I know the narrow answers. ;-}) > > > > > > Let me take a shot at answering these. > > > > > > > 1. After the proposed fix, should VLAN 3 on Cloud L > be bridged > > > > together with VLAN 3 on Cloud R, even though the backbone > > > itself > > > > doesn't directly carry VLAN 3? (I.e., are TRILL > > packets with > > > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > > > backbone?) > > > > > > Yes, that's pretty much what ends up happening. > > > We have effectively extended the bridged LAN. > > > > > > > Anoop, I'm reading the RBridge protocol specification > version 5 and it > > seems to me that your comment is inconsistent with the spec. > > In section, > > 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > > frames has > > the same VID as the inner tag. Is this section going to be changed? > > > > Futhermore, if we were to use different VIDs on outer VLAN > > tags then we > > would need to handle the multi-destination case where one > > would need to > > send a multi-destination frame per outer VID to communicate > > with the RBs > > in the distribution tree which are using different VIDs. Is this > > correct? > > > > Thanks, > > Hern > > Fulcrum Microsystems > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VHRTGQ010037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 31 Oct 2007 10:27:29 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l9VHRJQd028378; Wed, 31 Oct 2007 12:27:29 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 12:27:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 12:27:18 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DDF2DB@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <18216.36269.214404.179226@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: AcgbyZPXvavw21gNTGqjunT28RL/TwABz46A References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com><18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com><3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> <18216.36269.214404.179226@gargle.gargle.HOWL> From: "Eric Gray" <eric.gray@ericsson.com> To: "James Carlson" <james.d.carlson@sun.com> X-OriginalArrivalTime: 31 Oct 2007 17:27:24.0107 (UTC) FILETIME=[4CDBF9B0:01C81BE3] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9VHRTGQ010037 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 17:28:05 -0000 Status: RO Content-Length: 4194 James, That is kind of what I though, and - IMO - it seems to be pointless (over) specification. Still, it's better than other possible interpretation for what Donald was saying (see toward the end, below). Consider this simplified representation of a (specific) RBridge implementation: _________________________ _ _ | ________________ | A | B | |C | D ---+-[*]--+ Q-Bridge +-[?]-+--- | |________________| | | | | RBridge | |_________________________ _ _| It's important to realize that this is one potential implementation - used as an example. In this example: o A is the port connecting this RBridge to other RBridges; o [*] represents the process we're defining for preparing a frame to be ingressed on to, or egressed off of, the RBridge campus; o B is an internal port, connecting that function to an internal Q-Bridge; o C is an internal port connecting this same internal Q-Bridge to any arbitrary set of other functions within the implementation - possibly including other internal Q-Bridges; o [?] represents the arbitrary (set of) internal functions (again, possibly including other internal Q-Bridges) connecting internal port C to port D; o D is the port connecting this RBridge to end stations external to the RBridge campus. What we would be saying - if we specify what you suggest - is that the VID cannot change in going from A to B (or B to A). That may be a very reasonable thing to say, but we have to be careful in saying it. It is important NOT to be saying that the VID cannot change in going from A to D (or D to A). The externally visible behavior - for this implementation may include changing the VID for any specific set of frames at 'B', at 'C', or within the set of functions represented by '[?]'. This ability to change VID values is consistent with existing device capabilities. There may be an administrative domain boundary at this device, or the device may provide a Q-in-Q function. If we are not saying this implementation will be non-conformant, it's unreasonable to disallow this. What I thought Donald meant by "the same" was not with respect to the "inner" VLAN ID - but with respect to all of the frames sent using a particular physical interface. That would be REALLY BAD. It would - for example - make it very hard to do as good a job with link utilization using RBridges as it is already possible to do using MSTP bridges. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Wednesday, October 31, 2007 10:14 AM > To: Eric Gray > Cc: Eastlake III Donald-LDE008; Zhi-Hern Loh; Developing a > hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > Importance: High > > Eric Gray writes: > > Donald, > > > > When you say "would all have the same Outer [VID]" > > - do you mean: > > > > 1) all frames MUST have the same VID within the an RBridge > > campus, > > 2) all frames forwarded from a (physical) port on one RBridge > > to a (physical) port on another RBridge MUST have the same > > VID, or > > 3) something else? > > (I'm not Donald, but ...) > > My understanding was more like: > > 3) Where an outer VLAN tag is present, all frames transmitted by an > RBridge must have the same inner and outer VLAN tag numbers. > Where an outer VLAN tag is not present, the implicit tag for that > port must match or be compatible with the inner tag. > > ... which would be consistent with "traditional" bridge behavior and > would effectively rule out the type of solution that Silvano Gai has > been proposing. > > The distinction with (2) in your list is that (2) appears to rule out > the use of so-called "tagged" or leaf or ingress ports, forcing all > ports to carry VLAN tags. > > -- > James Carlson, Solaris Networking > <james.d.carlson@sun.com> > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > Received: from smtp.fulcrummicro.com (smtp.fulcrummicro.com [66.59.247.212]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VHHRDo006477 for <rbridge@postel.org>; Wed, 31 Oct 2007 10:17:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.fulcrummicro.com (Postfix) with ESMTP id E8E87DC8003; Wed, 31 Oct 2007 10:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.4 X-Spam-Level: X-Spam-Status: No, score=-4.4 tagged_above=-10 required=4 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, SPF_HELO_PASS=-0.001] Received: from smtp.fulcrummicro.com ([127.0.0.1]) by localhost (nepenthes.hq.fulcrummicro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdA94Pga56E9; Wed, 31 Oct 2007 10:17:26 -0700 (PDT) Received: from nepenthes.hq.fulcrummicro.com (localhost.localdomain [127.0.0.1]) by smtp.fulcrummicro.com (Postfix) with ESMTP id 5538C33862B; Wed, 31 Oct 2007 10:17:26 -0700 (PDT) Date: Wed, 31 Oct 2007 10:17:26 -0700 (PDT) From: Zhi-Hern Loh <zloh@fulcrummicro.com> To: Eric Gray <eric.gray@ericsson.com> Message-ID: <22446679.673821193851046308.JavaMail.root@nepenthes.hq.fulcrummicro.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.0.0.66] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zloh@fulcrummicro.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 17:18:12 -0000 Status: RO Content-Length: 4763 Donald, In addition to Eric's questions, could you (or anyone else) explain what would happen in the following scenario? Toplogy: RBa / VID a / RBn-link X-----VID b------RBb Problem: RBn is connected to 2 VLANs on link/port X. Connectivity to RBa is via VLAN a, and connectivity to RBb is via VLAN b. Suppose that RBa and RBb are in the multi-destination distribution tree from RBn. For a multi-destination frame going out link/port X on RBn to RBa and RBb, what is the VID on the outer VLAN tag? Or could there be need to send 2 frames, one with VID a and another with VID b? Thanks, Hern Fulcrum Microsystems ----- Original Message ----- From: "Eric Gray" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Zhi-Hern Loh" <zloh@fulcrummicro.com> Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Sent: Wednesday, October 31, 2007 4:16:33 AM (GMT-0800) America/Los_Angeles Subject: RE: [rbridge] RBridge: a case of study Donald, When you say "would all have the same Outer [VID]" - do you mean: 1) all frames MUST have the same VID within the an RBridge campus, 2) all frames forwarded from a (physical) port on one RBridge to a (physical) port on another RBridge MUST have the same VID, or 3) something else? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Wednesday, October 31, 2007 12:22 AM > To: Zhi-Hern Loh > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > > Hi, > > Yes, as noted in protocol draft -05, the pseudo code was > unchanged from > -04 and is out of date. > > As currently being discussed, the TRILL encapsulated data being > forwarded out a particular physical port would all have the same Outer > VLAN ID. > > Thanks, > Donald > > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On > Behalf Of Zhi-Hern Loh > Sent: Tuesday, October 30, 2007 10:54 PM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson > Subject: Re: [rbridge] RBridge: a case of study > > > ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > > Sent: Tuesday, October 30, 2007 2:37 PM > > > To: Silvano Gai > > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > Silvano Gai writes: > > > > Radia, > > > > > > > > I have added few slides to the example and I suggest that > > > we use it as > > > > a possible case of study for TRILL (of course, not the > only one). > > > > > > > > Let's see if the solutions we have discussed work on this > > example. > > > > > > > > The complete case of study is at: > > > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > > > I have a few narrow questions that I think might help me > > > understand this picture a bit better. (I probably have more > > > questions once I know the narrow answers. ;-}) > > > > Let me take a shot at answering these. > > > > > 1. After the proposed fix, should VLAN 3 on Cloud L be bridged > > > together with VLAN 3 on Cloud R, even though the backbone > > itself > > > doesn't directly carry VLAN 3? (I.e., are TRILL > packets with > > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > > backbone?) > > > > Yes, that's pretty much what ends up happening. > > We have effectively extended the bridged LAN. > > > > Anoop, I'm reading the RBridge protocol specification version 5 and it > seems to me that your comment is inconsistent with the spec. > In section, > 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > frames has > the same VID as the inner tag. Is this section going to be changed? > > Futhermore, if we were to use different VIDs on outer VLAN > tags then we > would need to handle the multi-destination case where one > would need to > send a multi-destination frame per outer VID to communicate > with the RBs > in the distribution tree which are using different VIDs. Is this > correct? > > Thanks, > Hern > Fulcrum Microsystems > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VF06so016058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Wed, 31 Oct 2007 08:00:07 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9VExwwu027926 for <rbridge@postel.org>; Wed, 31 Oct 2007 15:00:06 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9VExw9I062226 for <rbridge@postel.org>; Wed, 31 Oct 2007 10:59:58 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9VEEQdW002007; Wed, 31 Oct 2007 10:14:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9VEE5d9002000; Wed, 31 Oct 2007 10:14:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18216.36269.214404.179226@gargle.gargle.HOWL> Date: Wed, 31 Oct 2007 10:14:05 -0400 From: James Carlson <james.d.carlson@sun.com> To: Eric Gray <eric.gray@ericsson.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> <3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 15:01:02 -0000 Status: RO Content-Length: 1215 Eric Gray writes: > Donald, > > When you say "would all have the same Outer [VID]" > - do you mean: > > 1) all frames MUST have the same VID within the an RBridge > campus, > 2) all frames forwarded from a (physical) port on one RBridge > to a (physical) port on another RBridge MUST have the same > VID, or > 3) something else? (I'm not Donald, but ...) My understanding was more like: 3) Where an outer VLAN tag is present, all frames transmitted by an RBridge must have the same inner and outer VLAN tag numbers. Where an outer VLAN tag is not present, the implicit tag for that port must match or be compatible with the inner tag. ... which would be consistent with "traditional" bridge behavior and would effectively rule out the type of solution that Silvano Gai has been proposing. The distinction with (2) in your list is that (2) appears to rule out the use of so-called "tagged" or leaf or ingress ports, forcing all ports to carry VLAN tags. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VDHLDV006998 for <rbridge@postel.org>; Wed, 31 Oct 2007 06:17:22 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9VDHLSd008143 for <rbridge@postel.org>; Wed, 31 Oct 2007 13:17:21 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9VDHLP8046711 for <rbridge@postel.org>; Wed, 31 Oct 2007 09:17:21 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9VD1lG3001666; Wed, 31 Oct 2007 09:01:47 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9VD1lBS001663; Wed, 31 Oct 2007 09:01:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18216.31931.91042.199304@gargle.gargle.HOWL> Date: Wed, 31 Oct 2007 09:01:47 -0400 From: James Carlson <james.d.carlson@Sun.COM> To: Silvano Gai <sgai@nuovasystems.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20260671F@nuova-ex1.hq.nuovaimpresa.com> References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <18215.42006.843620.853514@gargle.gargle.HOWL> <34BDD2A93E5FD84594BB230DD6C18EA20260671F@nuova-ex1.hq.nuovaimpresa.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@Sun.COM Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 13:17:47 -0000 Status: RO Content-Length: 3141 Silvano Gai writes: > James, > > -- snip -- > > > > > 3. Suppose we were to configure VLAN 7 within Cloud L. Would you > > expect H1 to be able to access nodes within the backbone Cloud G > > at that point? (I'm trying to figure out whether the "X" and > > "Y" interfaces are of fundamentally different types or if the > > RBridges are just bridges. I suspect they're different.) > > > > I have produced an updated drawing to cover the case of "hybrid ports". > > http://www.ip6.com/example-v2.ppt > > In this drawing I assume that H5 is able to talk with H6. That new diagram still does not show the confusing situation that I was referring to above. In fact, it shows a situation that is essentially _identical_ to the previous one you showed in terms of added bridge functionality. To replicate the confusing functionality, consider what happens when adding a host (call it H7) attached to Cloud P. Without VLAN 7 in Cloud P, H7 will not be able to participate in VLAN 7 even though all attached RBridges are in fact transiting VLAN 7 traffic on that network. If VLAN 7 is provisioned onto Cloud P (exactly how does this happen?), then H7 can play. I see no functionality comparable to this in the existing draft. The core change that I think you're asserting here is that when the user deploys RBridges, the network automatically discovers all of the far-flung and disjoint islands of VLAN ID usage, and glues those together by tunneling over whatever VLANs might be in the way between them. It no longer matters what configuration separates them. This is quite a departure from traditional bridging, and I think it's likely to be both confusing and dangerous, so I'm not sure it ought to be the default behavior. In today's bridges, if I configure a trunk port such that VLAN 3 traffic does not traverse the link, then -- quite simply -- no packets with VLAN ID set to 3 go over that link. In the new model, that restriction does not apply. If I say "allow VLAN ID 3," then both an O-RBridge (original RBridge as I understood it) and the new G-RBridge (Silvano Gai modified RBridge) will allow VLAN ID 3 across the link. If I say "disallow VLAN ID 3 and allow only VLAN 7," then the O-RBridge would stop passing VLAN ID 3 traffic, but the G-RBridge would simply switch the outer VLAN ID number and use VLAN 7 effectively as a tunnel to pass VLAN 3. The TRILL-encapsulated packets will have VLAN 3 on the inside and VLAN 7 on the outside. I'm not at all sure that's a good thing. I can see why folks who are struggling with the unkempt nature of VLAN ID provisioning across complex (and politically divided) networks would be excited about a "do what I mean" option -- particularly if it means that I don't have to tell my local IT group to reconfigure switches to allow separated chunks of my new VLAN to connect together -- but the side-effects seem extreme. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VCaCCk022095 for <rbridge@postel.org>; Wed, 31 Oct 2007 05:36:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 05:36:12 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20260672B@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E920368@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLANtags onRBridge-RBridgepackets? thread-index: AcgbVO4fQhkPBX+9TiW3zTiSUJMq3AAB11zQABUCQIA= References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590551@nuova-ex1.hq.nuovaimpresa.com> <4727CADC.8000902@sun.com> <4C94DE2070B172459E4F1EE14BD2364E920368@HQ-EXCH-5.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9VCaCCk022095 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLANtags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 12:36:39 -0000 Status: RO Content-Length: 300 Anoop, Radia, The problem pointed out by Anoop, i.e. > > The problem with this is that there may be RB's sending > hellos on a VLAN that other RB's don't see. As a result > the adjacency creation may not be correct. It is the key issue we need to solve: we need a ROBUST solution. -- Silvano Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9VBGgHA025613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 31 Oct 2007 04:16:42 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9VBGa69009297; Wed, 31 Oct 2007 05:16:36 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 06:16:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 06:16:33 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DDEC7A@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: Acgba4lL3XBl3BwRSESWfpWFAnXLKAACbjSgAA5ZBIA= References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com><18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> <3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Zhi-Hern Loh" <zloh@fulcrummicro.com> X-OriginalArrivalTime: 31 Oct 2007 11:16:36.0401 (UTC) FILETIME=[80317210:01C81BAF] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9VBGgHA025613 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 11:17:14 -0000 Status: RO Content-Length: 3710 Donald, When you say "would all have the same Outer [VID]" - do you mean: 1) all frames MUST have the same VID within the an RBridge campus, 2) all frames forwarded from a (physical) port on one RBridge to a (physical) port on another RBridge MUST have the same VID, or 3) something else? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Wednesday, October 31, 2007 12:22 AM > To: Zhi-Hern Loh > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] RBridge: a case of study > > Hi, > > Yes, as noted in protocol draft -05, the pseudo code was > unchanged from > -04 and is out of date. > > As currently being discussed, the TRILL encapsulated data being > forwarded out a particular physical port would all have the same Outer > VLAN ID. > > Thanks, > Donald > > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On > Behalf Of Zhi-Hern Loh > Sent: Tuesday, October 30, 2007 10:54 PM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson > Subject: Re: [rbridge] RBridge: a case of study > > > ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > > Sent: Tuesday, October 30, 2007 2:37 PM > > > To: Silvano Gai > > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > > Subject: Re: [rbridge] RBridge: a case of study > > > > > > Silvano Gai writes: > > > > Radia, > > > > > > > > I have added few slides to the example and I suggest that > > > we use it as > > > > a possible case of study for TRILL (of course, not the > only one). > > > > > > > > Let's see if the solutions we have discussed work on this > > example. > > > > > > > > The complete case of study is at: > > > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > > > I have a few narrow questions that I think might help me > > > understand this picture a bit better. (I probably have more > > > questions once I know the narrow answers. ;-}) > > > > Let me take a shot at answering these. > > > > > 1. After the proposed fix, should VLAN 3 on Cloud L be bridged > > > together with VLAN 3 on Cloud R, even though the backbone > > itself > > > doesn't directly carry VLAN 3? (I.e., are TRILL > packets with > > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > > backbone?) > > > > Yes, that's pretty much what ends up happening. > > We have effectively extended the bridged LAN. > > > > Anoop, I'm reading the RBridge protocol specification version 5 and it > seems to me that your comment is inconsistent with the spec. > In section, > 5.2.2.3, the spec says that the outer VLAN tag of TRILL data > frames has > the same VID as the inner tag. Is this section going to be changed? > > Futhermore, if we were to use different VIDs on outer VLAN > tags then we > would need to handle the multi-destination case where one > would need to > send a multi-destination frame per outer VID to communicate > with the RBs > in the distribution tree which are using different VIDs. Is this > correct? > > Thanks, > Hern > Fulcrum Microsystems > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V9Yml4022061 for <rbridge@postel.org>; Wed, 31 Oct 2007 02:34:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 02:32:16 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20260671F@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <18215.42006.843620.853514@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study thread-index: AcgbPjbk0pcHhkzYTRajoR3ofe5eTQAYlM2A References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <18215.42006.843620.853514@gargle.gargle.HOWL> From: "Silvano Gai" <sgai@nuovasystems.com> To: "James Carlson" <james.d.carlson@Sun.COM> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V9Yml4022061 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@Sun.COM Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 09:35:04 -0000 Status: RO Content-Length: 557 James, -- snip -- > > 3. Suppose we were to configure VLAN 7 within Cloud L. Would you > expect H1 to be able to access nodes within the backbone Cloud G > at that point? (I'm trying to figure out whether the "X" and > "Y" interfaces are of fundamentally different types or if the > RBridges are just bridges. I suspect they're different.) > I have produced an updated drawing to cover the case of "hybrid ports". http://www.ip6.com/example-v2.ppt In this drawing I assume that H5 is able to talk with H6. -- Silvano Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V8xvmp010561 for <rbridge@postel.org>; Wed, 31 Oct 2007 01:59:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 01:57:21 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20260671D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study thread-index: AcgbQSObqjxw8HImSBq/dBXdND2s9AAHksMQAA8F3YA= References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <18215.42006.843620.853514@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "James Carlson" <james.d.carlson@Sun.COM> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V8xvmp010561 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@Sun.COM Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 09:00:07 -0000 Status: RO Content-Length: 797 Anoop wrote: --- snip --- > > This is where I think would help to introduce some > additional terminology in the spec. Just like MPLS > LSRs have ingress, core, and egress functionality, > I think we should have similar functions for RBridging. > We could have access ports, trill ports and hybrid > ports. From access ports, we only accept non-trill > encap'ed frames, from trill ports, we accept only > trill-encap'ed frames, and finally, from hybrid ports > we accept either. Today we only allow hybrid ports > and perhaps that's OK as a spec. > I strongly second Anoop proposal of adding terminology related to access, core, hybrid, ingress, egress, etc. The lack of such terminology in TRILL has been cause of confusion and it has slow down the progress of the spec. -- Silvano Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V8kkk8006526 for <rbridge@postel.org>; Wed, 31 Oct 2007 01:46:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 01:46:34 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20260671C@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <43B6589BD8C21C43AE2FE551397D4E878FD824@HQ-EXCH-4.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study thread-index: AcganwcSkIHaTwrbRRmmGg4yRIB1sgASFJSwABcMKSAAFbMVYA== References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <43B6589BD8C21C43AE2FE551397D4E878FD824@HQ-EXCH-4.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Jian Liu" <jliu@Brocade.COM>, <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V8kkk8006526 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 08:47:08 -0000 Status: RO Content-Length: 1415 inline > -----Original Message----- > From: Jian Liu [mailto:jliu@Brocade.COM] > Sent: Tuesday, October 30, 2007 3:28 PM > To: Silvano Gai; Radia.Perlman@sun.com > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] RBridge: a case of study > > Silvano, > > A couple of questions: > > 1. In the proposed solution, what is considered in the TRILL domain? It > seems TRILL domain includes RBridge 1-4 and backbone cloud G, correct? Yes, It may as well be the whole picture. > 2. Are there regular bridges or RBridges in backbone cloud G? All the clouds are built with regular IEEE 802.1Q bridges -- Silvano > > Regards, > Jian > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Silvano Gai > Sent: Tuesday, October 30, 2007 4:26 AM > To: Radia.Perlman@sun.com > Cc: Developing a hybrid router/bridge. > Subject: [rbridge] RBridge: a case of study > > Radia, > > I have added few slides to the example and I suggest that we use it as a > possible case of study for TRILL (of course, not the only one). > > Let's see if the solutions we have discussed work on this example. > > The complete case of study is at: > > http://www.ip6.com/acme-example-v1.ppt > > -- Silvano > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V8jGpr005811 for <rbridge@postel.org>; Wed, 31 Oct 2007 01:45:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2007 01:45:00 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20260671B@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study thread-index: AcgbQSObqjxw8HImSBq/dBXdND2s9AAHksMQAA62YUA= References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <18215.42006.843620.853514@gargle.gargle.HOWL> <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "James Carlson" <james.d.carlson@Sun.COM> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V8jGpr005811 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@Sun.COM Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 08:45:32 -0000 Status: RO Content-Length: 3341 I agree with Anoop answers -- Silvano > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Tuesday, October 30, 2007 6:54 PM > To: James Carlson; Silvano Gai > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > Subject: RE: [rbridge] RBridge: a case of study > > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > Sent: Tuesday, October 30, 2007 2:37 PM > > To: Silvano Gai > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > Subject: Re: [rbridge] RBridge: a case of study > > > > Silvano Gai writes: > > > Radia, > > > > > > I have added few slides to the example and I suggest that > > we use it as > > > a possible case of study for TRILL (of course, not the only one). > > > > > > Let's see if the solutions we have discussed work on this example. > > > > > > The complete case of study is at: > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > I have a few narrow questions that I think might help me > > understand this picture a bit better. (I probably have more > > questions once I know the narrow answers. ;-}) > > Let me take a shot at answering these. > > > 1. After the proposed fix, should VLAN 3 on Cloud L be bridged > > together with VLAN 3 on Cloud R, even though the backbone itself > > doesn't directly carry VLAN 3? (I.e., are TRILL packets with > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > backbone?) > > Yes, that's pretty much what ends up happening. > We have effectively extended the bridged LAN. > > > 2. What happened to the routing that once went on? It was > > previously possible to route between these VLANs, but in the new > > diagram, it's not. Is routing between these networks > > unimportant, or does it take place elsewhere, or must RBridges > > both bridge and route in this scenario? > > Routing can continue to happen wherever it was happening. > The Rbridge by itself doesn't do routing, but there's no > reason why one cannot build a device that does bridging, > RBridging, and routing. > > > 3. Suppose we were to configure VLAN 7 within Cloud L. Would you > > expect H1 to be able to access nodes within the backbone Cloud G > > at that point? (I'm trying to figure out whether the "X" and > > "Y" interfaces are of fundamentally different types or if the > > RBridges are just bridges. I suspect they're different.) > > This is where I think would help to introduce some > additional terminology in the spec. Just like MPLS > LSRs have ingress, core, and egress functionality, > I think we should have similar functions for RBridging. > We could have access ports, trill ports and hybrid > ports. From access ports, we only accept non-trill > encap'ed frames, from trill ports, we accept only > trill-encap'ed frames, and finally, from hybrid ports > we accept either. Today we only allow hybrid ports > and perhaps that's OK as a spec. > > Anyway, back to the specifics of your question: If you > did configure VLAN 7 within cloud L, then the RBridges > labeled "Router 1" and "Router 2" would have 2 of their > ports configured to be on VLAN 7 and would simply bridge > between those ports. > > Anoop Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9V4MNJJ017054 for <rbridge@postel.org>; Tue, 30 Oct 2007 21:22:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1193804540!19472200!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 12314 invoked from network); 31 Oct 2007 04:22:20 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-9.tower-128.messagelabs.com with SMTP; 31 Oct 2007 04:22:20 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l9V4MJ3j003466 for <rbridge@postel.org>; Tue, 30 Oct 2007 21:22:19 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l9V4MIoj028704 for <rbridge@postel.org>; Tue, 30 Oct 2007 23:22:19 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9V4MHqk028693 for <rbridge@postel.org>; Tue, 30 Oct 2007 23:22:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 31 Oct 2007 00:22:15 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900332B1E3@de01exm64.ds.mot.com> In-Reply-To: <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: Acgba4lL3XBl3BwRSESWfpWFAnXLKAACbjSg References: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Zhi-Hern Loh" <zloh@fulcrummicro.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V4MNJJ017054 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 04:23:26 -0000 Status: RO Content-Length: 2716 Hi, Yes, as noted in protocol draft -05, the pseudo code was unchanged from -04 and is out of date. As currently being discussed, the TRILL encapsulated data being forwarded out a particular physical port would all have the same Outer VLAN ID. Thanks, Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Zhi-Hern Loh Sent: Tuesday, October 30, 2007 10:54 PM To: Anoop Ghanwani Cc: Developing a hybrid router/bridge.; Radia Perlman; James Carlson Subject: Re: [rbridge] RBridge: a case of study ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > Sent: Tuesday, October 30, 2007 2:37 PM > > To: Silvano Gai > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > Subject: Re: [rbridge] RBridge: a case of study > > > > Silvano Gai writes: > > > Radia, > > > > > > I have added few slides to the example and I suggest that > > we use it as > > > a possible case of study for TRILL (of course, not the only one). > > > > > > Let's see if the solutions we have discussed work on this > example. > > > > > > The complete case of study is at: > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > I have a few narrow questions that I think might help me > > understand this picture a bit better. (I probably have more > > questions once I know the narrow answers. ;-}) > > Let me take a shot at answering these. > > > 1. After the proposed fix, should VLAN 3 on Cloud L be bridged > > together with VLAN 3 on Cloud R, even though the backbone > itself > > doesn't directly carry VLAN 3? (I.e., are TRILL packets with > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > backbone?) > > Yes, that's pretty much what ends up happening. > We have effectively extended the bridged LAN. > Anoop, I'm reading the RBridge protocol specification version 5 and it seems to me that your comment is inconsistent with the spec. In section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL data frames has the same VID as the inner tag. Is this section going to be changed? Futhermore, if we were to use different VIDs on outer VLAN tags then we would need to handle the multi-destination case where one would need to send a multi-destination frame per outer VID to communicate with the RBs in the distribution tree which are using different VIDs. Is this correct? Thanks, Hern Fulcrum Microsystems _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V4D4us014292 for <rbridge@postel.org>; Tue, 30 Oct 2007 21:13:04 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQR009FGD1MTT00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 30 Oct 2007 21:12:58 -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 <0JQR00EX4D1LF630@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 30 Oct 2007 21:12:58 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [67.161.89.58]) by mail-srv.sfvic.sunlabs.com (mshttpd); Tue, 30 Oct 2007 21:12:57 -0700 Date: Tue, 30 Oct 2007 21:12:57 -0700 From: Radia.Perlman@sun.com To: Zhi-Hern Loh <zloh@fulcrummicro.com> Message-id: <306310397c7f.47279e59@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 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 04:14:06 -0000 Status: RO Content-Length: 1160 Thanks for pointing that out Hern. Serves me right for not reading the pseudocode part of the spec, which got added later for clarity. My understanding has always been that the outer VLAN was just a way to carry the frame across the layer 2 cloud from one RBridge to another, and would be completely independent of the inner one. Radia ----- Original Message ----- From: Zhi-Hern Loh <zloh@fulcrummicro.com> Date: Tuesday, October 30, 2007 7:53 pm Subject: Re: [rbridge] RBridge: a case of study > > Anoop, I'm reading the RBridge protocol specification version 5 and > it seems to me that your comment is inconsistent with the spec. In > section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL > data frames has the same VID as the inner tag. Is this section > going to be changed? > > Futhermore, if we were to use different VIDs on outer VLAN tags > then we would need to handle the multi-destination case where one > would need to send a multi-destination frame per outer VID to > communicate with the RBs in the distribution tree which are using > different VIDs. Is this correct? > > Thanks, > Hern > Fulcrum Microsystems > > Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V41YFW010684 for <rbridge@postel.org>; Tue, 30 Oct 2007 21:01:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="244762639" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2007 21:01:34 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9V41Veu030237; Tue, 30 Oct 2007 21:01:31 -0700 Received: from [10.21.65.180] (sjc-vpn3-436.cisco.com [10.21.65.180]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9V41VnE003033; Wed, 31 Oct 2007 04:01:31 GMT Message-ID: <4727FE1C.7010804@cisco.com> Date: Tue, 30 Oct 2007 21:01:32 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590551@nuova-ex1.hq.nuovaimpresa.com> <4727CADC.8000902@sun.com> In-Reply-To: <4727CADC.8000902@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2859; t=1193803291; x=1194667291; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Final=20outcome=20of=20outer=20VLAN=09tag s=09onRBridge-RBridgepackets? |Sender:=20; bh=9fHi20V6u3sAU4E6u4Gp2TuK2FLibRyL5SIM1bP69iA=; b=ob4g94fYkyM2qQj7Hkx91qKCR0ct75Yi3EnSvv2hTWt8AJq0+V3fwYCAj/jcOWy9URO5wuvj oFncqggi3phtv0ETvnoipbODInuORgdIgwej6GmKVWR/Kagyk1gdo/uX; Authentication-Results: sj-dkim-4; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 04:02:23 -0000 Status: RO Content-Length: 2781 Radia, I've been swamped at work and have been travelling as well. Most of my issues were related to sending Hello on a single VLAN only, be it VLAN 1 or configurable. I'll get back to you in the next couple of days after I have caught up on the discussions, Dinesh Radia Perlman wrote: > Silvano Gai wrote: > >> "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have >> explained why. >> >> "single VLAN per layer 2 cloud" may be workable, but I need to see the >> details of the algorithm to see if there are corner cases. >> >> If we can agree to concentrate our focus on a "single VLAN per layer 2 >> cloud" we have made some progress. >> >> -- Silvano >> >> >> > I can live with "single VLAN, configurable, default=1". I'd recommend > that regardless of > the VLAN you are configured to send a Hello on, you accept Hellos on any > VLAN you > are capable of receiving traffic on, and that each DRB tells all the > other RBridges on that cloud > what VLAN to send on, so that they all wind up sending RBridge traffic > on the same VLAN. > > I think the only complexity/overhead it adds over "VLAN 1, > nonconfigurable is" > > a) something configurable to document and present in the management > interface (the VLAN on > which to send Hellos) > b) until a DRB is elected, there might be lots of RBridges transmitting > on different VLANs because > each might be configured with a different VLAN > c) if there are multiple (say k) DRBs (because for load splitting each > of them is DRB for > a different (nonoverlapping) set > of VLANs), then there will be k times as many Hellos being sent > d) I think there might be a slightly higher probability that there will > be misconfiguration such > as telling each RBridge a different set of VLANs to talk on, but the > safeguards that I specified > in previous emails (listen to BPDUs, report root bridge in pseudonode > LSP, don't decapsulate > from an ingress RBridge that you haven't seen all the LSPs from, wait > until you've synchrornized > LSP databases with your neighbors when you first start up) will prevent > loops in these cases, and > at worst orphan parts of the layer 2 cloud from the rest of the campus. > > So...can everyone live with this? (Silvano -- as you said above, > you promised to think about whether there > were any corner cases to worry about. You also said you wanted to see > "the whole algorithm > specified". I'll do that in a separate email. > > Radia > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V3v2GE009544 for <rbridge@postel.org>; Tue, 30 Oct 2007 20:57:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="411901720" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Oct 2007 20:57:02 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9V3v1HQ014915; Tue, 30 Oct 2007 20:57:01 -0700 Received: from [10.21.65.180] (sjc-vpn3-436.cisco.com [10.21.65.180]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9V3v1pM006258; Wed, 31 Oct 2007 03:57:01 GMT Message-ID: <4727FD0E.9020901@cisco.com> Date: Tue, 30 Oct 2007 20:57:02 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Zhi-Hern Loh <zloh@fulcrummicro.com> References: <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> In-Reply-To: <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2639; t=1193803021; x=1194667021; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20RBridge=3A=20a=20case=20of=20study |Sender:=20; bh=tCzCNEvM+HBCw9PPgT0dquy3kL7nbMnxOKBM87gubVg=; b=RG4ZuZ6NPc+Uqz93idfl+uU1fOcGAA8p0USUyzgzzTSmd70+d0geaWQaFALDggHsFEJ8H2+B fiQIjBIsgUbym7ETEBqBKGpTJFO+VHzu8aW8hjaw4VMwJ0uObcCOPP7B; Authentication-Results: sj-dkim-2; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@Sun.COM>, James Carlson <james.d.carlson@Sun.COM> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 03:57:55 -0000 Status: RO Content-Length: 2567 The spec is a trifle out of date and will be fixed once we all agree on some of the outstanding issues, Dinesh Zhi-Hern Loh wrote: > ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > >>> -----Original Message----- >>> From: rbridge-bounces@postel.org >>> [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson >>> Sent: Tuesday, October 30, 2007 2:37 PM >>> To: Silvano Gai >>> Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM >>> Subject: Re: [rbridge] RBridge: a case of study >>> >>> Silvano Gai writes: >>> >>>> Radia, >>>> >>>> I have added few slides to the example and I suggest that >>>> >>> we use it as >>> >>>> a possible case of study for TRILL (of course, not the only one). >>>> >>>> Let's see if the solutions we have discussed work on this >>>> >> example. >> >>>> The complete case of study is at: >>>> >>>> http://www.ip6.com/acme-example-v1.ppt >>>> >>> I have a few narrow questions that I think might help me >>> understand this picture a bit better. (I probably have more >>> questions once I know the narrow answers. ;-}) >>> >> Let me take a shot at answering these. >> >> >>> 1. After the proposed fix, should VLAN 3 on Cloud L be bridged >>> together with VLAN 3 on Cloud R, even though the backbone >>> >> itself >> >>> doesn't directly carry VLAN 3? (I.e., are TRILL packets with >>> outer VLAN ID 7 or 8 and with inner VLAN 3 present on the >>> backbone?) >>> >> Yes, that's pretty much what ends up happening. >> We have effectively extended the bridged LAN. >> >> > > Anoop, I'm reading the RBridge protocol specification version 5 and it seems to me that your comment is inconsistent with the spec. In section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL data frames has the same VID as the inner tag. Is this section going to be changed? > > Futhermore, if we were to use different VIDs on outer VLAN tags then we would need to handle the multi-destination case where one would need to send a multi-destination frame per outer VID to communicate with the RBs in the distribution tree which are using different VIDs. Is this correct? > > Thanks, > Hern > Fulcrum Microsystems > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from smtp.fulcrummicro.com (smtp.fulcrummicro.com [66.59.247.212]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V2rxL0021073 for <rbridge@postel.org>; Tue, 30 Oct 2007 19:53:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.fulcrummicro.com (Postfix) with ESMTP id 596ADDC8003; Tue, 30 Oct 2007 19:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-10 required=4 tests=[ALL_TRUSTED=-1.8, AWL=0.131, BAYES_00=-2.599, SPF_HELO_PASS=-0.001] Received: from smtp.fulcrummicro.com ([127.0.0.1]) by localhost (nepenthes.hq.fulcrummicro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t5-1ly4BmqH; Tue, 30 Oct 2007 19:53:58 -0700 (PDT) Received: from nepenthes.hq.fulcrummicro.com (localhost.localdomain [127.0.0.1]) by smtp.fulcrummicro.com (Postfix) with ESMTP id 8E6AB338629; Tue, 30 Oct 2007 19:53:58 -0700 (PDT) Date: Tue, 30 Oct 2007 19:53:58 -0700 (PDT) From: Zhi-Hern Loh <zloh@fulcrummicro.com> To: Anoop Ghanwani <anoop@brocade.com> Message-ID: <18442502.671741193799238499.JavaMail.root@nepenthes.hq.fulcrummicro.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.0.0.66] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zloh@fulcrummicro.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@Sun.COM>, James Carlson <james.d.carlson@Sun.COM> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 02:54:32 -0000 Status: RO Content-Length: 2013 ----- "Anoop Ghanwani" <anoop@brocade.com> wrote: > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > > Sent: Tuesday, October 30, 2007 2:37 PM > > To: Silvano Gai > > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > > Subject: Re: [rbridge] RBridge: a case of study > > > > Silvano Gai writes: > > > Radia, > > > > > > I have added few slides to the example and I suggest that > > we use it as > > > a possible case of study for TRILL (of course, not the only one). > > > > > > Let's see if the solutions we have discussed work on this > example. > > > > > > The complete case of study is at: > > > > > > http://www.ip6.com/acme-example-v1.ppt > > > > I have a few narrow questions that I think might help me > > understand this picture a bit better. (I probably have more > > questions once I know the narrow answers. ;-}) > > Let me take a shot at answering these. > > > 1. After the proposed fix, should VLAN 3 on Cloud L be bridged > > together with VLAN 3 on Cloud R, even though the backbone > itself > > doesn't directly carry VLAN 3? (I.e., are TRILL packets with > > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > > backbone?) > > Yes, that's pretty much what ends up happening. > We have effectively extended the bridged LAN. > Anoop, I'm reading the RBridge protocol specification version 5 and it seems to me that your comment is inconsistent with the spec. In section, 5.2.2.3, the spec says that the outer VLAN tag of TRILL data frames has the same VID as the inner tag. Is this section going to be changed? Futhermore, if we were to use different VIDs on outer VLAN tags then we would need to handle the multi-destination case where one would need to send a multi-destination frame per outer VID to communicate with the RBs in the distribution tree which are using different VIDs. Is this correct? Thanks, Hern Fulcrum Microsystems Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V1sX7u004081 for <rbridge@postel.org>; Tue, 30 Oct 2007 18:54:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="20765718" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 30 Oct 2007 18:54:34 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id CC2F6238459; Tue, 30 Oct 2007 18:54:33 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 18:54:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2007 18:54:28 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E92036D@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <18215.42006.843620.853514@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: AcgbQSObqjxw8HImSBq/dBXdND2s9AAHksMQ References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> <18215.42006.843620.853514@gargle.gargle.HOWL> From: "Anoop Ghanwani" <anoop@brocade.com> To: "James Carlson" <james.d.carlson@Sun.COM>, "Silvano Gai" <sgai@nuovasystems.com> X-OriginalArrivalTime: 31 Oct 2007 01:54:33.0889 (UTC) FILETIME=[FC027910:01C81B60] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V1sX7u004081 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@Sun.COM Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 01:55:01 -0000 Status: RO Content-Length: 2898 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of James Carlson > Sent: Tuesday, October 30, 2007 2:37 PM > To: Silvano Gai > Cc: Developing a hybrid router/bridge.; Radia.Perlman@Sun.COM > Subject: Re: [rbridge] RBridge: a case of study > > Silvano Gai writes: > > Radia, > > > > I have added few slides to the example and I suggest that > we use it as > > a possible case of study for TRILL (of course, not the only one). > > > > Let's see if the solutions we have discussed work on this example. > > > > The complete case of study is at: > > > > http://www.ip6.com/acme-example-v1.ppt > > I have a few narrow questions that I think might help me > understand this picture a bit better. (I probably have more > questions once I know the narrow answers. ;-}) Let me take a shot at answering these. > 1. After the proposed fix, should VLAN 3 on Cloud L be bridged > together with VLAN 3 on Cloud R, even though the backbone itself > doesn't directly carry VLAN 3? (I.e., are TRILL packets with > outer VLAN ID 7 or 8 and with inner VLAN 3 present on the > backbone?) Yes, that's pretty much what ends up happening. We have effectively extended the bridged LAN. > 2. What happened to the routing that once went on? It was > previously possible to route between these VLANs, but in the new > diagram, it's not. Is routing between these networks > unimportant, or does it take place elsewhere, or must RBridges > both bridge and route in this scenario? Routing can continue to happen wherever it was happening. The Rbridge by itself doesn't do routing, but there's no reason why one cannot build a device that does bridging, RBridging, and routing. > 3. Suppose we were to configure VLAN 7 within Cloud L. Would you > expect H1 to be able to access nodes within the backbone Cloud G > at that point? (I'm trying to figure out whether the "X" and > "Y" interfaces are of fundamentally different types or if the > RBridges are just bridges. I suspect they're different.) This is where I think would help to introduce some additional terminology in the spec. Just like MPLS LSRs have ingress, core, and egress functionality, I think we should have similar functions for RBridging. We could have access ports, trill ports and hybrid ports. From access ports, we only accept non-trill encap'ed frames, from trill ports, we accept only trill-encap'ed frames, and finally, from hybrid ports we accept either. Today we only allow hybrid ports and perhaps that's OK as a spec. Anyway, back to the specifics of your question: If you did configure VLAN 7 within cloud L, then the RBridges labeled "Router 1" and "Router 2" would have 2 of their ports configured to be on VLAN 7 and would simply bridge between those ports. Anoop Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V1fLMq000600 for <rbridge@postel.org>; Tue, 30 Oct 2007 18:41:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="20765340" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 30 Oct 2007 18:41:22 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 75813238459; Tue, 30 Oct 2007 18:41:21 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 18:41:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2007 18:41:15 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E920368@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <4727CADC.8000902@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLANtags onRBridge-RBridgepackets? Thread-Index: AcgbVO4fQhkPBX+9TiW3zTiSUJMq3AAB11zQ References: <283f04e35585.47263880@sunlabs.com><34BDD2A93E5FD84594BB230DD6C18EA202590551@nuova-ex1.hq.nuovaimpresa.com> <4727CADC.8000902@sun.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Silvano Gai" <sgai@nuovasystems.com> X-OriginalArrivalTime: 31 Oct 2007 01:41:21.0155 (UTC) FILETIME=[2380DD30:01C81B5F] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9V1fLMq000600 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLANtags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 01:41:51 -0000 Status: RO Content-Length: 3665 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, October 30, 2007 5:23 PM > To: Silvano Gai > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLANtags > onRBridge-RBridgepackets? > > Silvano Gai wrote: > > > > "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have > > explained why. > > > > "single VLAN per layer 2 cloud" may be workable, but I need > to see the > > details of the algorithm to see if there are corner cases. > > > > If we can agree to concentrate our focus on a "single VLAN > per layer 2 > > cloud" we have made some progress. > > > > -- Silvano > > I can live with "single VLAN, configurable, default=1". I'd > recommend that regardless of the VLAN you are configured to > send a Hello on, you accept Hellos on any VLAN you are > capable of receiving traffic on, and that each DRB tells all > the other RBridges on that cloud what VLAN to send on, so > that they all wind up sending RBridge traffic on the same VLAN. > > I think the only complexity/overhead it adds over "VLAN 1, > nonconfigurable is" > > a) something configurable to document and present in the > management interface (the VLAN on which to send Hellos) > b) until a DRB is elected, there might be lots of RBridges > transmitting on different VLANs because each might be > configured with a different VLAN The problem with this is that there may be RB's sending hellos on a VLAN that other RB's don't see. As a result the adjacency creation may not be correct. For example, RB1 may send its hellos on VLAN 4, RB2 may send its hellos on VLAN 5, neither RBridge is able to see the other's hellos because of the way the bridged LAN is configured. I think the correct way to solve this is to say that hellos will be sent on exactly one VLAN for any bridged LAN - VLAN 1 would be default, but configuration is allowed. So in the LSP, along with things like root bridge for the pseudonode, we advertise the "Rbridge control VLAN" that is used. If a conflict is detected when an LSP is received (same root, different control VLAN), then the RBridge with higher ID stop being a DRB and reports a misconfiguration. A misconfiguration could also be detected by configuring all RBridges on the LAN to be in a maintenance association using 802.1ag. (But that would be very configuration intensive. 802.1ag would cause a trap to be generated if all Rbridges don't see all the Rbridges they expect to see, or if they see extra ones that they haven't been configured about.) > c) if there are multiple (say k) DRBs (because for load > splitting each of them is DRB for a different > (nonoverlapping) set of VLANs), then there will be k times as > many Hellos being sent > d) I think there might be a slightly higher probability that > there will be misconfiguration such as telling each RBridge a > different set of VLANs to talk on, but the safeguards that I > specified in previous emails (listen to BPDUs, report root > bridge in pseudonode LSP, don't decapsulate from an ingress > RBridge that you haven't seen all the LSPs from, wait until > you've synchrornized LSP databases with your neighbors when > you first start up) will prevent loops in these cases, and at > worst orphan parts of the layer 2 cloud from the rest of the campus. > > So...can everyone live with this? (Silvano -- as you said > above, you promised to think about whether there were any > corner cases to worry about. You also said you wanted to see > "the whole algorithm specified". I'll do that in a separate email. Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9V0LbNm004371 for <rbridge@postel.org>; Tue, 30 Oct 2007 17:21:37 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQR0099K2BNTT00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 30 Oct 2007 17:21:23 -0700 (PDT) Received: from [129.150.22.40] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQR006B42BMZGI0@mail.sunlabs.com> for rbridge@postel.org; Tue, 30 Oct 2007 17:21:23 -0700 (PDT) Date: Tue, 30 Oct 2007 17:22:52 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <34BDD2A93E5FD84594BB230DD6C18EA202590551@nuova-ex1.hq.nuovaimpresa.com> To: Silvano Gai <sgai@nuovasystems.com> Message-id: <4727CADC.8000902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590551@nuova-ex1.hq.nuovaimpresa.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Oct 2007 00:21:53 -0000 Status: RO Content-Length: 2085 Silvano Gai wrote: > > "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have > explained why. > > "single VLAN per layer 2 cloud" may be workable, but I need to see the > details of the algorithm to see if there are corner cases. > > If we can agree to concentrate our focus on a "single VLAN per layer 2 > cloud" we have made some progress. > > -- Silvano > > I can live with "single VLAN, configurable, default=1". I'd recommend that regardless of the VLAN you are configured to send a Hello on, you accept Hellos on any VLAN you are capable of receiving traffic on, and that each DRB tells all the other RBridges on that cloud what VLAN to send on, so that they all wind up sending RBridge traffic on the same VLAN. I think the only complexity/overhead it adds over "VLAN 1, nonconfigurable is" a) something configurable to document and present in the management interface (the VLAN on which to send Hellos) b) until a DRB is elected, there might be lots of RBridges transmitting on different VLANs because each might be configured with a different VLAN c) if there are multiple (say k) DRBs (because for load splitting each of them is DRB for a different (nonoverlapping) set of VLANs), then there will be k times as many Hellos being sent d) I think there might be a slightly higher probability that there will be misconfiguration such as telling each RBridge a different set of VLANs to talk on, but the safeguards that I specified in previous emails (listen to BPDUs, report root bridge in pseudonode LSP, don't decapsulate from an ingress RBridge that you haven't seen all the LSPs from, wait until you've synchrornized LSP databases with your neighbors when you first start up) will prevent loops in these cases, and at worst orphan parts of the layer 2 cloud from the rest of the campus. So...can everyone live with this? (Silvano -- as you said above, you promised to think about whether there were any corner cases to worry about. You also said you wanted to see "the whole algorithm specified". I'll do that in a separate email. Radia Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9UMSXec023472 for <rbridge@postel.org>; Tue, 30 Oct 2007 15:28:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="20759329" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 30 Oct 2007 15:28:28 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 83DC723843A; Tue, 30 Oct 2007 15:28:28 -0700 (PDT) Received: from HQ-EXCH-4.corp.brocade.com ([10.3.8.82]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 15:28:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2007 15:28:27 -0700 Message-ID: <43B6589BD8C21C43AE2FE551397D4E878FD824@HQ-EXCH-4.corp.brocade.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge: a case of study Thread-Index: AcganwcSkIHaTwrbRRmmGg4yRIB1sgASFJSwABcMKSA= References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> From: "Jian Liu" <jliu@Brocade.COM> To: "Silvano Gai" <sgai@nuovasystems.com>, <Radia.Perlman@sun.com> X-OriginalArrivalTime: 30 Oct 2007 22:28:28.0195 (UTC) FILETIME=[317B4F30:01C81B44] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jliu@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9UMSXec023472 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 30 Oct 2007 22:28:53 -0000 Status: RO Content-Length: 968 Silvano, A couple of questions: 1. In the proposed solution, what is considered in the TRILL domain? It seems TRILL domain includes RBridge 1-4 and backbone cloud G, correct? 2. Are there regular bridges or RBridges in backbone cloud G? Regards, Jian -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai Sent: Tuesday, October 30, 2007 4:26 AM To: Radia.Perlman@sun.com Cc: Developing a hybrid router/bridge. Subject: [rbridge] RBridge: a case of study Radia, I have added few slides to the example and I suggest that we use it as a possible case of study for TRILL (of course, not the only one). Let's see if the solutions we have discussed work on this example. The complete case of study is at: http://www.ip6.com/acme-example-v1.ppt -- Silvano _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9ULr0hR010184 for <rbridge@postel.org>; Tue, 30 Oct 2007 14:53:01 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9ULr08G021626 for <rbridge@postel.org>; Tue, 30 Oct 2007 21:53:00 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9ULqxAx024947 for <rbridge@postel.org>; Tue, 30 Oct 2007 17:52:59 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9ULbRaV005129; Tue, 30 Oct 2007 17:37:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9ULbRtb005126; Tue, 30 Oct 2007 17:37:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18215.42006.843620.853514@gargle.gargle.HOWL> Date: Tue, 30 Oct 2007 17:37:26 -0400 From: James Carlson <james.d.carlson@Sun.COM> To: Silvano Gai <sgai@nuovasystems.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> References: <283f04e35585.47263880@sunlabs.com> <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@Sun.COM Subject: Re: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 30 Oct 2007 21:54:19 -0000 Status: RO Content-Length: 1656 Silvano Gai writes: > Radia, > > I have added few slides to the example and I suggest that we use it as a > possible case of study for TRILL (of course, not the only one). > > Let's see if the solutions we have discussed work on this example. > > The complete case of study is at: > > http://www.ip6.com/acme-example-v1.ppt I have a few narrow questions that I think might help me understand this picture a bit better. (I probably have more questions once I know the narrow answers. ;-}) 1. After the proposed fix, should VLAN 3 on Cloud L be bridged together with VLAN 3 on Cloud R, even though the backbone itself doesn't directly carry VLAN 3? (I.e., are TRILL packets with outer VLAN ID 7 or 8 and with inner VLAN 3 present on the backbone?) 2. What happened to the routing that once went on? It was previously possible to route between these VLANs, but in the new diagram, it's not. Is routing between these networks unimportant, or does it take place elsewhere, or must RBridges both bridge and route in this scenario? 3. Suppose we were to configure VLAN 7 within Cloud L. Would you expect H1 to be able to access nodes within the backbone Cloud G at that point? (I'm trying to figure out whether the "X" and "Y" interfaces are of fundamentally different types or if the RBridges are just bridges. I suspect they're different.) -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9UBQccx010296 for <rbridge@postel.org>; Tue, 30 Oct 2007 04:26:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2007 04:26:22 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202590558@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <283f04e35585.47263880@sunlabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RBridge: a case of study thread-index: AcganwcSkIHaTwrbRRmmGg4yRIB1sgASFJSw References: <283f04e35585.47263880@sunlabs.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9UBQccx010296 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: [rbridge] RBridge: a case of study X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 30 Oct 2007 11:26:52 -0000 Status: RO Content-Length: 302 Radia, I have added few slides to the example and I suggest that we use it as a possible case of study for TRILL (of course, not the only one). Let's see if the solutions we have discussed work on this example. The complete case of study is at: http://www.ip6.com/acme-example-v1.ppt -- Silvano Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9UAYkAl020374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Tue, 30 Oct 2007 03:34:47 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9UAYkDR025980; Tue, 30 Oct 2007 04:34:46 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 05:34:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2007 05:34:45 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DA99C8@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <272abe4465e8.4725dca1@sunlabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? Thread-Index: AcgaaSrch9pSmOdXRnKbTnafsMg88gAdvy1w References: <272abe4465e8.4725dca1@sunlabs.com> From: "Eric Gray" <eric.gray@ericsson.com> To: <Radia.Perlman@sun.com> X-OriginalArrivalTime: 30 Oct 2007 10:34:45.0811 (UTC) FILETIME=[7D5A1030:01C81AE0] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9UAYkAl020374 Cc: Rbridge@postel.org Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 30 Oct 2007 10:35:10 -0000 Status: RO Content-Length: 9003 Radia, Unfortunately, some people (myself, for instance) will be in Paris this week for the MEF meeting. Meeting at a time convenient to the US west coast is difficult for people meeting in Europe. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia.Perlman@sun.com > Sent: Monday, October 29, 2007 4:14 PM > To: Silvano Gai > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN tags > onRBridge-RBridgepackets? > > Silvano, > Based on your message, I think a lot of the controversy here > is simply miscommunication, which is actually great news. > The VLAN number we have been talking about is solely a local > matter on a single layer 2 cloud. It > is only the outer VLAN number used for RBridge-RBridge communication. > > So looking at your picture, note that we have three separate > layer 2 clouds. Let's add "port" numbers, > so that for each of the RBridges, their top port will be > called "x" and their bottom port would > be called "y". > > Let's call the clouds "G" for the top one (because it is > green). And "L" for the lower left, and "R" for the > lower right. > > if we went with the "VLAN 1 unconfigurable" strategy, then > we'd have to > tell that customer to open up VLAN 1 on the G cloud and R > cloud (and I'm sure I'm using the wrong word, > but by "open up", I mean make it so that the RBridges are > capable of sending and receiving traffic > on VLAN 1, and that VLAN 1 is not partitioned in the green > cloud). It wouldn't cause > the VLANs to get merged or anything like that. It just means > that VLAN 1 would not be allowed to > be partitioned on any of those 3 clouds, and that the > RBridges must be able to use VLAN 1 > to communicate with each other. And it means that all the > traffic for RBridge-RBridge communication > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated > data packet forwarding across the cloud between RBridges) > would be sent with an outer VLAN tag of 1. > > If we instead went with > the "single VLAN, but configurable", then all the RBridges > would be configured to use, say, VLAN 7 > for RBridge-RBridge communication on their "port x" which > connects to cloud G. > RB1 and RB2's "port y" would not need to be configured, since > VLAN 1 would already work on the cloud > attached to that port. RB3 and RB4 would need to be > configured to use, say, VLAN 3, on their "y" port (the > one to cloud R). > > Would some number of people like to have a phone call early > this week and resolve it? I'd hope that > the people would include at least you (Silvano), Dinesh, me, > Anoop, but I don't mean to exclude anyone. > > Radia > > > > ----- Original Message ----- > From: Silvano Gai <sgai@nuovasystems.com> > Date: Sunday, October 28, 2007 4:49 am > Subject: RE: [rbridge] Final outcome of outer VLAN tags > onRBridge-RBridgepackets? > > > > > Radia, > > > > Can you explain me if your solution supports the example that I have > > drawn in PowerPoint at: > > http://www.ip6.com/example.ppt > > ? > > > > Thank You > > > > Answering your email: > > > > I have seen customers deploying VLANs in a variety of ways. > > > > Some customers have VLAN 1 end-to-end and they use it for > control and > > data traffic. Some customers use VLAN 1 only for control > traffic. Some > > customers wants all VLANs (including VLAN 1) being local (not > > end-to-end). Some customers prefer to move some control protocol to > > another VLAN. I have seen multiple different approaches. > > > > You ask for rational, "tangible reasons". Each customer has its own > > reasons that don't match the ones of other customers. There are no > > universal tangible reasons, you just need to realize that > IEEE 802.1Q > > allows VLANs to be deployed in many different way. Any > solution that > > poses restrictions is going to be OK for some customers and KO for > > others. > > > > Over the years I have learned to live with the fact that customers > > havedifferent deployment approaches that are perfectly valid > > because allowed > > by IEEE 802.1Q and by the products. > > > > In TRILL we often speak about plug-and-play. If we consider > > plug-and-play, VLAN 1 is the only one enabled by default > and therefore > > it seems a reasonable default solution. > > > > While this is a valid concept in the consumer space, it is > absolutely > > not valid in Enterprise/Datacenter. Enterprise/Datacenter customers > > request that all the new boxes are shipped with all the ports > > disabled,because they realized that the switches will be connected > > in complex > > configurations in which plug-and-play is very dangerous. > > > > I expect the same to be true for RBridges, where customers will > > carefully design, test in a separate environment and bring-up a > > configuration that will match the existing VLAN deployment > they have. > > > > Inline for you specific questions: > > > > > > > -----Original Message----- > > > From: Radia Perlman [Radia.Perlman@sun.com] > > > Sent: Saturday, October 27, 2007 8:59 PM > > > To: Silvano Gai > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > > RBridgepackets? > > > > > > I'm anxious to close on this issue, but > > > Silvano...you always speak in such absolutes: words like > > > "unrealistic" without giving tangible reasons what the > > > problem is. Again, everything is engineering tradeoffs, and we > > have to > > > understand what the specific > > > pros and cons are (not phrases like > > > "won't work" "unrealistic" "not flexible enough", but > instead "won't > > allow > > > this *particular* scenario") > > > > > > Question: Is the problem picking specifically VLAN 1 as > > > our chosen single VLAN number? If we picked a different > > (unconfigurable) > > > VLAN number would that be OK? > > > > I think that VLAN 1 is probably our best default choice. I don't > > objectto have VLAN 1 to be the default VLAN. > > > > If so, what number? If you are arguing that > > > it's OK to require one VLAN not to be partitioned, and that all > > > RBridge-RBridge > > > communication be done over that VLAN, then I really don't > > understand. > > I am not sure what you are asking. If you are speaking of > the backbone > > between RBridges, the outer VLAN tag for sure may not be the same > > end-to-end. > > > > A department of a large corporation may want to deploy RBridges in 5 > > different sites. The VLAN they have available from site_1 to site_2 > > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 > > VLAN 4. > > > > If you want all this VLANs to be a single VLAN end-to-end, > there is a > > significant change that needs to happen in the communication > > infrastructure that may be considered difficult or impossible. > > > > If instead you are discussing the access to the RBridge clouds, I > > thinkit is reasonable to require that the RBridges that > perform TRILL > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may > > be the > > default, but I think that the value should be programmable. > > > > > > > If that were the case, why can't we (TRILL) put a stake in the > > ground> and say "RBridges will > > > use VLAN 1", and if the customer wanted to use VLAN 1 for > something > > > else, but was willing > > > to configure RBridges to use, say, VLAN 57, why can't > that customer > > > renumber their own > > > VLANs so that they switch their uses of VLAN 57 and VLAN > 1, and let > > the > > > rest of > > > the world have the simplicity of an unconfigurable choice > of VLAN 1? > > > > I don't think this is acceptable for many customers. You are > > putting a > > stake in the ground that IEEE has never put. > > > > > > > > Are you saying that you don't want to require customers to have > > *any*> VLAN number that > > > isn't partitioned, > > > > I am not sure what you mean with "*any* VLAN number that isn't > > partitioned", are you speaking of inner VLAN or outer VLAN? > > > > In most installation the numbering spaces of the Backbone VLANs and > > Access VLANs are disjoint. I don't think this is an issue since the > > access VLANs appears in the inner VLAN tag, while the backbone VLANs > > appears in the outer VLAN tag. > > > > > > and you want a solution that somehow finds all > > > possible ways of having > > > RBridges talk to each other using every possible VLAN? > > > > Again, when you are saying "RBridges talk to each other" are you > > speaking of the TRILL encapsulated frames or of the DRB election on > > theaccess? > > > > Again see my example at: > > http://www.ip6.com/example.ppt > > > > -- Silvano > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9U9qhvx006361 for <rbridge@postel.org>; Tue, 30 Oct 2007 02:52:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2007 02:52:42 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202590551@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <283f04e35585.47263880@sunlabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? thread-index: AcganwcSkIHaTwrbRRmmGg4yRIB1sgANDhiQ References: <283f04e35585.47263880@sunlabs.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9U9qhvx006361 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 30 Oct 2007 09:53:11 -0000 Status: RO Content-Length: 18140 Radia, inline > -----Original Message----- > From: Radia.Perlman@sun.com [mailto:Radia.Perlman@sun.com] > Sent: Monday, October 29, 2007 7:46 PM > To: Silvano Gai > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > Subject: Re: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > 1) I suggested a phone call sometime this week, but it was buried in the > end of my message. I'd particularly hope that (at least) you (Silvano), > Dinesh, Anoop, me, and Don Eastlake attend, but nobody would be excluded. > Send me email with all > your availability for this week (and time zones) and I'll try to pick a > time. > > 2) As for the updated picture, and talking through how I think > it all would work -- I think all the three clouds are completely > independent. So I think > we could just as well be talking about a single layer 2 cloud with a bunch > of RBridges > attached. But I'll use your picture. A single cloud or three separate clouds are not the same thing. Let's assume that cloud L is located in Manhattan (main data center), cloud R is located in New Jersey (backup data center) and Cloud G is some form of public/private fiber connectivity with Ethernet switches connected at the ends. Cloud G is run by central IT. Let's also assume that the finance department has been assigned two VLANs (7 and 8) on the Green Cloud and can use only that two VLANs. Originally the finance department was using routers (instead of RBridges in http://www.ip6.com/example.ppt), but now it is thinking to replace them with RBridges. With routers finance needs at least two separate IP subnets on VLAN 3, one on Cloud L, one on Cloud R. Replacing the routers with RBridges, finance can use the same IP subnet for VLAN 3 in Cloud L and Cloud R. > > ********************* > > First: let's talk through what happens with the "use VLAN 1, no > configuration" strategy: > > The rule is that on every layer 2 cloud (R, G, and L in your picture), > bridges inside each cloud must allow VLAN-1-tagged traffic to pass. This is impossible in our scenario. Finance has only VLAN 7 and 8 on the Green Cloud. Finance is not the only department that wants to deploy RBridges, also Marketing and Sales want to do the same. The requests of Finance, Marketing, and Sales to own VLAN 1 on the Green Cloud conflict. There is a strong corporate policy that the departments cannot share VLANs (and believe me, on Wall Street these rules are enforced). On Cloud R also we have an issue; Finance does not own VLAN 1. Therefore allowing VLAN 1 traffic to pass on Cloud G and R is impossible from a deployment perspective. That > would mean that > VLAN 1 would not partitioned on that cloud. Also every RBridge port must > be configured to allow > sending and receiving of VLAN 1 tagged traffic. > > The way I read your picture (http://www.ip6.com/example.ppt): As > configured, RB3, for > instance, is only able to send/receive frames tagged > with VLANs 2 and 3 on its port Y3, and send/receive VLANs 7 and 8 on its > port X3. > (Is that a correct interpretation of your picture?) YES > So, assuming my interpretation is correct, if you started with an > installation configured that > way, then ports X3, Y3, X4, Y4, X1, and X2 would have to be reconfigured > to allow use of VLAN 1, and any > bridges in between these ports (e.g., inside cloud G or cloud R), if they > were configured to partition VLAN 1, > would have to be configured to allow traffic marked with VLAN 1 to be > forwarded. In this example, this is impossible, as I explained you above. > > Consequences of not doing the reconfiguration as just stated are: > If an RBridge R *cannot* send/receive on VLAN 1 on a port, R will not send > any Hellos (which might be fine -- perhaps > there are no other RBridges on the link -- just endnodes, but my > preference would > be to discourage and possibly > disallow having an RBridge port with VLAN 1 turned off). If VLAN 1 is > partitioned on > the cloud, the same consequence happens. R will not > form any RBridge-RBridge adjacencies on that port, so no encapsulated > traffic will be forwarded across that cloud. With > the safeguards specified in my earlier emails, R will be conservative > about encapsulating/decapsulating data traffic > to/from that link, so that there won't be loops. > > If VLAN 1 is not partitioned and all RBridges can send/receive VLAN 1, > then everything works very smoothly. Other than > having had to reconfigure things, I don't see what functionality the > customer is giving up by allowing RBridges > to talk on VLAN 1. You are assuming that a customer "owns" the whole network. This is often not the case. Departments own pieces of the network. This often is a complex and painful process that results from merger and acquisition and from complex security policy inside the corporation. > > ************************ > Now let's talk about the "single VLAN, but we can configure which VLAN it > is" strategy: > > The customer *could* reconfigure things to allow VLAN 1 for RBridge- > RBridge communication, and then > everything would work as above. But if for some reason they wanted to only > allow VLANs 7 and 8 in cloud G, > and 2 and 3 in cloud R, then they could do the following: > > Ports Y1 and Y2 will not require any configuration -- they already support > VLAN 1 (the default). > OK > Ports X1, X2, X3, and X4 would be configured to send Hellos on either VLAN > 7 or 8. OK I'd recommend, if the VLAN > for Hellos is configurable, that you *accept* Hellos on any of the VLANs > for which you can receive traffic. This is a detail we can work later. Whoever > gets elected DRB (say RB1) specifies, in its Hello, "use VLAN 8", and then > X2, X3, and X4, as long as they continue > to receive Hellos from RB1, send their Hellos on VLAN 8. Furthermore, LSPs > on cloud G are transmitted tagged with > outer VLAN 8. Encapsulated data traffic being forwarded across cloud G > would also have outer VLAN tag of 8. > > If RB2 were DRB instead of RB1, and RB2 was configured to transmit on VLAN > 7, then it would tell all the RBridges to tag > their RBridge-RBridge traffic with 7. If there are different priorities, > say RB1 is DRB for VLAN 7, and wants to > tag RBridge-RBridge traffic with 7, and RB2 is DRB for VLAN 8, and wants > to tag RBridge-RBridge traffic with "8", then you wind up with two DRBs > (one for VLAN 7, and one for VLAN 8). If RB1 tells everyone "use VLAN 7" > and RB2 > tells everyone "use VLAN 8", then you'll get twice as many Hellos on the > link as you'd need. > So perhaps as an optimization, the RBridges could notice this and if you > are DRB for some > of the VLANs on a cloud, and some other DRB (for a different set of VLANs > on the same cloud) is > telling the RBridges to send Hellos on a different, lower numbered VLAN, > then I think it would > be reasonable to agree to using that VLAN. > > Something that's perhaps a bit subtle, but does indeed work, is to realize > what happens if you have > multiple DRBs as a consequence of load splitting the VLANs. What happens > is: > > a) you'll have multiple DRBs, and each DRB will create a different > pseudonode for that cloud > > b) the pseudonodes will have the same root bridge in the LSP, but with a > different, nonoverlapping > set of VLANs > > c) a multicast packet will not get sent twice on the cloud, because the > multicast data packet > will be (inner) tagged with some VLAN tag, and will only get delivered to > the pseudonode that > includes that VLAN tag. > > Anyway, I'm optimistic at this point that we will converge on either "VLAN > 1--nonconfigurable" > or "single VLAN per layer 2 cloud, but which VLAN is configurable", but > that if there really > is a problem with this, I think a phone call would be the best thing at > this point. > "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have explained why. "single VLAN per layer 2 cloud" may be workable, but I need to see the details of the algorithm to see if there are corner cases. If we can agree to concentrate our focus on a "single VLAN per layer 2 cloud" we have made some progress. -- Silvano > Thanks, > > Radia > > ----- Original Message ----- > From: Silvano Gai <sgai@nuovasystems.com> > Date: Monday, October 29, 2007 3:41 pm > Subject: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > > Radia, > > > > I have redrawn > > http://www.ip6.com/example.ppt > > > > Using more terminology according to your suggestion. > > > > Can you rewrite this email using the terminology of the updated > > > http://www.ip6.com/example.ppt > > > > Thank You > > > > -- Silvano > > > > > -----Original Message----- > > > From: Radia.Perlman@sun.com [Radia.Perlman@sun.com] > > > Sent: Monday, October 29, 2007 1:14 PM > > > To: Silvano Gai > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > > Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags > > onRBridge- > > > RBridgepackets? > > > > > > Silvano, > > > Based on your message, I think a lot of the controversy here is > > simply> miscommunication, which is actually great news. > > > The VLAN number we have been talking about is solely a local > > matter on > > a > > > single layer 2 cloud. It > > > is only the outer VLAN number used for RBridge-RBridge > > communication.> > > > So looking at your picture, note that we have three separate > > layer 2 > > > clouds. Let's add "port" numbers, > > > so that for each of the RBridges, their top port will be called "x" > > and > > > their bottom port would > > > be called "y". > > > > > > Let's call the clouds "G" for the top one (because it is green). And > > "L" > > > for the lower left, and "R" for the > > > lower right. > > > > > > if we went with the "VLAN 1 unconfigurable" strategy, then we'd have > > to > > > tell that customer to open up VLAN 1 on the G cloud and R cloud (and > > I'm > > > sure I'm using the wrong word, > > > but by "open up", I mean make it so that the RBridges are capable of > > > sending and receiving traffic > > > on VLAN 1, and that VLAN 1 is not partitioned in the green > > cloud). It > > > wouldn't cause > > > the VLANs to get merged or anything like that. It just means that > > VLAN1 > > > would not be allowed to > > > be partitioned on any of those 3 clouds, and that the RBridges > > must be > > > able to use VLAN 1 > > > to communicate with each other. And it means that all the traffic > > for> RBridge-RBridge communication > > > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated > > > data packet forwarding across the cloud between RBridges) > > > would be sent with an outer VLAN tag of 1. > > > > > > If we instead went with > > > the "single VLAN, but configurable", then all the RBridges would be > > > configured to use, say, VLAN 7 > > > for RBridge-RBridge communication on their "port x" which > > connects to > > > cloud G. > > > RB1 and RB2's "port y" would not need to be configured, since > > VLAN 1 > > would > > > already work on the cloud > > > attached to that port. RB3 and RB4 would need to be configured to > > use,> say, VLAN 3, on their "y" port (the > > > one to cloud R). > > > > > > Would some number of people like to have a phone call early this > > weekand > > > resolve it? I'd hope that > > > the people would include at least you (Silvano), Dinesh, me, Anoop, > > but I > > > don't mean to exclude anyone. > > > > > > Radia > > > > > > > > > > > > ----- Original Message ----- > > > From: Silvano Gai <sgai@nuovasystems.com> > > > Date: Sunday, October 28, 2007 4:49 am > > > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > > > RBridgepackets? > > > > > > > > > > > Radia, > > > > > > > > Can you explain me if your solution supports the example that I > > have> > drawn in PowerPoint at: > > > > http://www.ip6.com/example.ppt > > > > ? > > > > > > > > Thank You > > > > > > > > Answering your email: > > > > > > > > I have seen customers deploying VLANs in a variety of ways. > > > > > > > > Some customers have VLAN 1 end-to-end and they use it for control > > and > > > > data traffic. Some customers use VLAN 1 only for control traffic. > > Some > > > > customers wants all VLANs (including VLAN 1) being local (not > > > > end-to-end). Some customers prefer to move some control > > protocol to > > > > another VLAN. I have seen multiple different approaches. > > > > > > > > You ask for rational, "tangible reasons". Each customer has its > > own> > reasons that don't match the ones of other customers. There > > are no > > > > universal tangible reasons, you just need to realize that IEEE > > 802.1Q > > > > allows VLANs to be deployed in many different way. Any solution > > that > > > > poses restrictions is going to be OK for some customers and KO for > > > > others. > > > > > > > > Over the years I have learned to live with the fact that customers > > > > havedifferent deployment approaches that are perfectly valid > > > > because allowed > > > > by IEEE 802.1Q and by the products. > > > > > > > > In TRILL we often speak about plug-and-play. If we consider > > > > plug-and-play, VLAN 1 is the only one enabled by default and > > therefore > > > > it seems a reasonable default solution. > > > > > > > > While this is a valid concept in the consumer space, it is > > absolutely > > > > not valid in Enterprise/Datacenter. Enterprise/Datacenter > > customers> > request that all the new boxes are shipped with all > > the ports > > > > disabled,because they realized that the switches will be connected > > > > in complex > > > > configurations in which plug-and-play is very dangerous. > > > > > > > > I expect the same to be true for RBridges, where customers will > > > > carefully design, test in a separate environment and bring-up a > > > > configuration that will match the existing VLAN deployment they > > have. > > > > > > > > Inline for you specific questions: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Radia Perlman [Radia.Perlman@sun.com] > > > > > Sent: Saturday, October 27, 2007 8:59 PM > > > > > To: Silvano Gai > > > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags > > onRBridge- > > > > > RBridgepackets? > > > > > > > > > > I'm anxious to close on this issue, but > > > > > Silvano...you always speak in such absolutes: words like > > > > > "unrealistic" without giving tangible reasons what the > > > > > problem is. Again, everything is engineering tradeoffs, and we > > > > have to > > > > > understand what the specific > > > > > pros and cons are (not phrases like > > > > > "won't work" "unrealistic" "not flexible enough", but instead > > "won't > > > > allow > > > > > this *particular* scenario") > > > > > > > > > > Question: Is the problem picking specifically VLAN 1 as > > > > > our chosen single VLAN number? If we picked a different > > > > (unconfigurable) > > > > > VLAN number would that be OK? > > > > > > > > I think that VLAN 1 is probably our best default choice. I don't > > > > objectto have VLAN 1 to be the default VLAN. > > > > > > > > If so, what number? If you are arguing that > > > > > it's OK to require one VLAN not to be partitioned, and that all > > > > > RBridge-RBridge > > > > > communication be done over that VLAN, then I really don't > > > > understand. > > > > I am not sure what you are asking. If you are speaking of the > > backbone > > > > between RBridges, the outer VLAN tag for sure may not be the same > > > > end-to-end. > > > > > > > > A department of a large corporation may want to deploy RBridges > > in 5 > > > > different sites. The VLAN they have available from site_1 to > > site_2> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 > > to site_4 > > > > VLAN 4. > > > > > > > > If you want all this VLANs to be a single VLAN end-to-end, > > there is > > a > > > > significant change that needs to happen in the communication > > > > infrastructure that may be considered difficult or impossible. > > > > > > > > If instead you are discussing the access to the RBridge clouds, I > > > > thinkit is reasonable to require that the RBridges that perform > > TRILL > > > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may > > > > be the > > > > default, but I think that the value should be programmable. > > > > > > > > > > > > > If that were the case, why can't we (TRILL) put a stake in the > > > > ground> and say "RBridges will > > > > > use VLAN 1", and if the customer wanted to use VLAN 1 for > > something > > > > > else, but was willing > > > > > to configure RBridges to use, say, VLAN 57, why can't that > > customer > > > > > renumber their own > > > > > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and > > let > > > > the > > > > > rest of > > > > > the world have the simplicity of an unconfigurable choice of > > VLAN1? > > > > > > > > I don't think this is acceptable for many customers. You are > > > > putting a > > > > stake in the ground that IEEE has never put. > > > > > > > > > > > > > > Are you saying that you don't want to require customers to have > > > > *any*> VLAN number that > > > > > isn't partitioned, > > > > > > > > I am not sure what you mean with "*any* VLAN number that isn't > > > > partitioned", are you speaking of inner VLAN or outer VLAN? > > > > > > > > In most installation the numbering spaces of the Backbone VLANs > > and> > Access VLANs are disjoint. I don't think this is an issue > > since the > > > > access VLANs appears in the inner VLAN tag, while the backbone > > VLANs> > appears in the outer VLAN tag. > > > > > > > > > > > > and you want a solution that somehow finds all > > > > > possible ways of having > > > > > RBridges talk to each other using every possible VLAN? > > > > > > > > Again, when you are saying "RBridges talk to each other" are you > > > > speaking of the TRILL encapsulated frames or of the DRB > > election on > > > > theaccess? > > > > > > > > Again see my example at: > > > > http://www.ip6.com/example.ppt > > > > > > > > -- Silvano > > > > > > > Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9U2kDZW019082 for <rbridge@postel.org>; Mon, 29 Oct 2007 19:46:13 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQP007B0ECXJ900@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 29 Oct 2007 19:46: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 <0JQP007RLECWVV30@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 29 Oct 2007 19:46:09 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [67.161.89.58]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 29 Oct 2007 19:46:08 -0700 Date: Mon, 29 Oct 2007 19:46:08 -0700 From: Radia.Perlman@sun.com To: Silvano Gai <sgai@nuovasystems.com> Message-id: <283f04e35585.47263880@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 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 30 Oct 2007 02:46:37 -0000 Status: RO Content-Length: 14895 1) I suggested a phone call sometime this week, but it was buried in the end of my message. I'd particularly hope that (at least) you (Silvano), Dinesh, Anoop, me, and Don Eastlake attend, but nobody would be excluded. Send me email with all your availability for this week (and time zones) and I'll try to pick a time. 2) As for the updated picture, and talking through how I think it all would work -- I think all the three clouds are completely independent. So I think we could just as well be talking about a single layer 2 cloud with a bunch of RBridges attached. But I'll use your picture. ********************* First: let's talk through what happens with the "use VLAN 1, no configuration" strategy: The rule is that on every layer 2 cloud (R, G, and L in your picture), bridges inside each cloud must allow VLAN-1-tagged traffic to pass. That would mean that VLAN 1 would not partitioned on that cloud. Also every RBridge port must be configured to allow sending and receiving of VLAN 1 tagged traffic. The way I read your picture (http://www.ip6.com/example.ppt): As configured, RB3, for instance, is only able to send/receive frames tagged with VLANs 2 and 3 on its port Y3, and send/receive VLANs 7 and 8 on its port X3. (Is that a correct interpretation of your picture?) So, assuming my interpretation is correct, if you started with an installation configured that way, then ports X3, Y3, X4, Y4, X1, and X2 would have to be reconfigured to allow use of VLAN 1, and any bridges in between these ports (e.g., inside cloud G or cloud R), if they were configured to partition VLAN 1, would have to be configured to allow traffic marked with VLAN 1 to be forwarded. Consequences of not doing the reconfiguration as just stated are: If an RBridge R *cannot* send/receive on VLAN 1 on a port, R will not send any Hellos (which might be fine -- perhaps there are no other RBridges on the link -- just endnodes, but my preference would be to discourage and possibly disallow having an RBridge port with VLAN 1 turned off). If VLAN 1 is partitioned on the cloud, the same consequence happens. R will not form any RBridge-RBridge adjacencies on that port, so no encapsulated traffic will be forwarded across that cloud. With the safeguards specified in my earlier emails, R will be conservative about encapsulating/decapsulating data traffic to/from that link, so that there won't be loops. If VLAN 1 is not partitioned and all RBridges can send/receive VLAN 1, then everything works very smoothly. Other than having had to reconfigure things, I don't see what functionality the customer is giving up by allowing RBridges to talk on VLAN 1. ************************ Now let's talk about the "single VLAN, but we can configure which VLAN it is" strategy: The customer *could* reconfigure things to allow VLAN 1 for RBridge-RBridge communication, and then everything would work as above. But if for some reason they wanted to only allow VLANs 7 and 8 in cloud G, and 2 and 3 in cloud R, then they could do the following: Ports Y1 and Y2 will not require any configuration -- they already support VLAN 1 (the default). Ports X1, X2, X3, and X4 would be configured to send Hellos on either VLAN 7 or 8. I'd recommend, if the VLAN for Hellos is configurable, that you *accept* Hellos on any of the VLANs for which you can receive traffic. Whoever gets elected DRB (say RB1) specifies, in its Hello, "use VLAN 8", and then X2, X3, and X4, as long as they continue to receive Hellos from RB1, send their Hellos on VLAN 8. Furthermore, LSPs on cloud G are transmitted tagged with outer VLAN 8. Encapsulated data traffic being forwarded across cloud G would also have outer VLAN tag of 8. If RB2 were DRB instead of RB1, and RB2 was configured to transmit on VLAN 7, then it would tell all the RBridges to tag their RBridge-RBridge traffic with 7. If there are different priorities, say RB1 is DRB for VLAN 7, and wants to tag RBridge-RBridge traffic with 7, and RB2 is DRB for VLAN 8, and wants to tag RBridge-RBridge traffic with "8", then you wind up with two DRBs (one for VLAN 7, and one for VLAN 8). If RB1 tells everyone "use VLAN 7" and RB2 tells everyone "use VLAN 8", then you'll get twice as many Hellos on the link as you'd need. So perhaps as an optimization, the RBridges could notice this and if you are DRB for some of the VLANs on a cloud, and some other DRB (for a different set of VLANs on the same cloud) is telling the RBridges to send Hellos on a different, lower numbered VLAN, then I think it would be reasonable to agree to using that VLAN. Something that's perhaps a bit subtle, but does indeed work, is to realize what happens if you have multiple DRBs as a consequence of load splitting the VLANs. What happens is: a) you'll have multiple DRBs, and each DRB will create a different pseudonode for that cloud b) the pseudonodes will have the same root bridge in the LSP, but with a different, nonoverlapping set of VLANs c) a multicast packet will not get sent twice on the cloud, because the multicast data packet will be (inner) tagged with some VLAN tag, and will only get delivered to the pseudonode that includes that VLAN tag. Anyway, I'm optimistic at this point that we will converge on either "VLAN 1--nonconfigurable" or "single VLAN per layer 2 cloud, but which VLAN is configurable", but that if there really is a problem with this, I think a phone call would be the best thing at this point. Thanks, Radia ----- Original Message ----- From: Silvano Gai <sgai@nuovasystems.com> Date: Monday, October 29, 2007 3:41 pm Subject: RE: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? > Radia, > > I have redrawn > http://www.ip6.com/example.ppt > > Using more terminology according to your suggestion. > > Can you rewrite this email using the terminology of the updated > > http://www.ip6.com/example.ppt > > Thank You > > -- Silvano > > > -----Original Message----- > > From: Radia.Perlman@sun.com [Radia.Perlman@sun.com] > > Sent: Monday, October 29, 2007 1:14 PM > > To: Silvano Gai > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags > onRBridge- > > RBridgepackets? > > > > Silvano, > > Based on your message, I think a lot of the controversy here is > simply> miscommunication, which is actually great news. > > The VLAN number we have been talking about is solely a local > matter on > a > > single layer 2 cloud. It > > is only the outer VLAN number used for RBridge-RBridge > communication.> > > So looking at your picture, note that we have three separate > layer 2 > > clouds. Let's add "port" numbers, > > so that for each of the RBridges, their top port will be called "x" > and > > their bottom port would > > be called "y". > > > > Let's call the clouds "G" for the top one (because it is green). And > "L" > > for the lower left, and "R" for the > > lower right. > > > > if we went with the "VLAN 1 unconfigurable" strategy, then we'd have > to > > tell that customer to open up VLAN 1 on the G cloud and R cloud (and > I'm > > sure I'm using the wrong word, > > but by "open up", I mean make it so that the RBridges are capable of > > sending and receiving traffic > > on VLAN 1, and that VLAN 1 is not partitioned in the green > cloud). It > > wouldn't cause > > the VLANs to get merged or anything like that. It just means that > VLAN1 > > would not be allowed to > > be partitioned on any of those 3 clouds, and that the RBridges > must be > > able to use VLAN 1 > > to communicate with each other. And it means that all the traffic > for> RBridge-RBridge communication > > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated > > data packet forwarding across the cloud between RBridges) > > would be sent with an outer VLAN tag of 1. > > > > If we instead went with > > the "single VLAN, but configurable", then all the RBridges would be > > configured to use, say, VLAN 7 > > for RBridge-RBridge communication on their "port x" which > connects to > > cloud G. > > RB1 and RB2's "port y" would not need to be configured, since > VLAN 1 > would > > already work on the cloud > > attached to that port. RB3 and RB4 would need to be configured to > use,> say, VLAN 3, on their "y" port (the > > one to cloud R). > > > > Would some number of people like to have a phone call early this > weekand > > resolve it? I'd hope that > > the people would include at least you (Silvano), Dinesh, me, Anoop, > but I > > don't mean to exclude anyone. > > > > Radia > > > > > > > > ----- Original Message ----- > > From: Silvano Gai <sgai@nuovasystems.com> > > Date: Sunday, October 28, 2007 4:49 am > > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > > RBridgepackets? > > > > > > > > Radia, > > > > > > Can you explain me if your solution supports the example that I > have> > drawn in PowerPoint at: > > > http://www.ip6.com/example.ppt > > > ? > > > > > > Thank You > > > > > > Answering your email: > > > > > > I have seen customers deploying VLANs in a variety of ways. > > > > > > Some customers have VLAN 1 end-to-end and they use it for control > and > > > data traffic. Some customers use VLAN 1 only for control traffic. > Some > > > customers wants all VLANs (including VLAN 1) being local (not > > > end-to-end). Some customers prefer to move some control > protocol to > > > another VLAN. I have seen multiple different approaches. > > > > > > You ask for rational, "tangible reasons". Each customer has its > own> > reasons that don't match the ones of other customers. There > are no > > > universal tangible reasons, you just need to realize that IEEE > 802.1Q > > > allows VLANs to be deployed in many different way. Any solution > that > > > poses restrictions is going to be OK for some customers and KO for > > > others. > > > > > > Over the years I have learned to live with the fact that customers > > > havedifferent deployment approaches that are perfectly valid > > > because allowed > > > by IEEE 802.1Q and by the products. > > > > > > In TRILL we often speak about plug-and-play. If we consider > > > plug-and-play, VLAN 1 is the only one enabled by default and > therefore > > > it seems a reasonable default solution. > > > > > > While this is a valid concept in the consumer space, it is > absolutely > > > not valid in Enterprise/Datacenter. Enterprise/Datacenter > customers> > request that all the new boxes are shipped with all > the ports > > > disabled,because they realized that the switches will be connected > > > in complex > > > configurations in which plug-and-play is very dangerous. > > > > > > I expect the same to be true for RBridges, where customers will > > > carefully design, test in a separate environment and bring-up a > > > configuration that will match the existing VLAN deployment they > have. > > > > > > Inline for you specific questions: > > > > > > > > > > -----Original Message----- > > > > From: Radia Perlman [Radia.Perlman@sun.com] > > > > Sent: Saturday, October 27, 2007 8:59 PM > > > > To: Silvano Gai > > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags > onRBridge- > > > > RBridgepackets? > > > > > > > > I'm anxious to close on this issue, but > > > > Silvano...you always speak in such absolutes: words like > > > > "unrealistic" without giving tangible reasons what the > > > > problem is. Again, everything is engineering tradeoffs, and we > > > have to > > > > understand what the specific > > > > pros and cons are (not phrases like > > > > "won't work" "unrealistic" "not flexible enough", but instead > "won't > > > allow > > > > this *particular* scenario") > > > > > > > > Question: Is the problem picking specifically VLAN 1 as > > > > our chosen single VLAN number? If we picked a different > > > (unconfigurable) > > > > VLAN number would that be OK? > > > > > > I think that VLAN 1 is probably our best default choice. I don't > > > objectto have VLAN 1 to be the default VLAN. > > > > > > If so, what number? If you are arguing that > > > > it's OK to require one VLAN not to be partitioned, and that all > > > > RBridge-RBridge > > > > communication be done over that VLAN, then I really don't > > > understand. > > > I am not sure what you are asking. If you are speaking of the > backbone > > > between RBridges, the outer VLAN tag for sure may not be the same > > > end-to-end. > > > > > > A department of a large corporation may want to deploy RBridges > in 5 > > > different sites. The VLAN they have available from site_1 to > site_2> > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 > to site_4 > > > VLAN 4. > > > > > > If you want all this VLANs to be a single VLAN end-to-end, > there is > a > > > significant change that needs to happen in the communication > > > infrastructure that may be considered difficult or impossible. > > > > > > If instead you are discussing the access to the RBridge clouds, I > > > thinkit is reasonable to require that the RBridges that perform > TRILL > > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may > > > be the > > > default, but I think that the value should be programmable. > > > > > > > > > > If that were the case, why can't we (TRILL) put a stake in the > > > ground> and say "RBridges will > > > > use VLAN 1", and if the customer wanted to use VLAN 1 for > something > > > > else, but was willing > > > > to configure RBridges to use, say, VLAN 57, why can't that > customer > > > > renumber their own > > > > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and > let > > > the > > > > rest of > > > > the world have the simplicity of an unconfigurable choice of > VLAN1? > > > > > > I don't think this is acceptable for many customers. You are > > > putting a > > > stake in the ground that IEEE has never put. > > > > > > > > > > > Are you saying that you don't want to require customers to have > > > *any*> VLAN number that > > > > isn't partitioned, > > > > > > I am not sure what you mean with "*any* VLAN number that isn't > > > partitioned", are you speaking of inner VLAN or outer VLAN? > > > > > > In most installation the numbering spaces of the Backbone VLANs > and> > Access VLANs are disjoint. I don't think this is an issue > since the > > > access VLANs appears in the inner VLAN tag, while the backbone > VLANs> > appears in the outer VLAN tag. > > > > > > > > > and you want a solution that somehow finds all > > > > possible ways of having > > > > RBridges talk to each other using every possible VLAN? > > > > > > Again, when you are saying "RBridges talk to each other" are you > > > speaking of the TRILL encapsulated frames or of the DRB > election on > > > theaccess? > > > > > > Again see my example at: > > > http://www.ip6.com/example.ppt > > > > > > -- Silvano > > > > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9TMfRcA004218 for <rbridge@postel.org>; Mon, 29 Oct 2007 15:41:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Oct 2007 15:41:12 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202590366@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <272abe4465e8.4725dca1@sunlabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? thread-index: AcgaaEbh9LTlFop0Tpup+k4ljqP0uAAFFdVQ References: <272abe4465e8.4725dca1@sunlabs.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9TMfRcA004218 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 29 Oct 2007 22:41:48 -0000 Status: RO Content-Length: 8690 Radia, I have redrawn http://www.ip6.com/example.ppt Using more terminology according to your suggestion. Can you rewrite this email using the terminology of the updated > http://www.ip6.com/example.ppt Thank You -- Silvano > -----Original Message----- > From: Radia.Perlman@sun.com [mailto:Radia.Perlman@sun.com] > Sent: Monday, October 29, 2007 1:14 PM > To: Silvano Gai > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > Subject: Re: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > Silvano, > Based on your message, I think a lot of the controversy here is simply > miscommunication, which is actually great news. > The VLAN number we have been talking about is solely a local matter on a > single layer 2 cloud. It > is only the outer VLAN number used for RBridge-RBridge communication. > > So looking at your picture, note that we have three separate layer 2 > clouds. Let's add "port" numbers, > so that for each of the RBridges, their top port will be called "x" and > their bottom port would > be called "y". > > Let's call the clouds "G" for the top one (because it is green). And "L" > for the lower left, and "R" for the > lower right. > > if we went with the "VLAN 1 unconfigurable" strategy, then we'd have to > tell that customer to open up VLAN 1 on the G cloud and R cloud (and I'm > sure I'm using the wrong word, > but by "open up", I mean make it so that the RBridges are capable of > sending and receiving traffic > on VLAN 1, and that VLAN 1 is not partitioned in the green cloud). It > wouldn't cause > the VLANs to get merged or anything like that. It just means that VLAN 1 > would not be allowed to > be partitioned on any of those 3 clouds, and that the RBridges must be > able to use VLAN 1 > to communicate with each other. And it means that all the traffic for > RBridge-RBridge communication > (which consists of IS-IS Hellos, LSP forwarding, and encapsulated > data packet forwarding across the cloud between RBridges) > would be sent with an outer VLAN tag of 1. > > If we instead went with > the "single VLAN, but configurable", then all the RBridges would be > configured to use, say, VLAN 7 > for RBridge-RBridge communication on their "port x" which connects to > cloud G. > RB1 and RB2's "port y" would not need to be configured, since VLAN 1 would > already work on the cloud > attached to that port. RB3 and RB4 would need to be configured to use, > say, VLAN 3, on their "y" port (the > one to cloud R). > > Would some number of people like to have a phone call early this week and > resolve it? I'd hope that > the people would include at least you (Silvano), Dinesh, me, Anoop, but I > don't mean to exclude anyone. > > Radia > > > > ----- Original Message ----- > From: Silvano Gai <sgai@nuovasystems.com> > Date: Sunday, October 28, 2007 4:49 am > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > > > > Radia, > > > > Can you explain me if your solution supports the example that I have > > drawn in PowerPoint at: > > http://www.ip6.com/example.ppt > > ? > > > > Thank You > > > > Answering your email: > > > > I have seen customers deploying VLANs in a variety of ways. > > > > Some customers have VLAN 1 end-to-end and they use it for control and > > data traffic. Some customers use VLAN 1 only for control traffic. Some > > customers wants all VLANs (including VLAN 1) being local (not > > end-to-end). Some customers prefer to move some control protocol to > > another VLAN. I have seen multiple different approaches. > > > > You ask for rational, "tangible reasons". Each customer has its own > > reasons that don't match the ones of other customers. There are no > > universal tangible reasons, you just need to realize that IEEE 802.1Q > > allows VLANs to be deployed in many different way. Any solution that > > poses restrictions is going to be OK for some customers and KO for > > others. > > > > Over the years I have learned to live with the fact that customers > > havedifferent deployment approaches that are perfectly valid > > because allowed > > by IEEE 802.1Q and by the products. > > > > In TRILL we often speak about plug-and-play. If we consider > > plug-and-play, VLAN 1 is the only one enabled by default and therefore > > it seems a reasonable default solution. > > > > While this is a valid concept in the consumer space, it is absolutely > > not valid in Enterprise/Datacenter. Enterprise/Datacenter customers > > request that all the new boxes are shipped with all the ports > > disabled,because they realized that the switches will be connected > > in complex > > configurations in which plug-and-play is very dangerous. > > > > I expect the same to be true for RBridges, where customers will > > carefully design, test in a separate environment and bring-up a > > configuration that will match the existing VLAN deployment they have. > > > > Inline for you specific questions: > > > > > > > -----Original Message----- > > > From: Radia Perlman [Radia.Perlman@sun.com] > > > Sent: Saturday, October 27, 2007 8:59 PM > > > To: Silvano Gai > > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > > RBridgepackets? > > > > > > I'm anxious to close on this issue, but > > > Silvano...you always speak in such absolutes: words like > > > "unrealistic" without giving tangible reasons what the > > > problem is. Again, everything is engineering tradeoffs, and we > > have to > > > understand what the specific > > > pros and cons are (not phrases like > > > "won't work" "unrealistic" "not flexible enough", but instead "won't > > allow > > > this *particular* scenario") > > > > > > Question: Is the problem picking specifically VLAN 1 as > > > our chosen single VLAN number? If we picked a different > > (unconfigurable) > > > VLAN number would that be OK? > > > > I think that VLAN 1 is probably our best default choice. I don't > > objectto have VLAN 1 to be the default VLAN. > > > > If so, what number? If you are arguing that > > > it's OK to require one VLAN not to be partitioned, and that all > > > RBridge-RBridge > > > communication be done over that VLAN, then I really don't > > understand. > > I am not sure what you are asking. If you are speaking of the backbone > > between RBridges, the outer VLAN tag for sure may not be the same > > end-to-end. > > > > A department of a large corporation may want to deploy RBridges in 5 > > different sites. The VLAN they have available from site_1 to site_2 > > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 > > VLAN 4. > > > > If you want all this VLANs to be a single VLAN end-to-end, there is a > > significant change that needs to happen in the communication > > infrastructure that may be considered difficult or impossible. > > > > If instead you are discussing the access to the RBridge clouds, I > > thinkit is reasonable to require that the RBridges that perform TRILL > > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may > > be the > > default, but I think that the value should be programmable. > > > > > > > If that were the case, why can't we (TRILL) put a stake in the > > ground> and say "RBridges will > > > use VLAN 1", and if the customer wanted to use VLAN 1 for something > > > else, but was willing > > > to configure RBridges to use, say, VLAN 57, why can't that customer > > > renumber their own > > > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let > > the > > > rest of > > > the world have the simplicity of an unconfigurable choice of VLAN 1? > > > > I don't think this is acceptable for many customers. You are > > putting a > > stake in the ground that IEEE has never put. > > > > > > > > Are you saying that you don't want to require customers to have > > *any*> VLAN number that > > > isn't partitioned, > > > > I am not sure what you mean with "*any* VLAN number that isn't > > partitioned", are you speaking of inner VLAN or outer VLAN? > > > > In most installation the numbering spaces of the Backbone VLANs and > > Access VLANs are disjoint. I don't think this is an issue since the > > access VLANs appears in the inner VLAN tag, while the backbone VLANs > > appears in the outer VLAN tag. > > > > > > and you want a solution that somehow finds all > > > possible ways of having > > > RBridges talk to each other using every possible VLAN? > > > > Again, when you are saying "RBridges talk to each other" are you > > speaking of the TRILL encapsulated frames or of the DRB election on > > theaccess? > > > > Again see my example at: > > http://www.ip6.com/example.ppt > > > > -- Silvano > Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9TKEGuh013600 for <rbridge@postel.org>; Mon, 29 Oct 2007 13:14:16 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQO0071FW7MJ900@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 29 Oct 2007 13:14:10 -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 <0JQO007RGW7LVV10@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 29 Oct 2007 13:14:09 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [67.161.89.58]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 29 Oct 2007 13:14:09 -0700 Date: Mon, 29 Oct 2007 13:14:09 -0700 From: Radia.Perlman@sun.com To: Silvano Gai <sgai@nuovasystems.com> Message-id: <272abe4465e8.4725dca1@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 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 29 Oct 2007 20:14:44 -0000 Status: RO Content-Length: 7802 Silvano, Based on your message, I think a lot of the controversy here is simply miscommunication, which is actually great news. The VLAN number we have been talking about is solely a local matter on a single layer 2 cloud. It is only the outer VLAN number used for RBridge-RBridge communication. So looking at your picture, note that we have three separate layer 2 clouds. Let's add "port" numbers, so that for each of the RBridges, their top port will be called "x" and their bottom port would be called "y". Let's call the clouds "G" for the top one (because it is green). And "L" for the lower left, and "R" for the lower right. if we went with the "VLAN 1 unconfigurable" strategy, then we'd have to tell that customer to open up VLAN 1 on the G cloud and R cloud (and I'm sure I'm using the wrong word, but by "open up", I mean make it so that the RBridges are capable of sending and receiving traffic on VLAN 1, and that VLAN 1 is not partitioned in the green cloud). It wouldn't cause the VLANs to get merged or anything like that. It just means that VLAN 1 would not be allowed to be partitioned on any of those 3 clouds, and that the RBridges must be able to use VLAN 1 to communicate with each other. And it means that all the traffic for RBridge-RBridge communication (which consists of IS-IS Hellos, LSP forwarding, and encapsulated data packet forwarding across the cloud between RBridges) would be sent with an outer VLAN tag of 1. If we instead went with the "single VLAN, but configurable", then all the RBridges would be configured to use, say, VLAN 7 for RBridge-RBridge communication on their "port x" which connects to cloud G. RB1 and RB2's "port y" would not need to be configured, since VLAN 1 would already work on the cloud attached to that port. RB3 and RB4 would need to be configured to use, say, VLAN 3, on their "y" port (the one to cloud R). Would some number of people like to have a phone call early this week and resolve it? I'd hope that the people would include at least you (Silvano), Dinesh, me, Anoop, but I don't mean to exclude anyone. Radia ----- Original Message ----- From: Silvano Gai <sgai@nuovasystems.com> Date: Sunday, October 28, 2007 4:49 am Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? > > Radia, > > Can you explain me if your solution supports the example that I have > drawn in PowerPoint at: > http://www.ip6.com/example.ppt > ? > > Thank You > > Answering your email: > > I have seen customers deploying VLANs in a variety of ways. > > Some customers have VLAN 1 end-to-end and they use it for control and > data traffic. Some customers use VLAN 1 only for control traffic. Some > customers wants all VLANs (including VLAN 1) being local (not > end-to-end). Some customers prefer to move some control protocol to > another VLAN. I have seen multiple different approaches. > > You ask for rational, "tangible reasons". Each customer has its own > reasons that don't match the ones of other customers. There are no > universal tangible reasons, you just need to realize that IEEE 802.1Q > allows VLANs to be deployed in many different way. Any solution that > poses restrictions is going to be OK for some customers and KO for > others. > > Over the years I have learned to live with the fact that customers > havedifferent deployment approaches that are perfectly valid > because allowed > by IEEE 802.1Q and by the products. > > In TRILL we often speak about plug-and-play. If we consider > plug-and-play, VLAN 1 is the only one enabled by default and therefore > it seems a reasonable default solution. > > While this is a valid concept in the consumer space, it is absolutely > not valid in Enterprise/Datacenter. Enterprise/Datacenter customers > request that all the new boxes are shipped with all the ports > disabled,because they realized that the switches will be connected > in complex > configurations in which plug-and-play is very dangerous. > > I expect the same to be true for RBridges, where customers will > carefully design, test in a separate environment and bring-up a > configuration that will match the existing VLAN deployment they have. > > Inline for you specific questions: > > > > -----Original Message----- > > From: Radia Perlman [Radia.Perlman@sun.com] > > Sent: Saturday, October 27, 2007 8:59 PM > > To: Silvano Gai > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > RBridgepackets? > > > > I'm anxious to close on this issue, but > > Silvano...you always speak in such absolutes: words like > > "unrealistic" without giving tangible reasons what the > > problem is. Again, everything is engineering tradeoffs, and we > have to > > understand what the specific > > pros and cons are (not phrases like > > "won't work" "unrealistic" "not flexible enough", but instead "won't > allow > > this *particular* scenario") > > > > Question: Is the problem picking specifically VLAN 1 as > > our chosen single VLAN number? If we picked a different > (unconfigurable) > > VLAN number would that be OK? > > I think that VLAN 1 is probably our best default choice. I don't > objectto have VLAN 1 to be the default VLAN. > > If so, what number? If you are arguing that > > it's OK to require one VLAN not to be partitioned, and that all > > RBridge-RBridge > > communication be done over that VLAN, then I really don't > understand. > I am not sure what you are asking. If you are speaking of the backbone > between RBridges, the outer VLAN tag for sure may not be the same > end-to-end. > > A department of a large corporation may want to deploy RBridges in 5 > different sites. The VLAN they have available from site_1 to site_2 > maybe VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 > VLAN 4. > > If you want all this VLANs to be a single VLAN end-to-end, there is a > significant change that needs to happen in the communication > infrastructure that may be considered difficult or impossible. > > If instead you are discussing the access to the RBridge clouds, I > thinkit is reasonable to require that the RBridges that perform TRILL > encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may > be the > default, but I think that the value should be programmable. > > > > If that were the case, why can't we (TRILL) put a stake in the > ground> and say "RBridges will > > use VLAN 1", and if the customer wanted to use VLAN 1 for something > > else, but was willing > > to configure RBridges to use, say, VLAN 57, why can't that customer > > renumber their own > > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let > the > > rest of > > the world have the simplicity of an unconfigurable choice of VLAN 1? > > I don't think this is acceptable for many customers. You are > putting a > stake in the ground that IEEE has never put. > > > > > Are you saying that you don't want to require customers to have > *any*> VLAN number that > > isn't partitioned, > > I am not sure what you mean with "*any* VLAN number that isn't > partitioned", are you speaking of inner VLAN or outer VLAN? > > In most installation the numbering spaces of the Backbone VLANs and > Access VLANs are disjoint. I don't think this is an issue since the > access VLANs appears in the inner VLAN tag, while the backbone VLANs > appears in the outer VLAN tag. > > > and you want a solution that somehow finds all > > possible ways of having > > RBridges talk to each other using every possible VLAN? > > Again, when you are saying "RBridges talk to each other" are you > speaking of the TRILL encapsulated frames or of the DRB election on > theaccess? > > Again see my example at: > http://www.ip6.com/example.ppt > > -- Silvano Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9SKtPjk019614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sun, 28 Oct 2007 13:55:26 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l9SL4KAA025930; Sun, 28 Oct 2007 15:04:20 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 15:55:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2007 15:55:21 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DA8D5A@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032E6FED@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXkZ/uPF1Fs5u3TtKQJjskB4t2IAB9aVMgAAVvQ7AAAVep8A== References: <4720E6A3.7010603@sun.com><3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> <47217A84.1040303@sun.com> <941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D9790032E6FED@de01exm64.ds.mot.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-OriginalArrivalTime: 28 Oct 2007 20:55:23.0565 (UTC) FILETIME=[DBF4E5D0:01C819A4] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SKtPjk019614 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 20:56:38 -0000 Status: RO Content-Length: 11058 Donald, The issue with excessively large hello messages because of multiple per-VLAN priorities doesn't come up if you don't have hello messages with information about more than one VLAN. So, IMO, it looks like you are wrong in saying there's "currently no provision for fragmenting Hellos." It seems as if it is simply more like some people are talking about it one way and others are talking about it another. It looks as if - by trying to address a possible scale issue that might very well be unrealistic - we have invented a problem and are now dreaming up all kinds of neat and cool ways to solve it. Let's just un-invent it... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake@motorola.com] > Sent: Sunday, October 28, 2007 4:02 PM > To: Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] A "multiple VLAN Hello" proposal > Importance: High > > Eric, > > There is currently no provision for fragmenting Hellos. If different > Rbridges are gong to have different priorities for becoming DRB for > different VLANs the current IS-IS election style would say that that > information has to go into the Hello PDUs. If bits maps are > better than > ranges, we could use those. > > Donald > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Sunday, October 28, 2007 1:29 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] A "multiple VLAN Hello" proposal > > Radia, > > Using sets of VLANs as a range of values is likely to force > sub-optimality on load-sharing - possibly to the extent that load > sharing becomes useless. > > It is not a trivial exercise to make VLAN topologies line up > conveniently with VLAN ID assignments. In fact, assuming that it > is possible to modify VLAN topologies, it's most likely infeasible > to do so in some scenarios. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Friday, October 26, 2007 1:26 AM > > To: Eastlake III Donald-LDE008 > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > > > Right...I was not intending to preclude having R1 be DRB > for (inner) > > VLANs (v1, v2, v3) and > > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you > > point out, if > > each RBridge can > > be configured with a different priority for each of the 4000 > > VLANs, the > > IS-IS Hello would > > get too large. The only reason for different priorities is > to do some > > load splitting. I'd argue > > that with just a tiny bit of flexibility customers can get enough > > functionality. So I'd suggest > > limiting multiple priorities to some reasonable number, like > > 3, and sets > > of VLANs to ranges. > > That would mean that R1 can claim to have priority P1 for the > > VLANs in > > range (n1-n2), and > > priority P2 for the VLANs in range (n3-n4), and priority P3 > for VLANs > > betwen (n5-n6). > > This would require (for 3 different priorities) 18 bytes in > > the Hello. > > For instance, "I have > > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and > > priority 2 for > > VLANs (101-115). Perhaps another 500 bytes to do a bit mask > > of all the > > VLANs that > > you support at all (or alternatively you can't claim to have > > a priority > > for a range of VLANs unless > > you support all the VLANs in that range). > > > > Likewise, in the pseudonode, we'd have to say the range of > VLANs that > > that pseudonode > > refers to. > > > > And it's NOT a DRB collision if there is a pseudonode, say R1,17, > > for which R1 is DRB, reporting root bridge X > > and R2 is DRB on a link with root bridge X as long as the set > > of VLANs > > reported > > in R1.17's LSP does not overlap with the set of VLANs that R2 > > is DRB for > > on that link. > > > > And actually, R2 really only needs to decline to forward > data (act as > > DRB) for the set of > > VLANs in R1.17's pseudonode that overlaps with R2's. It could > > be that R2 > > has some > > other VLANs that are not in R1.17's pseudonode. > > > > So that's an additional refinement on the rules that should > be added. > > > > Perhaps we should start a different thread on whether > people can live > > with having a single > > DRB be configured with at most 3 priorities on a port, and > > require the > > set of VLANs for > > each priority to be expressible in a range (rather than having to > > enumerate each of the > > VLAN tags individually). > > > > Radia > > > > > > > > Eastlake III Donald-LDE008 wrote: > > > Hi Radia, > > > > > > The proposal below appears to be written from the "one > DRB per link" > > > point of view while the current draft claims to support > "one DRB per > > > VLAN per link". Even if you have complete VLAN 1 > > connectivity and use > > > single Hellos, I'm not quite sure how the one DRB per > VLAN per link > > > would work. In principle, the per VLAN priority for a > > Rbridge port for > > > all its configured VLANs might not fit into a Hello... > > > > > > Thanks, > > > Donald > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On > > > Behalf Of Radia Perlman > > > Sent: Thursday, October 25, 2007 2:56 PM > > > To: Developing a hybrid router/bridge. > > > Subject: [rbridge] A "multiple VLAN Hello" proposal > > > > > > It's a bit difficult to argue on the list about proposals > > when one of > > > them has not been specified, especially > > > since I can imagine lots of variations on multiple VLANs, > > and lots of > > > questions about choices for > > > the details. > > > > > > Here's an attempt to specify a "send Hellos on multiple > > VLANs" proposal. > > > > > > I've chosen details > > > where in many cases there are other options I could have > > chosen. But I > > > think we need some > > > tangible proposal with details worked out before > advocating for it. > > > People should feel free > > > to suggest modifications to the details below, but I, as I > > said, cannot > > > argue between proposals > > > if the proposals aren't concrete. I've tried to make it as > > simple as > > > possible, as low overhead > > > as possible, while adding the ability to configure sending > > Hellos on > > > lots of VLANs. > > > > > > > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > > > > > b) In addition, RBridges MAY be configured to send and > > receive Hellos on > > > > > > some set of > > > VLANs in addition to 1 > > > > > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all > > the VLANs that > > > R1 is > > > configured to send (and receive) on. To clarify, as long as > > R1 thinks > > > itself is DRB, it will > > > send Hellos on the complete set of VLANs that R1 is > > configured to send > > > on. In addition (see > > > point "e"), R1 may wind up having to send Hellos on some > > set of VLANs in > > > > > > addition > > > to those it was configured to send on. > > > > > > d) In IS-IS's Hello, R1 reports the set of neighbor > RBridges R1 has > > > heard Hellos from. In addition, > > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > > that R1 hears > > > > > > hellos from R2 on. > > > The one VLAN that R1 reports is the lowest numbered VLAN > > that R1 hears a > > > > > > Hello from R2 on. > > > > > > e) If R1 does not hear a Hello from R2 on any of R1's > > configured VLANs, > > > but does hear on some other VLAN, say VLAN x, then R1 adds > > "x" to the > > > set of VLANs that > > > R1 transmits on, as long as it continues to hear Hellos on > > VLAN x (and > > > no > > > other VLANs) from R2. Note that if R2's Hello gives R2 > > better priority > > > for > > > being DRB, then R1 will not be DRB any more, but MUST > > continue sending > > > Hellos on > > > VLAN x (even though x is not in the set of VLANs > > > that R1 was configured to send on) to ensure that R2 > > continues to send > > > its Hellos on VLAN x. > > > > > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > > the VLAN > > > that the DRB reports > > > that it has heard from you on. This cuts down on Hellos > > since it means > > > that non-DRB RBridges > > > will send on at most two VLANs. > > > {Note: An alternate option would have had every RBridge > send Hellos > > > always on all VLANs they > > > have been configured to send on}. > > > > > > f) all RBridge-RBridge traffic (other than Hellos) is > > always sent on > > > VLAN 1. So if R2 cannot > > > reach the DRB via VLAN 1, then R2 cannot forward data > to/from that > > > cloud, or receive > > > LSPs on that cloud. In other words, that link will be > > broken for R2. The > > > > > > purpose > > > of the Hellos is only to notice (through a means *in > > addition* to the > > > safeguards in the other > > > proposals) that R2 is not DRB for the link. > > > > > > g) We do the same safeguards as in the other proposals (report the > > > bridge root ID in the pseudonode LSP, don't decapsulate > > from ingress Ra > > > unless > > > you have all the relevant pseudonode LSPs attached to Ra to > > ensure that > > > none of them have > > > the same root RBridge, and that you delay before > > encapsulating data off > > > the link until you've > > > been DRB for enough time to synchronize LSP databases with your > > > neighbors) > > > > > > ************** > > > My thoughts on this: > > > > > > a) I assume the only reason to send Hellos on multiple > VLANs is to > > > minimize the probability > > > of accidentally having two DRBs, and therefore loops. I'm > > not convinced > > > this adds safety > > > over the safeguards in the single VLAN proposals. > > > > > > b) this winds up with sending lots more Hellos, but does > not create > > > additional pseudonodes, > > > or complicate data forwarding, because the Hellos is only to find > > > neighbors, not to repair > > > use of the link for forwarding data (or propagating LSPs) > > if VLAN 1 is > > > partitioned on the link > > > > > > c) This is a lot more complicated. It might seem simpler to > > not try to > > > optimize the number of > > > Hellos (like I did in point e), but there seem to be scary > > corner cases > > > where all the VLANs > > > common to R1 and R2 are partitioned. Saying there must be an > > > unpartitioned VLAN 1 seems > > > the safest. > > > > > > So, I still like the "just use VLAN 1" proposal. > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9SKjcis017208 for <rbridge@postel.org>; Sun, 28 Oct 2007 13:45:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2007 13:45:24 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20258FF2A@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032E6FED@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal thread-index: AcgXkZ/uPF1Fs5u3TtKQJjskB4t2IAB9aVMgAAVvQ7AAAYcbIA== References: <4720E6A3.7010603@sun.com><3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com><47217A84.1040303@sun.com><941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D9790032E6FED@de01exm64.ds.mot.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Eric Gray" <eric.gray@ericsson.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SKjcis017208 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 20:46:13 -0000 Status: RO Content-Length: 10644 Donald, We need to face the reality that the only solution that works is to send a Hello per VLAN. We are in the version one of the protocol, we should use well know solutions and look at optimizations in future versions, when we have implementation experience. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Sunday, October 28, 2007 1:02 PM > To: Eric Gray > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Eric, > > There is currently no provision for fragmenting Hellos. If different > Rbridges are gong to have different priorities for becoming DRB for > different VLANs the current IS-IS election style would say that that > information has to go into the Hello PDUs. If bits maps are better than > ranges, we could use those. > > Donald > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Sunday, October 28, 2007 1:29 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] A "multiple VLAN Hello" proposal > > Radia, > > Using sets of VLANs as a range of values is likely to force > sub-optimality on load-sharing - possibly to the extent that load > sharing becomes useless. > > It is not a trivial exercise to make VLAN topologies line up > conveniently with VLAN ID assignments. In fact, assuming that it > is possible to modify VLAN topologies, it's most likely infeasible > to do so in some scenarios. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Friday, October 26, 2007 1:26 AM > > To: Eastlake III Donald-LDE008 > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > > > Right...I was not intending to preclude having R1 be DRB for (inner) > > VLANs (v1, v2, v3) and > > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you > > point out, if > > each RBridge can > > be configured with a different priority for each of the 4000 > > VLANs, the > > IS-IS Hello would > > get too large. The only reason for different priorities is to do some > > load splitting. I'd argue > > that with just a tiny bit of flexibility customers can get enough > > functionality. So I'd suggest > > limiting multiple priorities to some reasonable number, like > > 3, and sets > > of VLANs to ranges. > > That would mean that R1 can claim to have priority P1 for the > > VLANs in > > range (n1-n2), and > > priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs > > betwen (n5-n6). > > This would require (for 3 different priorities) 18 bytes in > > the Hello. > > For instance, "I have > > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and > > priority 2 for > > VLANs (101-115). Perhaps another 500 bytes to do a bit mask > > of all the > > VLANs that > > you support at all (or alternatively you can't claim to have > > a priority > > for a range of VLANs unless > > you support all the VLANs in that range). > > > > Likewise, in the pseudonode, we'd have to say the range of VLANs that > > that pseudonode > > refers to. > > > > And it's NOT a DRB collision if there is a pseudonode, say R1,17, > > for which R1 is DRB, reporting root bridge X > > and R2 is DRB on a link with root bridge X as long as the set > > of VLANs > > reported > > in R1.17's LSP does not overlap with the set of VLANs that R2 > > is DRB for > > on that link. > > > > And actually, R2 really only needs to decline to forward data (act as > > DRB) for the set of > > VLANs in R1.17's pseudonode that overlaps with R2's. It could > > be that R2 > > has some > > other VLANs that are not in R1.17's pseudonode. > > > > So that's an additional refinement on the rules that should be added. > > > > Perhaps we should start a different thread on whether people can live > > with having a single > > DRB be configured with at most 3 priorities on a port, and > > require the > > set of VLANs for > > each priority to be expressible in a range (rather than having to > > enumerate each of the > > VLAN tags individually). > > > > Radia > > > > > > > > Eastlake III Donald-LDE008 wrote: > > > Hi Radia, > > > > > > The proposal below appears to be written from the "one DRB per link" > > > point of view while the current draft claims to support "one DRB per > > > VLAN per link". Even if you have complete VLAN 1 > > connectivity and use > > > single Hellos, I'm not quite sure how the one DRB per VLAN per link > > > would work. In principle, the per VLAN priority for a > > Rbridge port for > > > all its configured VLANs might not fit into a Hello... > > > > > > Thanks, > > > Donald > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On > > > Behalf Of Radia Perlman > > > Sent: Thursday, October 25, 2007 2:56 PM > > > To: Developing a hybrid router/bridge. > > > Subject: [rbridge] A "multiple VLAN Hello" proposal > > > > > > It's a bit difficult to argue on the list about proposals > > when one of > > > them has not been specified, especially > > > since I can imagine lots of variations on multiple VLANs, > > and lots of > > > questions about choices for > > > the details. > > > > > > Here's an attempt to specify a "send Hellos on multiple > > VLANs" proposal. > > > > > > I've chosen details > > > where in many cases there are other options I could have > > chosen. But I > > > think we need some > > > tangible proposal with details worked out before advocating for it. > > > People should feel free > > > to suggest modifications to the details below, but I, as I > > said, cannot > > > argue between proposals > > > if the proposals aren't concrete. I've tried to make it as > > simple as > > > possible, as low overhead > > > as possible, while adding the ability to configure sending > > Hellos on > > > lots of VLANs. > > > > > > > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > > > > > b) In addition, RBridges MAY be configured to send and > > receive Hellos on > > > > > > some set of > > > VLANs in addition to 1 > > > > > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all > > the VLANs that > > > R1 is > > > configured to send (and receive) on. To clarify, as long as > > R1 thinks > > > itself is DRB, it will > > > send Hellos on the complete set of VLANs that R1 is > > configured to send > > > on. In addition (see > > > point "e"), R1 may wind up having to send Hellos on some > > set of VLANs in > > > > > > addition > > > to those it was configured to send on. > > > > > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has > > > heard Hellos from. In addition, > > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > > that R1 hears > > > > > > hellos from R2 on. > > > The one VLAN that R1 reports is the lowest numbered VLAN > > that R1 hears a > > > > > > Hello from R2 on. > > > > > > e) If R1 does not hear a Hello from R2 on any of R1's > > configured VLANs, > > > but does hear on some other VLAN, say VLAN x, then R1 adds > > "x" to the > > > set of VLANs that > > > R1 transmits on, as long as it continues to hear Hellos on > > VLAN x (and > > > no > > > other VLANs) from R2. Note that if R2's Hello gives R2 > > better priority > > > for > > > being DRB, then R1 will not be DRB any more, but MUST > > continue sending > > > Hellos on > > > VLAN x (even though x is not in the set of VLANs > > > that R1 was configured to send on) to ensure that R2 > > continues to send > > > its Hellos on VLAN x. > > > > > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > > the VLAN > > > that the DRB reports > > > that it has heard from you on. This cuts down on Hellos > > since it means > > > that non-DRB RBridges > > > will send on at most two VLANs. > > > {Note: An alternate option would have had every RBridge send Hellos > > > always on all VLANs they > > > have been configured to send on}. > > > > > > f) all RBridge-RBridge traffic (other than Hellos) is > > always sent on > > > VLAN 1. So if R2 cannot > > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that > > > cloud, or receive > > > LSPs on that cloud. In other words, that link will be > > broken for R2. The > > > > > > purpose > > > of the Hellos is only to notice (through a means *in > > addition* to the > > > safeguards in the other > > > proposals) that R2 is not DRB for the link. > > > > > > g) We do the same safeguards as in the other proposals (report the > > > bridge root ID in the pseudonode LSP, don't decapsulate > > from ingress Ra > > > unless > > > you have all the relevant pseudonode LSPs attached to Ra to > > ensure that > > > none of them have > > > the same root RBridge, and that you delay before > > encapsulating data off > > > the link until you've > > > been DRB for enough time to synchronize LSP databases with your > > > neighbors) > > > > > > ************** > > > My thoughts on this: > > > > > > a) I assume the only reason to send Hellos on multiple VLANs is to > > > minimize the probability > > > of accidentally having two DRBs, and therefore loops. I'm > > not convinced > > > this adds safety > > > over the safeguards in the single VLAN proposals. > > > > > > b) this winds up with sending lots more Hellos, but does not create > > > additional pseudonodes, > > > or complicate data forwarding, because the Hellos is only to find > > > neighbors, not to repair > > > use of the link for forwarding data (or propagating LSPs) > > if VLAN 1 is > > > partitioned on the link > > > > > > c) This is a lot more complicated. It might seem simpler to > > not try to > > > optimize the number of > > > Hellos (like I did in point e), but there seem to be scary > > corner cases > > > where all the VLANs > > > common to R1 and R2 are partitioned. Saying there must be an > > > unpartitioned VLAN 1 seems > > > the safest. > > > > > > So, I still like the "just use VLAN 1" proposal. > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9SKg16b016617 for <rbridge@postel.org>; Sun, 28 Oct 2007 13:42:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2007 13:41:45 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20258FF29@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal thread-index: AcgXkZ/uPF1Fs5u3TtKQJjskB4t2IAB9aVMgAAbePiA= References: <4720E6A3.7010603@sun.com><3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com><47217A84.1040303@sun.com> <941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SKg16b016617 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 20:42:49 -0000 Status: RO Content-Length: 9844 I agree with Eric, VLAN range is not widely deployed today. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eric Gray > Sent: Sunday, October 28, 2007 10:29 AM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Radia, > > Using sets of VLANs as a range of values is likely to force > sub-optimality on load-sharing - possibly to the extent that load > sharing becomes useless. > > It is not a trivial exercise to make VLAN topologies line up > conveniently with VLAN ID assignments. In fact, assuming that it > is possible to modify VLAN topologies, it's most likely infeasible > to do so in some scenarios. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Friday, October 26, 2007 1:26 AM > > To: Eastlake III Donald-LDE008 > > Cc: Developing a hybrid router/bridge. > > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > > > Right...I was not intending to preclude having R1 be DRB for (inner) > > VLANs (v1, v2, v3) and > > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you > > point out, if > > each RBridge can > > be configured with a different priority for each of the 4000 > > VLANs, the > > IS-IS Hello would > > get too large. The only reason for different priorities is to do some > > load splitting. I'd argue > > that with just a tiny bit of flexibility customers can get enough > > functionality. So I'd suggest > > limiting multiple priorities to some reasonable number, like > > 3, and sets > > of VLANs to ranges. > > That would mean that R1 can claim to have priority P1 for the > > VLANs in > > range (n1-n2), and > > priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs > > betwen (n5-n6). > > This would require (for 3 different priorities) 18 bytes in > > the Hello. > > For instance, "I have > > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and > > priority 2 for > > VLANs (101-115). Perhaps another 500 bytes to do a bit mask > > of all the > > VLANs that > > you support at all (or alternatively you can't claim to have > > a priority > > for a range of VLANs unless > > you support all the VLANs in that range). > > > > Likewise, in the pseudonode, we'd have to say the range of VLANs that > > that pseudonode > > refers to. > > > > And it's NOT a DRB collision if there is a pseudonode, say R1,17, > > for which R1 is DRB, reporting root bridge X > > and R2 is DRB on a link with root bridge X as long as the set > > of VLANs > > reported > > in R1.17's LSP does not overlap with the set of VLANs that R2 > > is DRB for > > on that link. > > > > And actually, R2 really only needs to decline to forward data (act as > > DRB) for the set of > > VLANs in R1.17's pseudonode that overlaps with R2's. It could > > be that R2 > > has some > > other VLANs that are not in R1.17's pseudonode. > > > > So that's an additional refinement on the rules that should be added. > > > > Perhaps we should start a different thread on whether people can live > > with having a single > > DRB be configured with at most 3 priorities on a port, and > > require the > > set of VLANs for > > each priority to be expressible in a range (rather than having to > > enumerate each of the > > VLAN tags individually). > > > > Radia > > > > > > > > Eastlake III Donald-LDE008 wrote: > > > Hi Radia, > > > > > > The proposal below appears to be written from the "one DRB per link" > > > point of view while the current draft claims to support "one DRB per > > > VLAN per link". Even if you have complete VLAN 1 > > connectivity and use > > > single Hellos, I'm not quite sure how the one DRB per VLAN per link > > > would work. In principle, the per VLAN priority for a > > Rbridge port for > > > all its configured VLANs might not fit into a Hello... > > > > > > Thanks, > > > Donald > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On > > > Behalf Of Radia Perlman > > > Sent: Thursday, October 25, 2007 2:56 PM > > > To: Developing a hybrid router/bridge. > > > Subject: [rbridge] A "multiple VLAN Hello" proposal > > > > > > It's a bit difficult to argue on the list about proposals > > when one of > > > them has not been specified, especially > > > since I can imagine lots of variations on multiple VLANs, > > and lots of > > > questions about choices for > > > the details. > > > > > > Here's an attempt to specify a "send Hellos on multiple > > VLANs" proposal. > > > > > > I've chosen details > > > where in many cases there are other options I could have > > chosen. But I > > > think we need some > > > tangible proposal with details worked out before advocating for it. > > > People should feel free > > > to suggest modifications to the details below, but I, as I > > said, cannot > > > argue between proposals > > > if the proposals aren't concrete. I've tried to make it as > > simple as > > > possible, as low overhead > > > as possible, while adding the ability to configure sending > > Hellos on > > > lots of VLANs. > > > > > > > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > > > > > b) In addition, RBridges MAY be configured to send and > > receive Hellos on > > > > > > some set of > > > VLANs in addition to 1 > > > > > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all > > the VLANs that > > > R1 is > > > configured to send (and receive) on. To clarify, as long as > > R1 thinks > > > itself is DRB, it will > > > send Hellos on the complete set of VLANs that R1 is > > configured to send > > > on. In addition (see > > > point "e"), R1 may wind up having to send Hellos on some > > set of VLANs in > > > > > > addition > > > to those it was configured to send on. > > > > > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has > > > heard Hellos from. In addition, > > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > > that R1 hears > > > > > > hellos from R2 on. > > > The one VLAN that R1 reports is the lowest numbered VLAN > > that R1 hears a > > > > > > Hello from R2 on. > > > > > > e) If R1 does not hear a Hello from R2 on any of R1's > > configured VLANs, > > > but does hear on some other VLAN, say VLAN x, then R1 adds > > "x" to the > > > set of VLANs that > > > R1 transmits on, as long as it continues to hear Hellos on > > VLAN x (and > > > no > > > other VLANs) from R2. Note that if R2's Hello gives R2 > > better priority > > > for > > > being DRB, then R1 will not be DRB any more, but MUST > > continue sending > > > Hellos on > > > VLAN x (even though x is not in the set of VLANs > > > that R1 was configured to send on) to ensure that R2 > > continues to send > > > its Hellos on VLAN x. > > > > > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > > the VLAN > > > that the DRB reports > > > that it has heard from you on. This cuts down on Hellos > > since it means > > > that non-DRB RBridges > > > will send on at most two VLANs. > > > {Note: An alternate option would have had every RBridge send Hellos > > > always on all VLANs they > > > have been configured to send on}. > > > > > > f) all RBridge-RBridge traffic (other than Hellos) is > > always sent on > > > VLAN 1. So if R2 cannot > > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that > > > cloud, or receive > > > LSPs on that cloud. In other words, that link will be > > broken for R2. The > > > > > > purpose > > > of the Hellos is only to notice (through a means *in > > addition* to the > > > safeguards in the other > > > proposals) that R2 is not DRB for the link. > > > > > > g) We do the same safeguards as in the other proposals (report the > > > bridge root ID in the pseudonode LSP, don't decapsulate > > from ingress Ra > > > unless > > > you have all the relevant pseudonode LSPs attached to Ra to > > ensure that > > > none of them have > > > the same root RBridge, and that you delay before > > encapsulating data off > > > the link until you've > > > been DRB for enough time to synchronize LSP databases with your > > > neighbors) > > > > > > ************** > > > My thoughts on this: > > > > > > a) I assume the only reason to send Hellos on multiple VLANs is to > > > minimize the probability > > > of accidentally having two DRBs, and therefore loops. I'm > > not convinced > > > this adds safety > > > over the safeguards in the single VLAN proposals. > > > > > > b) this winds up with sending lots more Hellos, but does not create > > > additional pseudonodes, > > > or complicate data forwarding, because the Hellos is only to find > > > neighbors, not to repair > > > use of the link for forwarding data (or propagating LSPs) > > if VLAN 1 is > > > partitioned on the link > > > > > > c) This is a lot more complicated. It might seem simpler to > > not try to > > > optimize the number of > > > Hellos (like I did in point e), but there seem to be scary > > corner cases > > > where all the VLANs > > > common to R1 and R2 are partitioned. Saying there must be an > > > unpartitioned VLAN 1 seems > > > the safest. > > > > > > So, I still like the "just use VLAN 1" proposal. > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9SK2BZD006135 for <rbridge@postel.org>; Sun, 28 Oct 2007 13:02:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1193601730!37872887!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29618 invoked from network); 28 Oct 2007 20:02:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 28 Oct 2007 20:02:10 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9SK295d004771 for <rbridge@postel.org>; Sun, 28 Oct 2007 13:02:10 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l9SK299A022775 for <rbridge@postel.org>; Sun, 28 Oct 2007 15:02:09 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l9SK28R0022770 for <rbridge@postel.org>; Sun, 28 Oct 2007 15:02:09 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sun, 28 Oct 2007 16:02:06 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6FED@de01exm64.ds.mot.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXkZ/uPF1Fs5u3TtKQJjskB4t2IAB9aVMgAAVvQ7A= References: <4720E6A3.7010603@sun.com><3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> <47217A84.1040303@sun.com> <941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Eric Gray" <eric.gray@ericsson.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SK2BZD006135 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 20:02:44 -0000 Status: RO Content-Length: 9449 Eric, There is currently no provision for fragmenting Hellos. If different Rbridges are gong to have different priorities for becoming DRB for different VLANs the current IS-IS election style would say that that information has to go into the Hello PDUs. If bits maps are better than ranges, we could use those. Donald -----Original Message----- From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Sunday, October 28, 2007 1:29 PM To: Radia Perlman; Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge. Subject: RE: [rbridge] A "multiple VLAN Hello" proposal Radia, Using sets of VLANs as a range of values is likely to force sub-optimality on load-sharing - possibly to the extent that load sharing becomes useless. It is not a trivial exercise to make VLAN topologies line up conveniently with VLAN ID assignments. In fact, assuming that it is possible to modify VLAN topologies, it's most likely infeasible to do so in some scenarios. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Friday, October 26, 2007 1:26 AM > To: Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Right...I was not intending to preclude having R1 be DRB for (inner) > VLANs (v1, v2, v3) and > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you > point out, if > each RBridge can > be configured with a different priority for each of the 4000 > VLANs, the > IS-IS Hello would > get too large. The only reason for different priorities is to do some > load splitting. I'd argue > that with just a tiny bit of flexibility customers can get enough > functionality. So I'd suggest > limiting multiple priorities to some reasonable number, like > 3, and sets > of VLANs to ranges. > That would mean that R1 can claim to have priority P1 for the > VLANs in > range (n1-n2), and > priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs > betwen (n5-n6). > This would require (for 3 different priorities) 18 bytes in > the Hello. > For instance, "I have > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and > priority 2 for > VLANs (101-115). Perhaps another 500 bytes to do a bit mask > of all the > VLANs that > you support at all (or alternatively you can't claim to have > a priority > for a range of VLANs unless > you support all the VLANs in that range). > > Likewise, in the pseudonode, we'd have to say the range of VLANs that > that pseudonode > refers to. > > And it's NOT a DRB collision if there is a pseudonode, say R1,17, > for which R1 is DRB, reporting root bridge X > and R2 is DRB on a link with root bridge X as long as the set > of VLANs > reported > in R1.17's LSP does not overlap with the set of VLANs that R2 > is DRB for > on that link. > > And actually, R2 really only needs to decline to forward data (act as > DRB) for the set of > VLANs in R1.17's pseudonode that overlaps with R2's. It could > be that R2 > has some > other VLANs that are not in R1.17's pseudonode. > > So that's an additional refinement on the rules that should be added. > > Perhaps we should start a different thread on whether people can live > with having a single > DRB be configured with at most 3 priorities on a port, and > require the > set of VLANs for > each priority to be expressible in a range (rather than having to > enumerate each of the > VLAN tags individually). > > Radia > > > > Eastlake III Donald-LDE008 wrote: > > Hi Radia, > > > > The proposal below appears to be written from the "one DRB per link" > > point of view while the current draft claims to support "one DRB per > > VLAN per link". Even if you have complete VLAN 1 > connectivity and use > > single Hellos, I'm not quite sure how the one DRB per VLAN per link > > would work. In principle, the per VLAN priority for a > Rbridge port for > > all its configured VLANs might not fit into a Hello... > > > > Thanks, > > Donald > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On > > Behalf Of Radia Perlman > > Sent: Thursday, October 25, 2007 2:56 PM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] A "multiple VLAN Hello" proposal > > > > It's a bit difficult to argue on the list about proposals > when one of > > them has not been specified, especially > > since I can imagine lots of variations on multiple VLANs, > and lots of > > questions about choices for > > the details. > > > > Here's an attempt to specify a "send Hellos on multiple > VLANs" proposal. > > > > I've chosen details > > where in many cases there are other options I could have > chosen. But I > > think we need some > > tangible proposal with details worked out before advocating for it. > > People should feel free > > to suggest modifications to the details below, but I, as I > said, cannot > > argue between proposals > > if the proposals aren't concrete. I've tried to make it as > simple as > > possible, as low overhead > > as possible, while adding the ability to configure sending > Hellos on > > lots of VLANs. > > > > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > > > b) In addition, RBridges MAY be configured to send and > receive Hellos on > > > > some set of > > VLANs in addition to 1 > > > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all > the VLANs that > > R1 is > > configured to send (and receive) on. To clarify, as long as > R1 thinks > > itself is DRB, it will > > send Hellos on the complete set of VLANs that R1 is > configured to send > > on. In addition (see > > point "e"), R1 may wind up having to send Hellos on some > set of VLANs in > > > > addition > > to those it was configured to send on. > > > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has > > heard Hellos from. In addition, > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > that R1 hears > > > > hellos from R2 on. > > The one VLAN that R1 reports is the lowest numbered VLAN > that R1 hears a > > > > Hello from R2 on. > > > > e) If R1 does not hear a Hello from R2 on any of R1's > configured VLANs, > > but does hear on some other VLAN, say VLAN x, then R1 adds > "x" to the > > set of VLANs that > > R1 transmits on, as long as it continues to hear Hellos on > VLAN x (and > > no > > other VLANs) from R2. Note that if R2's Hello gives R2 > better priority > > for > > being DRB, then R1 will not be DRB any more, but MUST > continue sending > > Hellos on > > VLAN x (even though x is not in the set of VLANs > > that R1 was configured to send on) to ensure that R2 > continues to send > > its Hellos on VLAN x. > > > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > the VLAN > > that the DRB reports > > that it has heard from you on. This cuts down on Hellos > since it means > > that non-DRB RBridges > > will send on at most two VLANs. > > {Note: An alternate option would have had every RBridge send Hellos > > always on all VLANs they > > have been configured to send on}. > > > > f) all RBridge-RBridge traffic (other than Hellos) is > always sent on > > VLAN 1. So if R2 cannot > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that > > cloud, or receive > > LSPs on that cloud. In other words, that link will be > broken for R2. The > > > > purpose > > of the Hellos is only to notice (through a means *in > addition* to the > > safeguards in the other > > proposals) that R2 is not DRB for the link. > > > > g) We do the same safeguards as in the other proposals (report the > > bridge root ID in the pseudonode LSP, don't decapsulate > from ingress Ra > > unless > > you have all the relevant pseudonode LSPs attached to Ra to > ensure that > > none of them have > > the same root RBridge, and that you delay before > encapsulating data off > > the link until you've > > been DRB for enough time to synchronize LSP databases with your > > neighbors) > > > > ************** > > My thoughts on this: > > > > a) I assume the only reason to send Hellos on multiple VLANs is to > > minimize the probability > > of accidentally having two DRBs, and therefore loops. I'm > not convinced > > this adds safety > > over the safeguards in the single VLAN proposals. > > > > b) this winds up with sending lots more Hellos, but does not create > > additional pseudonodes, > > or complicate data forwarding, because the Hellos is only to find > > neighbors, not to repair > > use of the link for forwarding data (or propagating LSPs) > if VLAN 1 is > > partitioned on the link > > > > c) This is a lot more complicated. It might seem simpler to > not try to > > optimize the number of > > Hellos (like I did in point e), but there seem to be scary > corner cases > > where all the VLANs > > common to R1 and R2 are partitioned. Saying there must be an > > unpartitioned VLAN 1 seems > > the safest. > > > > So, I still like the "just use VLAN 1" proposal. > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9SJsgm7003586 for <Rbridge@postel.org>; Sun, 28 Oct 2007 12:54:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1193601281!6895725!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12872 invoked from network); 28 Oct 2007 19:54:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 28 Oct 2007 19:54:41 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9SJsfvW003956 for <Rbridge@postel.org>; Sun, 28 Oct 2007 12:54:41 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l9SJseaL011019 for <Rbridge@postel.org>; Sun, 28 Oct 2007 14:54:40 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9SJseHf011014 for <Rbridge@postel.org>; Sun, 28 Oct 2007 14:54:40 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sun, 28 Oct 2007 15:54:37 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6FEC@de01exm64.ds.mot.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202404568@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Announcing Root Thread-Index: AcgJXgj/P6j0arLXQFebq3JJMK3pSQAXQmtgANJkOOAAAmPiUAMi2btA References: <b1cde5dcd6e.470943b6@sunlabs.com><4C94DE2070B172459E4F1EE14BD2364E7B076C@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979003219323@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA202404568@nuova-ex1.hq.nuovaimpresa.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SJsgm7003586 Subject: Re: [rbridge] Consensus Check: Announcing Root X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 19:55:10 -0000 Status: RO Content-Length: 3715 Actually, because an Rbridge may be the DRB from multiple links in the same VLAN on different ports and each of those ports could be connected to a different bridged LAN, you have to report a set of spanning tree root bridge IDs. Since this is a variable amount of information, if there aren't any spanning tree devices around so you haven't received any BPDUs, it seems simplest just to report that the size of the set is zero. Donald > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Friday, October 12, 2007 12:21 PM > To: Anoop Ghanwani > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Announcing Root > > I'm fine with option (b) but it seems implausible that all 0's could > ever be a normal MAC address. Among other things, the 00-00-00 OUI is > reserved for expressing arbitrary EtherTypes in the SNAP SAP format... > > Donald > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Monday, October 08, 2007 10:56 AM > To: Radia.Perlman@sun.com; Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Announcing Root > > I would prefer (a) or (b) since 0 is technically > a valid address. (b) seems best since it's explicit. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia.Perlman@sun.com > > Sent: Sunday, October 07, 2007 8:38 PM > > To: Eastlake III Donald-LDE008 > > Cc: Rbridge@postel.org > > Subject: Re: [rbridge] Consensus Check: Announcing Root > > > > Good point. There might be no bridges. So there has to be a > > way of encoding that. Anything such as: > > a) leaving out the TLV in which one announces the root bridge > > b) using a flag to say "no root" > > c) using a special address, say 0 > > or I'm sure there are lots of possibilities. > > > > Radia > > > > ----- Original Message ----- > > From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> > > Date: Saturday, October 6, 2007 12:46 pm > > Subject: [rbridge] Consensus Check: Announcing Root > > > > > This is a check via the mailing list on a slight modification of an > > > apparent consensus from the minutes of the Chicago meeting for a > > > changefrom protocol draft -05. The tentative consensus at > > the Chicago > > > meeting > > > was: > > > > > > It is mandatory for an RBridge to announce the bridge root that > > > it sees out each physical port. > > > > > > Based on mailing list discussion, I would like to tweak this as > > > follows: > > > An Rbridge MUST parse BPDUs it receives on a port and announce > > > in the core IS-IS instance the bridge root that it sees out > > > each port. For MSTP (Multiple Spanning Tree Protocol), this is > > > the CIST (Common and Internal Spanning Tree) root. > > > > > > I have a question in connection with this. What is > > announced for the > > > port if no BPDU has been received recently or ever? Should > > there be a > > > "root MAC address valid" flag per port or should there some > > > conventionalvalue, like zero, which is announced? > > > > > > Thanks, > > > Donald > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9SHhntm025861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sun, 28 Oct 2007 10:43:50 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9SHhgcL012840; Sun, 28 Oct 2007 11:43:43 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 12:43:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2007 12:43:40 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DA8D3C@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032E6BDF@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXOlfU4OOzyiioQ8GJPRkktrzbhAAFLipgAA2yR8AAgLzDsA== References: <4720E6A3.7010603@sun.com><4C94DE2070B172459E4F1EE14BD2364E91FB0D@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790032E6BDF@de01exm64.ds.mot.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Anoop Ghanwani" <anoop@brocade.com> X-OriginalArrivalTime: 28 Oct 2007 17:43:42.0842 (UTC) FILETIME=[14FDD5A0:01C8198A] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SHhntm025861 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 17:44:18 -0000 Status: RO Content-Length: 7595 Donald, We do not have carte-blanch in saying what is correct and incorrect behavior for RBridges, unless we want to give up on a large number of common concerns - compatibility with existing/deployed technologies, software/hardware re-use and just plain taking advantage of results of past experience, to name a few. In saying that it is alright - at the protocol level (what people actually do is their business) - for a device to treat VLAN traffic promiscuously is assuming both a level of complexity and a degree of risk in achieving long term interoperability between RBridges and other potential VLAN forwarding devices. Also, in establishing a precedent for ignoring what is "common accepted practice" in existing VLAN devices, we may expose ourselves to reciprocal future activities. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, October 26, 2007 12:45 AM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Hi Anoop, > > I don't look at it that way at all. We get to say what "correct" and > "incorrect" behavior are for Rbridges. > > TRILL Ethertype frames are special. The Outer VLAN tag on a TRILL > Ethertype frame is just a transport artifact added to enable the frame > to get through a Bridged LAN that is in the way. It is unnecessary on > point-to-point links. If an Outer VLAN tag is present on a > TRILL frame, > it shouldn't affect whether the frame is processed. > > Donald > > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On > Behalf Of Anoop Ghanwani > Sent: Thursday, October 25, 2007 5:39 PM > To: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Radia, > > Step "e" would be considered incorrect behavior > w.r.t. VLANs. If an end station is not configured > with a certain VLAN, it should not be receiving and > trying to process packets from that VLAN. In this > case, the end station is the management port running > IS-IS. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Thursday, October 25, 2007 11:56 AM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] A "multiple VLAN Hello" proposal > > > > It's a bit difficult to argue on the list about proposals > > when one of them has not been specified, especially since I > > can imagine lots of variations on multiple VLANs, and lots of > > questions about choices for the details. > > > > Here's an attempt to specify a "send Hellos on multiple > > VLANs" proposal. > > I've chosen details > > where in many cases there are other options I could have > > chosen. But I think we need some tangible proposal with > > details worked out before advocating for it. > > People should feel free > > to suggest modifications to the details below, but I, as I > > said, cannot argue between proposals if the proposals aren't > > concrete. I've tried to make it as simple as possible, as low > > overhead as possible, while adding the ability to configure > > sending Hellos on lots of VLANs. > > > > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > > > b) In addition, RBridges MAY be configured to send and > > receive Hellos on some set of VLANs in addition to 1 > > > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the > > VLANs that > > R1 is > > configured to send (and receive) on. To clarify, as long as > > R1 thinks itself is DRB, it will send Hellos on the complete > > set of VLANs that R1 is configured to send on. In addition > > (see point "e"), R1 may wind up having to send Hellos on some > > set of VLANs in addition to those it was configured to send on. > > > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges > > R1 has heard Hellos from. In addition, > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > > that R1 hears hellos from R2 on. > > The one VLAN that R1 reports is the lowest numbered VLAN that > > R1 hears a Hello from R2 on. > > > > e) If R1 does not hear a Hello from R2 on any of R1's > > configured VLANs, but does hear on some other VLAN, say VLAN > > x, then R1 adds "x" to the set of VLANs that > > R1 transmits on, as long as it continues to hear Hellos on > > VLAN x (and no other VLANs) from R2. Note that if R2's Hello > > gives R2 better priority for being DRB, then R1 will not be > > DRB any more, but MUST continue sending Hellos on VLAN x > > (even though x is not in the set of VLANs that R1 was > > configured to send on) to ensure that R2 continues to send > > its Hellos on VLAN x. > > > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > > the VLAN that the DRB reports that it has heard from you on. > > This cuts down on Hellos since it means that non-DRB RBridges > > will send on at most two VLANs. > > {Note: An alternate option would have had every RBridge send > > Hellos always on all VLANs they have been configured to send on}. > > > > f) all RBridge-RBridge traffic (other than Hellos) is always > > sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, > > then R2 cannot forward data to/from that cloud, or receive > > LSPs on that cloud. In other words, that link will be broken > > for R2. The purpose of the Hellos is only to notice (through > > a means *in addition* to the safeguards in the other > > proposals) that R2 is not DRB for the link. > > > > g) We do the same safeguards as in the other proposals > > (report the bridge root ID in the pseudonode LSP, don't > > decapsulate from ingress Ra unless you have all the relevant > > pseudonode LSPs attached to Ra to ensure that none of them > > have the same root RBridge, and that you delay before > > encapsulating data off the link until you've been DRB for > > enough time to synchronize LSP databases with your neighbors) > > > > ************** > > My thoughts on this: > > > > a) I assume the only reason to send Hellos on multiple VLANs > > is to minimize the probability of accidentally having two > > DRBs, and therefore loops. I'm not convinced this adds safety > > over the safeguards in the single VLAN proposals. > > > > b) this winds up with sending lots more Hellos, but does not > > create additional pseudonodes, or complicate data forwarding, > > because the Hellos is only to find neighbors, not to repair > > use of the link for forwarding data (or propagating LSPs) if > > VLAN 1 is partitioned on the link > > > > c) This is a lot more complicated. It might seem simpler to > > not try to optimize the number of Hellos (like I did in point > > e), but there seem to be scary corner cases where all the > > VLANs common to R1 and R2 are partitioned. Saying there must > > be an unpartitioned VLAN 1 seems the safest. > > > > So, I still like the "just use VLAN 1" proposal. > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9SHSu6c021337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sun, 28 Oct 2007 10:28:56 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l9SHbkXq004375; Sun, 28 Oct 2007 11:37:46 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 12:28:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2007 12:28:46 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01DA8D3A@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <47217A84.1040303@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXkZ/uPF1Fs5u3TtKQJjskB4t2IAB9aVMg References: <4720E6A3.7010603@sun.com><3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> <47217A84.1040303@sun.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-OriginalArrivalTime: 28 Oct 2007 17:28:49.0448 (UTC) FILETIME=[007CBA80:01C81988] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SHSu6c021337 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 17:29:40 -0000 Status: RO Content-Length: 8870 Radia, Using sets of VLANs as a range of values is likely to force sub-optimality on load-sharing - possibly to the extent that load sharing becomes useless. It is not a trivial exercise to make VLAN topologies line up conveniently with VLAN ID assignments. In fact, assuming that it is possible to modify VLAN topologies, it's most likely infeasible to do so in some scenarios. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Friday, October 26, 2007 1:26 AM > To: Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Right...I was not intending to preclude having R1 be DRB for (inner) > VLANs (v1, v2, v3) and > R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you > point out, if > each RBridge can > be configured with a different priority for each of the 4000 > VLANs, the > IS-IS Hello would > get too large. The only reason for different priorities is to do some > load splitting. I'd argue > that with just a tiny bit of flexibility customers can get enough > functionality. So I'd suggest > limiting multiple priorities to some reasonable number, like > 3, and sets > of VLANs to ranges. > That would mean that R1 can claim to have priority P1 for the > VLANs in > range (n1-n2), and > priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs > betwen (n5-n6). > This would require (for 3 different priorities) 18 bytes in > the Hello. > For instance, "I have > priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and > priority 2 for > VLANs (101-115). Perhaps another 500 bytes to do a bit mask > of all the > VLANs that > you support at all (or alternatively you can't claim to have > a priority > for a range of VLANs unless > you support all the VLANs in that range). > > Likewise, in the pseudonode, we'd have to say the range of VLANs that > that pseudonode > refers to. > > And it's NOT a DRB collision if there is a pseudonode, say R1,17, > for which R1 is DRB, reporting root bridge X > and R2 is DRB on a link with root bridge X as long as the set > of VLANs > reported > in R1.17's LSP does not overlap with the set of VLANs that R2 > is DRB for > on that link. > > And actually, R2 really only needs to decline to forward data (act as > DRB) for the set of > VLANs in R1.17's pseudonode that overlaps with R2's. It could > be that R2 > has some > other VLANs that are not in R1.17's pseudonode. > > So that's an additional refinement on the rules that should be added. > > Perhaps we should start a different thread on whether people can live > with having a single > DRB be configured with at most 3 priorities on a port, and > require the > set of VLANs for > each priority to be expressible in a range (rather than having to > enumerate each of the > VLAN tags individually). > > Radia > > > > Eastlake III Donald-LDE008 wrote: > > Hi Radia, > > > > The proposal below appears to be written from the "one DRB per link" > > point of view while the current draft claims to support "one DRB per > > VLAN per link". Even if you have complete VLAN 1 > connectivity and use > > single Hellos, I'm not quite sure how the one DRB per VLAN per link > > would work. In principle, the per VLAN priority for a > Rbridge port for > > all its configured VLANs might not fit into a Hello... > > > > Thanks, > > Donald > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On > > Behalf Of Radia Perlman > > Sent: Thursday, October 25, 2007 2:56 PM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] A "multiple VLAN Hello" proposal > > > > It's a bit difficult to argue on the list about proposals > when one of > > them has not been specified, especially > > since I can imagine lots of variations on multiple VLANs, > and lots of > > questions about choices for > > the details. > > > > Here's an attempt to specify a "send Hellos on multiple > VLANs" proposal. > > > > I've chosen details > > where in many cases there are other options I could have > chosen. But I > > think we need some > > tangible proposal with details worked out before advocating for it. > > People should feel free > > to suggest modifications to the details below, but I, as I > said, cannot > > argue between proposals > > if the proposals aren't concrete. I've tried to make it as > simple as > > possible, as low overhead > > as possible, while adding the ability to configure sending > Hellos on > > lots of VLANs. > > > > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > > > b) In addition, RBridges MAY be configured to send and > receive Hellos on > > > > some set of > > VLANs in addition to 1 > > > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all > the VLANs that > > R1 is > > configured to send (and receive) on. To clarify, as long as > R1 thinks > > itself is DRB, it will > > send Hellos on the complete set of VLANs that R1 is > configured to send > > on. In addition (see > > point "e"), R1 may wind up having to send Hellos on some > set of VLANs in > > > > addition > > to those it was configured to send on. > > > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has > > heard Hellos from. In addition, > > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > that R1 hears > > > > hellos from R2 on. > > The one VLAN that R1 reports is the lowest numbered VLAN > that R1 hears a > > > > Hello from R2 on. > > > > e) If R1 does not hear a Hello from R2 on any of R1's > configured VLANs, > > but does hear on some other VLAN, say VLAN x, then R1 adds > "x" to the > > set of VLANs that > > R1 transmits on, as long as it continues to hear Hellos on > VLAN x (and > > no > > other VLANs) from R2. Note that if R2's Hello gives R2 > better priority > > for > > being DRB, then R1 will not be DRB any more, but MUST > continue sending > > Hellos on > > VLAN x (even though x is not in the set of VLANs > > that R1 was configured to send on) to ensure that R2 > continues to send > > its Hellos on VLAN x. > > > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > the VLAN > > that the DRB reports > > that it has heard from you on. This cuts down on Hellos > since it means > > that non-DRB RBridges > > will send on at most two VLANs. > > {Note: An alternate option would have had every RBridge send Hellos > > always on all VLANs they > > have been configured to send on}. > > > > f) all RBridge-RBridge traffic (other than Hellos) is > always sent on > > VLAN 1. So if R2 cannot > > reach the DRB via VLAN 1, then R2 cannot forward data to/from that > > cloud, or receive > > LSPs on that cloud. In other words, that link will be > broken for R2. The > > > > purpose > > of the Hellos is only to notice (through a means *in > addition* to the > > safeguards in the other > > proposals) that R2 is not DRB for the link. > > > > g) We do the same safeguards as in the other proposals (report the > > bridge root ID in the pseudonode LSP, don't decapsulate > from ingress Ra > > unless > > you have all the relevant pseudonode LSPs attached to Ra to > ensure that > > none of them have > > the same root RBridge, and that you delay before > encapsulating data off > > the link until you've > > been DRB for enough time to synchronize LSP databases with your > > neighbors) > > > > ************** > > My thoughts on this: > > > > a) I assume the only reason to send Hellos on multiple VLANs is to > > minimize the probability > > of accidentally having two DRBs, and therefore loops. I'm > not convinced > > this adds safety > > over the safeguards in the single VLAN proposals. > > > > b) this winds up with sending lots more Hellos, but does not create > > additional pseudonodes, > > or complicate data forwarding, because the Hellos is only to find > > neighbors, not to repair > > use of the link for forwarding data (or propagating LSPs) > if VLAN 1 is > > partitioned on the link > > > > c) This is a lot more complicated. It might seem simpler to > not try to > > optimize the number of > > Hellos (like I did in point e), but there seem to be scary > corner cases > > where all the VLANs > > common to R1 and R2 are partitioned. Saying there must be an > > unpartitioned VLAN 1 seems > > the safest. > > > > So, I still like the "just use VLAN 1" proposal. > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9SBnqP8020533 for <rbridge@postel.org>; Sun, 28 Oct 2007 04:49:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2007 04:49:05 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20258FEF5@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <472408EF.9030801@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? thread-index: AcgZFqA+oqQ04BWNRjmcmmsXlZhcCQANpEGQ References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <471FBC2E.5080705@sun.com> <4C94DE2070B172459E4F1EE14BD2364E91F9E5@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA20258F953@nuova-ex1.hq.nuovaimpresa.com> <472408EF.9030801@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9SBnqP8020533 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 11:50:38 -0000 Status: RO Content-Length: 17802 Radia, Can you explain me if your solution supports the example that I have drawn in PowerPoint at: http://www.ip6.com/example.ppt ? Thank You Answering your email: I have seen customers deploying VLANs in a variety of ways. Some customers have VLAN 1 end-to-end and they use it for control and data traffic. Some customers use VLAN 1 only for control traffic. Some customers wants all VLANs (including VLAN 1) being local (not end-to-end). Some customers prefer to move some control protocol to another VLAN. I have seen multiple different approaches. You ask for rational, "tangible reasons". Each customer has its own reasons that don't match the ones of other customers. There are no universal tangible reasons, you just need to realize that IEEE 802.1Q allows VLANs to be deployed in many different way. Any solution that poses restrictions is going to be OK for some customers and KO for others. Over the years I have learned to live with the fact that customers have different deployment approaches that are perfectly valid because allowed by IEEE 802.1Q and by the products. In TRILL we often speak about plug-and-play. If we consider plug-and-play, VLAN 1 is the only one enabled by default and therefore it seems a reasonable default solution. While this is a valid concept in the consumer space, it is absolutely not valid in Enterprise/Datacenter. Enterprise/Datacenter customers request that all the new boxes are shipped with all the ports disabled, because they realized that the switches will be connected in complex configurations in which plug-and-play is very dangerous. I expect the same to be true for RBridges, where customers will carefully design, test in a separate environment and bring-up a configuration that will match the existing VLAN deployment they have. Inline for you specific questions: > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Saturday, October 27, 2007 8:59 PM > To: Silvano Gai > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > I'm anxious to close on this issue, but > Silvano...you always speak in such absolutes: words like > "unrealistic" without giving tangible reasons what the > problem is. Again, everything is engineering tradeoffs, and we have to > understand what the specific > pros and cons are (not phrases like > "won't work" "unrealistic" "not flexible enough", but instead "won't allow > this *particular* scenario") > > Question: Is the problem picking specifically VLAN 1 as > our chosen single VLAN number? If we picked a different (unconfigurable) > VLAN number would that be OK? I think that VLAN 1 is probably our best default choice. I don't object to have VLAN 1 to be the default VLAN. If so, what number? If you are arguing that > it's OK to require one VLAN not to be partitioned, and that all > RBridge-RBridge > communication be done over that VLAN, then I really don't understand. I am not sure what you are asking. If you are speaking of the backbone between RBridges, the outer VLAN tag for sure may not be the same end-to-end. A department of a large corporation may want to deploy RBridges in 5 different sites. The VLAN they have available from site_1 to site_2 may be VLAN 5, form site_1 to site_3 VLAN 7, from site_3 to site_4 VLAN 4. If you want all this VLANs to be a single VLAN end-to-end, there is a significant change that needs to happen in the communication infrastructure that may be considered difficult or impossible. If instead you are discussing the access to the RBridge clouds, I think it is reasonable to require that the RBridges that perform TRILL encapsulation for an Ethernet Cloud have a common VLAN. VLAN1 may be the default, but I think that the value should be programmable. > If that were the case, why can't we (TRILL) put a stake in the ground > and say "RBridges will > use VLAN 1", and if the customer wanted to use VLAN 1 for something > else, but was willing > to configure RBridges to use, say, VLAN 57, why can't that customer > renumber their own > VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let the > rest of > the world have the simplicity of an unconfigurable choice of VLAN 1? I don't think this is acceptable for many customers. You are putting a stake in the ground that IEEE has never put. > > Are you saying that you don't want to require customers to have *any* > VLAN number that > isn't partitioned, I am not sure what you mean with "*any* VLAN number that isn't partitioned", are you speaking of inner VLAN or outer VLAN? In most installation the numbering spaces of the Backbone VLANs and Access VLANs are disjoint. I don't think this is an issue since the access VLANs appears in the inner VLAN tag, while the backbone VLANs appears in the outer VLAN tag. and you want a solution that somehow finds all > possible ways of having > RBridges talk to each other using every possible VLAN? Again, when you are saying "RBridges talk to each other" are you speaking of the TRILL encapsulated frames or of the DRB election on the access? Again see my example at: http://www.ip6.com/example.ppt -- Silvano If so, this > proposal has never been > specified, and, as I said, can't be evaluated unless it is specified. > > Anyway, I really want to understand the issue, but you really have to be > specific about > what is being precluded by saying "just use VLAN 1", or even the > fallback compromise "just use a single > VLAN that is default=1, but the DRB can tell all the other RBridges to > use some other VLAN > number instead". I don't think we should give in and make it > configurable without understanding > why it is less work for the customer to configure the RBridges to change > to a different VLAN number X > than for that same customer to reconfigure whatever it was they were > doing to switch VLAN 1 > with VLAN X, so that RBridges can use VLAN 1. > > Radia > > > Silvano Gai wrote: > > Assuming that you always have connectivity on VLAN 1 is unrealistic. > > Different installation may use VLAN 1 for different purposes. > > > > Forbidding by standard to change this VLAN to another value is not going > > to work in products. Products will need to support the capability to > > change this value to meet customer needs. They will therefore invent > > proprietary mechanism to support a different value. Result: lack of > > interoperability. > > > > -- Silvano > > > > > >> -----Original Message----- > >> From: Anoop Ghanwani [mailto:anoop@brocade.com] > >> Sent: Thursday, October 25, 2007 10:20 AM > >> To: Radia Perlman; Silvano Gai > >> Cc: Developing a hybrid router/bridge. > >> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > >> RBridgepackets? > >> > >> > >> Hi Radia, > >> > >> I am fairly comfortable with adopting the single > >> VLAN hello proposal and forcing that to be VLAN 1. > >> > >> I would rather not have to deal with the complexity > >> of making it configurable because even that can > >> be subject to misconfiguration and would have its > >> own set of issues, but I am also not totally > >> opposed to that if someone else feels strongly > >> about it. The main argument for doing that > >> would be point (b) in your message -- that > >> VLAN 1 was already being used for something > >> else and the operator didn't want to use it > >> for RBridge control traffic. > >> > >> As you point out, it looks like the proposal > >> for sending hellos on multiple VLANs would also > >> require additional scrutiny/specification before > >> it can be adopted. Unless shown to be absolutely > >> necessary, this approach imposes a significant > >> processing burden so I would rather see us > >> solve the problem with the hellos on VLAN 1 > >> only. > >> > >> Anoop > >> > >> > >>> -----Original Message----- > >>> From: Radia Perlman [mailto:Radia.Perlman@sun.com] > >>> Sent: Wednesday, October 24, 2007 2:42 PM > >>> To: Silvano Gai > >>> Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > >>> Subject: Re: [rbridge] Final outcome of outer VLAN tags > >>> onRBridge-RBridgepackets? > >>> > >>> It's always hard to catch up on a thread after being away > >>> from email for a couple of days, but Silvano --- both the > >>> tone and (lack of) content of your message below makes it > >>> really difficult. > >>> > >>> In order to do quality engineering, we need to understand > >>> what all the tradeoffs are, and we have to be able to do > >>> discourse in an atmosphere of mutual respect. > >>> > >>> Saying something like "not doing it my way is 'too weak to be > >>> practical', or 'holds water like a pasta strainer' is not > >>> engineering. It is attempting to ridicule anyone who > >>> disagrees with you, and also is completely uninformative > >>> because you are not saying what the tradeoffs are, or even > >>> the details of how the thing you want would work. > >>> > >>> I am usually proud of this WG because we usually do explore > >>> all the options and what the tradoffs are without resorting > >>> to bullying and ridicule. Let's strive to do engineering that way. > >>> > >>> So let me demonstrate by getting back to the thread. > >>> > >>> I think the "downsides" of sending all RBridge-RBridge > >>> messages on a single unconfigurable VLAN (proposal being VLAN 1) > >>> > > are: > > > >>> a) if VLAN 1 is indeed partitioned, the RBridges will not > >>> know through IS-IS Hellos that they have RBridge neighbors, > >>> and multiple DRBs will be elected. But the proposal also > >>> includes how to prevent multiple DRB, namely by being > >>> conservative about forwarding data traffic to/from the link > >>> until we discover, though reporting the bridge root ID in > >>> LSPs, that it is safe to do so > >>> b) a customer might want to not use that VLAN for > >>> RBridge-RBridge traffic. However, if that customer felt so > >>> strongly about minimizing RBridge-Rbridge traffic, they could > >>> reconfigure use of the VLANs to move what they were using > >>> VLAN 1 to, to some other VLAN. So saying "just use 1" might > >>> inconvenience one customer who is already very savvy and > >>> likes to do really fancy configuration things, but does not > >>> prevent them from accomplishing all the exotic things they > >>> are trying to do -- just means some more configuration. And > >>> is saves what hopefully is the vast majority of customers > >>> from having to do any configuration whatsoever, and > >>> simplifies the spec and prevents misconfiguration. > >>> > >>> The upside of saying "just use 1" is extreme simplicity, and > >>> with the safeguards, will not have any higher probabilty of > >>> loops than already exists due to repeaters coming up, or > >>> bridge spanning tree messages getting lost. > >>> > >>> The next more complex proposal was to allow configuration to > >>> still ultimately use one VLAN per cloud, but allow it to be > >>> configurable to be something other than 1. I gave a proposal > >>> for doing that in a previous message (the DRB tells all the > >>> other RBridges what VLAN to use, while the DRB still sends on > >>> VLAN 1 in addition to the VLAN the DRB tells everyone to send > >>> one). I think the upside over the simplest "just use 1", is > >>> that it allows a customer that doesn't want RBridge-RBridge > >>> traffic being used on VLAN 1, or intentionally wants data > >>> traffic on VLAN 1 to be partitioned on a cloud, to move to a > >>> VLAN on that cloud that is OK not to be partitioned. The > >>> downside is that steady state the DRB will send one more > >>> Hello (on VLAN 1) than it would have, once the DRB tells all > >>> the other RBridges what VLAN to send on, and it is one more > >>> configuration thing to have to explain. And it seems likely > >>> that the DRB will be misconfigured and declare that RBridges > >>> will use VLAN k instead of 1, when some other RBridge on the > >>> cloud is not configured to support k. It won't be fatal > >>> (since that other RBridge will still hear the DRB on VLAN 1 > >>> and will also know about the other DRB through link state > >>> messages). My opinion is that this extra complexity over > >>> "just use 1" is not warranted given the small upside. > >>> > >>> If there is another proposal, say "send all Hellos on all > >>> VLANs", I claim that the details of that have never been > >>> specified well enough for that proposal to be evaluated. So > >>> if someone who advocates that can do that, staying technical, > >>> covering all details like whether in your IS-IS Hello you > >>> list all the VLAN tags you've heard Hellos from for each > >>> neighbor, and how you send a multicast data message when you > >>> have adjacencies with different VLAN tags for different > >>> subsets of neighbors, I'd like to hear it. > >>> > >>> And by all means, if I have missed some of the downsides on > >>> "just use VLAN 1", or "just use a single VLAN, but it can be > >>> configured to be something other than 1", then by all means > >>> add to the arguments. > >>> > >>> Radia > >>> > >>> > >>> > >>> > >>> Silvano Gai wrote: > >>> > >>>> I want to restate that IMHO a design that sends messages on > >>>> > >>> a single > >>> > >>>> VLAN is so week to be completely useless. > >>>> > >>>> I met Anoop on a plane back from a T11 meeting and we discussed > >>>> > > the > > > >>>> issue of sending messages on all the configured VLANs. > >>>> > >>> Anoop pointed > >>> > >>>> out that, if these messages are ISIS messages, this can > >>>> > >>> overload the > >>> > >>>> RBrige supervisor. > >>>> > >>>> We identified a possible solution based on two different > >>>> > >>> message types: > >>> > >>>> - ISIS used on a single VLAN to compute adjacency > >>>> - simple per-VLAN checking on all the VLANs to verify > >>>> > > reachability. > > > >>>> The second kind of messages is much simpler and therefore they > >>>> > > load > > > >>>> less the RBrige supervisor. In the future, per-VLAN checking can > >>>> > > be > > > >>>> implemented by the port ASIC. This seems a viable solution that > >>>> requires design effort, but it is promising. > >>>> > >>>> Without the per-VLAN checking, running ISIS on a single VLAN holds > >>>> water like a pasta-strainer. > >>>> > >>>> -- Silvano > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: rbridge-bounces@postel.org > >>>>> > >>> [mailto:rbridge-bounces@postel.org] > >>> > >>>> On > >>>> > >>>> > >>>>> Behalf Of Anoop Ghanwani > >>>>> Sent: Monday, October 22, 2007 11:01 AM > >>>>> To: Radia Perlman; Developing a hybrid router/bridge. > >>>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags > >>>>> > > onRBridge- > > > >>>>> RBridgepackets? > >>>>> > >>>>> > >>>>> If we want to make implementations work with only a single > >>>>> > >>> Hello for > >>> > >>>>> all VLANs than the option is (a). I think that is what it > >>>>> > >>> should be. > >>> > >>>>> Basically, as a part of RBridge configuration there should be a > >>>>> "RBridge Control VLAN" configuration that applies to the whole > >>>>> device. It should default to VLAN 1, but an operator can > >>>>> > >>> choose to > >>> > >>>>> change it. > >>>>> A RBridge only emits Hellos on that VLAN. If it receives > >>>>> > >>> Hellos on > >>> > >>>>> any other VLAN that should be detected as an error condition and > >>>>> reported. > >>>>> > >>>>> There have been some problem corner cases that have been > >>>>> > >>> pointed out > >>> > >>>>> previously on the list that may result in temporary duplication > >>>>> > > of > > > >>>>> traffic when there is misconfiguration. Those should be > >>>>> > >>> documented. > >>> > >>>>> Anoop > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: rbridge-bounces@postel.org > >>>>>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > >>>>>> Sent: Saturday, October 20, 2007 9:47 PM > >>>>>> To: Developing a hybrid router/bridge. > >>>>>> Subject: [rbridge] Final outcome of outer VLAN tags on > >>>>>> RBridge-RBridgepackets? > >>>>>> > >>>>>> I'm not sure I understood the final consensus on what we > >>>>>> > >>> should do > >>> > >>>>>> for outer VLAN tags on inter-RBridge packets. > >>>>>> > >>>>>> The possibilities I think the consensus might have been are: > >>>>>> > >>>>>> a) only use VLAN 1, explicit tag, no configuration possible. > >>>>>> b) default is VLAN 1, explicit tag, configuration is possible to > >>>>>> change sending with VLAN tag(s) something other than 1. > >>>>>> > >>> If this is > >>> > >>>>>> what was decided, I don't believe we've worked out the design > >>>>>> details. I'd assume this would mean RBridges should be willing > >>>>>> > > to > > > >>>>>> receive packets from other RBridges regardless of outer VLAN > >>>>>> > > tag. > > > >>>>>> Would we then mark in the Hellos what VLAN tag(s) you've > >>>>>> > >>> heard from > >>> > >>>>>> what other RBridges with? What do we do with multicast if there > >>>>>> isn't a single VLAN tag that seems to work to send to everyone? > >>>>>> Would we allow configuration to send on a set of VLAN > >>>>>> > >>> tags, or just > >>> > >>>>>> on one at a time (and we allow configuration to say which one it > >>>>>> is)? > >>>>>> > >>>>>> Certainly a) is simpler. If the consensus was b), we'd > >>>>>> > >>> better work > >>> > >>>>>> out the details. > >>>>>> > >>>>>> Radia > >>>>>> _______________________________________________ > >>>>>> rbridge mailing list > >>>>>> rbridge@postel.org > >>>>>> http://mailman.postel.org/mailman/listinfo/rbridge > >>>>>> > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> rbridge mailing list > >>>>> rbridge@postel.org > >>>>> http://mailman.postel.org/mailman/listinfo/rbridge > >>>>> > >>>>> Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9S3vU9j026503 for <rbridge@postel.org>; Sat, 27 Oct 2007 20:57:30 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQL00492SBAL700@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 27 Oct 2007 20:57:10 -0700 (PDT) Received: from [192.168.2.58] ([67.161.89.58]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQL006KCSB8ZGH0@mail.sunlabs.com> for rbridge@postel.org; Sat, 27 Oct 2007 20:57:10 -0700 (PDT) Date: Sat, 27 Oct 2007 20:58:39 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <34BDD2A93E5FD84594BB230DD6C18EA20258F953@nuova-ex1.hq.nuovaimpresa.com> To: Silvano Gai <sgai@nuovasystems.com> Message-id: <472408EF.9030801@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <471FBC2E.5080705@sun.com> <4C94DE2070B172459E4F1EE14BD2364E91F9E5@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA20258F953@nuova-ex1.hq.nuovaimpresa.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 28 Oct 2007 03:58:56 -0000 Status: RO Content-Length: 13773 I'm anxious to close on this issue, but Silvano...you always speak in such absolutes: words like "unrealistic" without giving tangible reasons what the problem is. Again, everything is engineering tradeoffs, and we have to understand what the specific pros and cons are (not phrases like "won't work" "unrealistic" "not flexible enough", but instead "won't allow this *particular* scenario") Question: Is the problem picking specifically VLAN 1 as our chosen single VLAN number? If we picked a different (unconfigurable) VLAN number would that be OK? If so, what number? If you are arguing that it's OK to require one VLAN not to be partitioned, and that all RBridge-RBridge communication be done over that VLAN, then I really don't understand. If that were the case, why can't we (TRILL) put a stake in the ground and say "RBridges will use VLAN 1", and if the customer wanted to use VLAN 1 for something else, but was willing to configure RBridges to use, say, VLAN 57, why can't that customer renumber their own VLANs so that they switch their uses of VLAN 57 and VLAN 1, and let the rest of the world have the simplicity of an unconfigurable choice of VLAN 1? Are you saying that you don't want to require customers to have *any* VLAN number that isn't partitioned, and you want a solution that somehow finds all possible ways of having RBridges talk to each other using every possible VLAN? If so, this proposal has never been specified, and, as I said, can't be evaluated unless it is specified. Anyway, I really want to understand the issue, but you really have to be specific about what is being precluded by saying "just use VLAN 1", or even the fallback compromise "just use a single VLAN that is default=1, but the DRB can tell all the other RBridges to use some other VLAN number instead". I don't think we should give in and make it configurable without understanding why it is less work for the customer to configure the RBridges to change to a different VLAN number X than for that same customer to reconfigure whatever it was they were doing to switch VLAN 1 with VLAN X, so that RBridges can use VLAN 1. Radia Silvano Gai wrote: > Assuming that you always have connectivity on VLAN 1 is unrealistic. > Different installation may use VLAN 1 for different purposes. > > Forbidding by standard to change this VLAN to another value is not going > to work in products. Products will need to support the capability to > change this value to meet customer needs. They will therefore invent > proprietary mechanism to support a different value. Result: lack of > interoperability. > > -- Silvano > > >> -----Original Message----- >> From: Anoop Ghanwani [mailto:anoop@brocade.com] >> Sent: Thursday, October 25, 2007 10:20 AM >> To: Radia Perlman; Silvano Gai >> Cc: Developing a hybrid router/bridge. >> Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- >> RBridgepackets? >> >> >> Hi Radia, >> >> I am fairly comfortable with adopting the single >> VLAN hello proposal and forcing that to be VLAN 1. >> >> I would rather not have to deal with the complexity >> of making it configurable because even that can >> be subject to misconfiguration and would have its >> own set of issues, but I am also not totally >> opposed to that if someone else feels strongly >> about it. The main argument for doing that >> would be point (b) in your message -- that >> VLAN 1 was already being used for something >> else and the operator didn't want to use it >> for RBridge control traffic. >> >> As you point out, it looks like the proposal >> for sending hellos on multiple VLANs would also >> require additional scrutiny/specification before >> it can be adopted. Unless shown to be absolutely >> necessary, this approach imposes a significant >> processing burden so I would rather see us >> solve the problem with the hellos on VLAN 1 >> only. >> >> Anoop >> >> >>> -----Original Message----- >>> From: Radia Perlman [mailto:Radia.Perlman@sun.com] >>> Sent: Wednesday, October 24, 2007 2:42 PM >>> To: Silvano Gai >>> Cc: Anoop Ghanwani; Developing a hybrid router/bridge. >>> Subject: Re: [rbridge] Final outcome of outer VLAN tags >>> onRBridge-RBridgepackets? >>> >>> It's always hard to catch up on a thread after being away >>> from email for a couple of days, but Silvano --- both the >>> tone and (lack of) content of your message below makes it >>> really difficult. >>> >>> In order to do quality engineering, we need to understand >>> what all the tradeoffs are, and we have to be able to do >>> discourse in an atmosphere of mutual respect. >>> >>> Saying something like "not doing it my way is 'too weak to be >>> practical', or 'holds water like a pasta strainer' is not >>> engineering. It is attempting to ridicule anyone who >>> disagrees with you, and also is completely uninformative >>> because you are not saying what the tradeoffs are, or even >>> the details of how the thing you want would work. >>> >>> I am usually proud of this WG because we usually do explore >>> all the options and what the tradoffs are without resorting >>> to bullying and ridicule. Let's strive to do engineering that way. >>> >>> So let me demonstrate by getting back to the thread. >>> >>> I think the "downsides" of sending all RBridge-RBridge >>> messages on a single unconfigurable VLAN (proposal being VLAN 1) >>> > are: > >>> a) if VLAN 1 is indeed partitioned, the RBridges will not >>> know through IS-IS Hellos that they have RBridge neighbors, >>> and multiple DRBs will be elected. But the proposal also >>> includes how to prevent multiple DRB, namely by being >>> conservative about forwarding data traffic to/from the link >>> until we discover, though reporting the bridge root ID in >>> LSPs, that it is safe to do so >>> b) a customer might want to not use that VLAN for >>> RBridge-RBridge traffic. However, if that customer felt so >>> strongly about minimizing RBridge-Rbridge traffic, they could >>> reconfigure use of the VLANs to move what they were using >>> VLAN 1 to, to some other VLAN. So saying "just use 1" might >>> inconvenience one customer who is already very savvy and >>> likes to do really fancy configuration things, but does not >>> prevent them from accomplishing all the exotic things they >>> are trying to do -- just means some more configuration. And >>> is saves what hopefully is the vast majority of customers >>> from having to do any configuration whatsoever, and >>> simplifies the spec and prevents misconfiguration. >>> >>> The upside of saying "just use 1" is extreme simplicity, and >>> with the safeguards, will not have any higher probabilty of >>> loops than already exists due to repeaters coming up, or >>> bridge spanning tree messages getting lost. >>> >>> The next more complex proposal was to allow configuration to >>> still ultimately use one VLAN per cloud, but allow it to be >>> configurable to be something other than 1. I gave a proposal >>> for doing that in a previous message (the DRB tells all the >>> other RBridges what VLAN to use, while the DRB still sends on >>> VLAN 1 in addition to the VLAN the DRB tells everyone to send >>> one). I think the upside over the simplest "just use 1", is >>> that it allows a customer that doesn't want RBridge-RBridge >>> traffic being used on VLAN 1, or intentionally wants data >>> traffic on VLAN 1 to be partitioned on a cloud, to move to a >>> VLAN on that cloud that is OK not to be partitioned. The >>> downside is that steady state the DRB will send one more >>> Hello (on VLAN 1) than it would have, once the DRB tells all >>> the other RBridges what VLAN to send on, and it is one more >>> configuration thing to have to explain. And it seems likely >>> that the DRB will be misconfigured and declare that RBridges >>> will use VLAN k instead of 1, when some other RBridge on the >>> cloud is not configured to support k. It won't be fatal >>> (since that other RBridge will still hear the DRB on VLAN 1 >>> and will also know about the other DRB through link state >>> messages). My opinion is that this extra complexity over >>> "just use 1" is not warranted given the small upside. >>> >>> If there is another proposal, say "send all Hellos on all >>> VLANs", I claim that the details of that have never been >>> specified well enough for that proposal to be evaluated. So >>> if someone who advocates that can do that, staying technical, >>> covering all details like whether in your IS-IS Hello you >>> list all the VLAN tags you've heard Hellos from for each >>> neighbor, and how you send a multicast data message when you >>> have adjacencies with different VLAN tags for different >>> subsets of neighbors, I'd like to hear it. >>> >>> And by all means, if I have missed some of the downsides on >>> "just use VLAN 1", or "just use a single VLAN, but it can be >>> configured to be something other than 1", then by all means >>> add to the arguments. >>> >>> Radia >>> >>> >>> >>> >>> Silvano Gai wrote: >>> >>>> I want to restate that IMHO a design that sends messages on >>>> >>> a single >>> >>>> VLAN is so week to be completely useless. >>>> >>>> I met Anoop on a plane back from a T11 meeting and we discussed >>>> > the > >>>> issue of sending messages on all the configured VLANs. >>>> >>> Anoop pointed >>> >>>> out that, if these messages are ISIS messages, this can >>>> >>> overload the >>> >>>> RBrige supervisor. >>>> >>>> We identified a possible solution based on two different >>>> >>> message types: >>> >>>> - ISIS used on a single VLAN to compute adjacency >>>> - simple per-VLAN checking on all the VLANs to verify >>>> > reachability. > >>>> The second kind of messages is much simpler and therefore they >>>> > load > >>>> less the RBrige supervisor. In the future, per-VLAN checking can >>>> > be > >>>> implemented by the port ASIC. This seems a viable solution that >>>> requires design effort, but it is promising. >>>> >>>> Without the per-VLAN checking, running ISIS on a single VLAN holds >>>> water like a pasta-strainer. >>>> >>>> -- Silvano >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces@postel.org >>>>> >>> [mailto:rbridge-bounces@postel.org] >>> >>>> On >>>> >>>> >>>>> Behalf Of Anoop Ghanwani >>>>> Sent: Monday, October 22, 2007 11:01 AM >>>>> To: Radia Perlman; Developing a hybrid router/bridge. >>>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags >>>>> > onRBridge- > >>>>> RBridgepackets? >>>>> >>>>> >>>>> If we want to make implementations work with only a single >>>>> >>> Hello for >>> >>>>> all VLANs than the option is (a). I think that is what it >>>>> >>> should be. >>> >>>>> Basically, as a part of RBridge configuration there should be a >>>>> "RBridge Control VLAN" configuration that applies to the whole >>>>> device. It should default to VLAN 1, but an operator can >>>>> >>> choose to >>> >>>>> change it. >>>>> A RBridge only emits Hellos on that VLAN. If it receives >>>>> >>> Hellos on >>> >>>>> any other VLAN that should be detected as an error condition and >>>>> reported. >>>>> >>>>> There have been some problem corner cases that have been >>>>> >>> pointed out >>> >>>>> previously on the list that may result in temporary duplication >>>>> > of > >>>>> traffic when there is misconfiguration. Those should be >>>>> >>> documented. >>> >>>>> Anoop >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: rbridge-bounces@postel.org >>>>>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >>>>>> Sent: Saturday, October 20, 2007 9:47 PM >>>>>> To: Developing a hybrid router/bridge. >>>>>> Subject: [rbridge] Final outcome of outer VLAN tags on >>>>>> RBridge-RBridgepackets? >>>>>> >>>>>> I'm not sure I understood the final consensus on what we >>>>>> >>> should do >>> >>>>>> for outer VLAN tags on inter-RBridge packets. >>>>>> >>>>>> The possibilities I think the consensus might have been are: >>>>>> >>>>>> a) only use VLAN 1, explicit tag, no configuration possible. >>>>>> b) default is VLAN 1, explicit tag, configuration is possible to >>>>>> change sending with VLAN tag(s) something other than 1. >>>>>> >>> If this is >>> >>>>>> what was decided, I don't believe we've worked out the design >>>>>> details. I'd assume this would mean RBridges should be willing >>>>>> > to > >>>>>> receive packets from other RBridges regardless of outer VLAN >>>>>> > tag. > >>>>>> Would we then mark in the Hellos what VLAN tag(s) you've >>>>>> >>> heard from >>> >>>>>> what other RBridges with? What do we do with multicast if there >>>>>> isn't a single VLAN tag that seems to work to send to everyone? >>>>>> Would we allow configuration to send on a set of VLAN >>>>>> >>> tags, or just >>> >>>>>> on one at a time (and we allow configuration to say which one it >>>>>> is)? >>>>>> >>>>>> Certainly a) is simpler. If the consensus was b), we'd >>>>>> >>> better work >>> >>>>>> out the details. >>>>>> >>>>>> Radia >>>>>> _______________________________________________ >>>>>> rbridge mailing list >>>>>> rbridge@postel.org >>>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge@postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>>> Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9QI0J6T029252 for <Rbridge@postel.org>; Fri, 26 Oct 2007 11:00:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1193421618!31024883!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6913 invoked from network); 26 Oct 2007 18:00:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 26 Oct 2007 18:00:18 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9QI08iB025383 for <Rbridge@postel.org>; Fri, 26 Oct 2007 11:00:18 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l9QI07mn020195 for <Rbridge@postel.org>; Fri, 26 Oct 2007 13:00:07 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l9QI06VV020178 for <Rbridge@postel.org>; Fri, 26 Oct 2007 13:00:07 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 26 Oct 2007 14:00:04 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6DED@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032192F4@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call: Single Pseudo-node Announcment Thread-Index: AcgFbQQ7CB53pCMuQLq7lbwJdGzn5AHkhULQAr6zI8A= References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D9790032192F4@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9QI0J6T029252 Subject: [rbridge] Consensus Call: Single Pseudo-node Announcment X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 18:00:33 -0000 Status: RO Content-Length: 1014 This consensus from the Chicago meeting has been confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Friday, October 12, 2007 2:46 PM To: Rbridge@postel.org Subject: [rbridge] Consensus Check: Single Pseudo-node Announcment This is the last of the consensus checks via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Each RBridge which is DRB for one or more VLANs out one physical port should announce only one pseudo-node for the port. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Please also post any other comments you have on the current -05 protocol draft. If a revision can be posted in 3 or 4 weeks, we may be able to do a working group last call before the December IETF TRILL meeting. Thanks, Donald & Erik Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9Q9GS64001289 for <rbridge@postel.org>; Fri, 26 Oct 2007 02:16:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Oct 2007 02:16:13 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20258F953@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E91F9E5@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? thread-index: AcgWhouop6vKgvVeR1eEbNP3V93vmAAoyO6AACGo1dA= References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <471FBC2E.5080705@sun.com> <4C94DE2070B172459E4F1EE14BD2364E91F9E5@HQ-EXCH-5.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9Q9GS64001289 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 09:16:46 -0000 Status: RO Content-Length: 10913 Assuming that you always have connectivity on VLAN 1 is unrealistic. Different installation may use VLAN 1 for different purposes. Forbidding by standard to change this VLAN to another value is not going to work in products. Products will need to support the capability to change this value to meet customer needs. They will therefore invent proprietary mechanism to support a different value. Result: lack of interoperability. -- Silvano > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Thursday, October 25, 2007 10:20 AM > To: Radia Perlman; Silvano Gai > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > > Hi Radia, > > I am fairly comfortable with adopting the single > VLAN hello proposal and forcing that to be VLAN 1. > > I would rather not have to deal with the complexity > of making it configurable because even that can > be subject to misconfiguration and would have its > own set of issues, but I am also not totally > opposed to that if someone else feels strongly > about it. The main argument for doing that > would be point (b) in your message -- that > VLAN 1 was already being used for something > else and the operator didn't want to use it > for RBridge control traffic. > > As you point out, it looks like the proposal > for sending hellos on multiple VLANs would also > require additional scrutiny/specification before > it can be adopted. Unless shown to be absolutely > necessary, this approach imposes a significant > processing burden so I would rather see us > solve the problem with the hellos on VLAN 1 > only. > > Anoop > > > -----Original Message----- > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > Sent: Wednesday, October 24, 2007 2:42 PM > > To: Silvano Gai > > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN tags > > onRBridge-RBridgepackets? > > > > It's always hard to catch up on a thread after being away > > from email for a couple of days, but Silvano --- both the > > tone and (lack of) content of your message below makes it > > really difficult. > > > > In order to do quality engineering, we need to understand > > what all the tradeoffs are, and we have to be able to do > > discourse in an atmosphere of mutual respect. > > > > Saying something like "not doing it my way is 'too weak to be > > practical', or 'holds water like a pasta strainer' is not > > engineering. It is attempting to ridicule anyone who > > disagrees with you, and also is completely uninformative > > because you are not saying what the tradeoffs are, or even > > the details of how the thing you want would work. > > > > I am usually proud of this WG because we usually do explore > > all the options and what the tradoffs are without resorting > > to bullying and ridicule. Let's strive to do engineering that way. > > > > So let me demonstrate by getting back to the thread. > > > > I think the "downsides" of sending all RBridge-RBridge > > messages on a single unconfigurable VLAN (proposal being VLAN 1) are: > > a) if VLAN 1 is indeed partitioned, the RBridges will not > > know through IS-IS Hellos that they have RBridge neighbors, > > and multiple DRBs will be elected. But the proposal also > > includes how to prevent multiple DRB, namely by being > > conservative about forwarding data traffic to/from the link > > until we discover, though reporting the bridge root ID in > > LSPs, that it is safe to do so > > b) a customer might want to not use that VLAN for > > RBridge-RBridge traffic. However, if that customer felt so > > strongly about minimizing RBridge-Rbridge traffic, they could > > reconfigure use of the VLANs to move what they were using > > VLAN 1 to, to some other VLAN. So saying "just use 1" might > > inconvenience one customer who is already very savvy and > > likes to do really fancy configuration things, but does not > > prevent them from accomplishing all the exotic things they > > are trying to do -- just means some more configuration. And > > is saves what hopefully is the vast majority of customers > > from having to do any configuration whatsoever, and > > simplifies the spec and prevents misconfiguration. > > > > The upside of saying "just use 1" is extreme simplicity, and > > with the safeguards, will not have any higher probabilty of > > loops than already exists due to repeaters coming up, or > > bridge spanning tree messages getting lost. > > > > The next more complex proposal was to allow configuration to > > still ultimately use one VLAN per cloud, but allow it to be > > configurable to be something other than 1. I gave a proposal > > for doing that in a previous message (the DRB tells all the > > other RBridges what VLAN to use, while the DRB still sends on > > VLAN 1 in addition to the VLAN the DRB tells everyone to send > > one). I think the upside over the simplest "just use 1", is > > that it allows a customer that doesn't want RBridge-RBridge > > traffic being used on VLAN 1, or intentionally wants data > > traffic on VLAN 1 to be partitioned on a cloud, to move to a > > VLAN on that cloud that is OK not to be partitioned. The > > downside is that steady state the DRB will send one more > > Hello (on VLAN 1) than it would have, once the DRB tells all > > the other RBridges what VLAN to send on, and it is one more > > configuration thing to have to explain. And it seems likely > > that the DRB will be misconfigured and declare that RBridges > > will use VLAN k instead of 1, when some other RBridge on the > > cloud is not configured to support k. It won't be fatal > > (since that other RBridge will still hear the DRB on VLAN 1 > > and will also know about the other DRB through link state > > messages). My opinion is that this extra complexity over > > "just use 1" is not warranted given the small upside. > > > > If there is another proposal, say "send all Hellos on all > > VLANs", I claim that the details of that have never been > > specified well enough for that proposal to be evaluated. So > > if someone who advocates that can do that, staying technical, > > covering all details like whether in your IS-IS Hello you > > list all the VLAN tags you've heard Hellos from for each > > neighbor, and how you send a multicast data message when you > > have adjacencies with different VLAN tags for different > > subsets of neighbors, I'd like to hear it. > > > > And by all means, if I have missed some of the downsides on > > "just use VLAN 1", or "just use a single VLAN, but it can be > > configured to be something other than 1", then by all means > > add to the arguments. > > > > Radia > > > > > > > > > > Silvano Gai wrote: > > > I want to restate that IMHO a design that sends messages on > > a single > > > VLAN is so week to be completely useless. > > > > > > I met Anoop on a plane back from a T11 meeting and we discussed the > > > issue of sending messages on all the configured VLANs. > > Anoop pointed > > > out that, if these messages are ISIS messages, this can > > overload the > > > RBrige supervisor. > > > > > > We identified a possible solution based on two different > > message types: > > > - ISIS used on a single VLAN to compute adjacency > > > - simple per-VLAN checking on all the VLANs to verify reachability. > > > > > > The second kind of messages is much simpler and therefore they load > > > less the RBrige supervisor. In the future, per-VLAN checking can be > > > implemented by the port ASIC. This seems a viable solution that > > > requires design effort, but it is promising. > > > > > > Without the per-VLAN checking, running ISIS on a single VLAN holds > > > water like a pasta-strainer. > > > > > > -- Silvano > > > > > > > > > > > >> -----Original Message----- > > >> From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] > > >> > > > On > > > > > >> Behalf Of Anoop Ghanwani > > >> Sent: Monday, October 22, 2007 11:01 AM > > >> To: Radia Perlman; Developing a hybrid router/bridge. > > >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > >> RBridgepackets? > > >> > > >> > > >> If we want to make implementations work with only a single > > Hello for > > >> all VLANs than the option is (a). I think that is what it > > should be. > > >> Basically, as a part of RBridge configuration there should be a > > >> "RBridge Control VLAN" configuration that applies to the whole > > >> device. It should default to VLAN 1, but an operator can > > choose to > > >> change it. > > >> A RBridge only emits Hellos on that VLAN. If it receives > > Hellos on > > >> any other VLAN that should be detected as an error condition and > > >> reported. > > >> > > >> There have been some problem corner cases that have been > > pointed out > > >> previously on the list that may result in temporary duplication of > > >> traffic when there is misconfiguration. Those should be > > documented. > > >> > > >> Anoop > > >> > > >> > > >>> -----Original Message----- > > >>> From: rbridge-bounces@postel.org > > >>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > >>> Sent: Saturday, October 20, 2007 9:47 PM > > >>> To: Developing a hybrid router/bridge. > > >>> Subject: [rbridge] Final outcome of outer VLAN tags on > > >>> RBridge-RBridgepackets? > > >>> > > >>> I'm not sure I understood the final consensus on what we > > should do > > >>> for outer VLAN tags on inter-RBridge packets. > > >>> > > >>> The possibilities I think the consensus might have been are: > > >>> > > >>> a) only use VLAN 1, explicit tag, no configuration possible. > > >>> b) default is VLAN 1, explicit tag, configuration is possible to > > >>> change sending with VLAN tag(s) something other than 1. > > If this is > > >>> what was decided, I don't believe we've worked out the design > > >>> details. I'd assume this would mean RBridges should be willing to > > >>> receive packets from other RBridges regardless of outer VLAN tag. > > >>> Would we then mark in the Hellos what VLAN tag(s) you've > > heard from > > >>> what other RBridges with? What do we do with multicast if there > > >>> isn't a single VLAN tag that seems to work to send to everyone? > > >>> Would we allow configuration to send on a set of VLAN > > tags, or just > > >>> on one at a time (and we allow configuration to say which one it > > >>> is)? > > >>> > > >>> Certainly a) is simpler. If the consensus was b), we'd > > better work > > >>> out the details. > > >>> > > >>> Radia > > >>> _______________________________________________ > > >>> rbridge mailing list > > >>> rbridge@postel.org > > >>> http://mailman.postel.org/mailman/listinfo/rbridge > > >>> > > >>> > > >> _______________________________________________ > > >> rbridge mailing list > > >> rbridge@postel.org > > >> http://mailman.postel.org/mailman/listinfo/rbridge > > >> > > Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9Q5P7QR023040 for <rbridge@postel.org>; Thu, 25 Oct 2007 22:25:07 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQI000JN71UH000@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 22:25:06 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQI006BZ71QZIH0@mail.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 22:25:04 -0700 (PDT) Date: Thu, 25 Oct 2007 22:26:28 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Message-id: <47217A84.1040303@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4720E6A3.7010603@sun.com> <3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 05:25:38 -0000 Status: RO Content-Length: 7448 Right...I was not intending to preclude having R1 be DRB for (inner) VLANs (v1, v2, v3) and R2 be DRB for (inner) VLANs (v4, v5, v6). However, as you point out, if each RBridge can be configured with a different priority for each of the 4000 VLANs, the IS-IS Hello would get too large. The only reason for different priorities is to do some load splitting. I'd argue that with just a tiny bit of flexibility customers can get enough functionality. So I'd suggest limiting multiple priorities to some reasonable number, like 3, and sets of VLANs to ranges. That would mean that R1 can claim to have priority P1 for the VLANs in range (n1-n2), and priority P2 for the VLANs in range (n3-n4), and priority P3 for VLANs betwen (n5-n6). This would require (for 3 different priorities) 18 bytes in the Hello. For instance, "I have priority 7 for VLANs (1-50) and priority 12 for VLANs (61-80), and priority 2 for VLANs (101-115). Perhaps another 500 bytes to do a bit mask of all the VLANs that you support at all (or alternatively you can't claim to have a priority for a range of VLANs unless you support all the VLANs in that range). Likewise, in the pseudonode, we'd have to say the range of VLANs that that pseudonode refers to. And it's NOT a DRB collision if there is a pseudonode, say R1,17, for which R1 is DRB, reporting root bridge X and R2 is DRB on a link with root bridge X as long as the set of VLANs reported in R1.17's LSP does not overlap with the set of VLANs that R2 is DRB for on that link. And actually, R2 really only needs to decline to forward data (act as DRB) for the set of VLANs in R1.17's pseudonode that overlaps with R2's. It could be that R2 has some other VLANs that are not in R1.17's pseudonode. So that's an additional refinement on the rules that should be added. Perhaps we should start a different thread on whether people can live with having a single DRB be configured with at most 3 priorities on a port, and require the set of VLANs for each priority to be expressible in a range (rather than having to enumerate each of the VLAN tags individually). Radia Eastlake III Donald-LDE008 wrote: > Hi Radia, > > The proposal below appears to be written from the "one DRB per link" > point of view while the current draft claims to support "one DRB per > VLAN per link". Even if you have complete VLAN 1 connectivity and use > single Hellos, I'm not quite sure how the one DRB per VLAN per link > would work. In principle, the per VLAN priority for a Rbridge port for > all its configured VLANs might not fit into a Hello... > > Thanks, > Donald > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Thursday, October 25, 2007 2:56 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] A "multiple VLAN Hello" proposal > > It's a bit difficult to argue on the list about proposals when one of > them has not been specified, especially > since I can imagine lots of variations on multiple VLANs, and lots of > questions about choices for > the details. > > Here's an attempt to specify a "send Hellos on multiple VLANs" proposal. > > I've chosen details > where in many cases there are other options I could have chosen. But I > think we need some > tangible proposal with details worked out before advocating for it. > People should feel free > to suggest modifications to the details below, but I, as I said, cannot > argue between proposals > if the proposals aren't concrete. I've tried to make it as simple as > possible, as low overhead > as possible, while adding the ability to configure sending Hellos on > lots of VLANs. > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > b) In addition, RBridges MAY be configured to send and receive Hellos on > > some set of > VLANs in addition to 1 > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that > R1 is > configured to send (and receive) on. To clarify, as long as R1 thinks > itself is DRB, it will > send Hellos on the complete set of VLANs that R1 is configured to send > on. In addition (see > point "e"), R1 may wind up having to send Hellos on some set of VLANs in > > addition > to those it was configured to send on. > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has > heard Hellos from. In addition, > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears > > hellos from R2 on. > The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a > > Hello from R2 on. > > e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs, > but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the > set of VLANs that > R1 transmits on, as long as it continues to hear Hellos on VLAN x (and > no > other VLANs) from R2. Note that if R2's Hello gives R2 better priority > for > being DRB, then R1 will not be DRB any more, but MUST continue sending > Hellos on > VLAN x (even though x is not in the set of VLANs > that R1 was configured to send on) to ensure that R2 continues to send > its Hellos on VLAN x. > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN > that the DRB reports > that it has heard from you on. This cuts down on Hellos since it means > that non-DRB RBridges > will send on at most two VLANs. > {Note: An alternate option would have had every RBridge send Hellos > always on all VLANs they > have been configured to send on}. > > f) all RBridge-RBridge traffic (other than Hellos) is always sent on > VLAN 1. So if R2 cannot > reach the DRB via VLAN 1, then R2 cannot forward data to/from that > cloud, or receive > LSPs on that cloud. In other words, that link will be broken for R2. The > > purpose > of the Hellos is only to notice (through a means *in addition* to the > safeguards in the other > proposals) that R2 is not DRB for the link. > > g) We do the same safeguards as in the other proposals (report the > bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra > unless > you have all the relevant pseudonode LSPs attached to Ra to ensure that > none of them have > the same root RBridge, and that you delay before encapsulating data off > the link until you've > been DRB for enough time to synchronize LSP databases with your > neighbors) > > ************** > My thoughts on this: > > a) I assume the only reason to send Hellos on multiple VLANs is to > minimize the probability > of accidentally having two DRBs, and therefore loops. I'm not convinced > this adds safety > over the safeguards in the single VLAN proposals. > > b) this winds up with sending lots more Hellos, but does not create > additional pseudonodes, > or complicate data forwarding, because the Hellos is only to find > neighbors, not to repair > use of the link for forwarding data (or propagating LSPs) if VLAN 1 is > partitioned on the link > > c) This is a lot more complicated. It might seem simpler to not try to > optimize the number of > Hellos (like I did in point e), but there seem to be scary corner cases > where all the VLANs > common to R1 and R2 are partitioned. Saying there must be an > unpartitioned VLAN 1 seems > the safest. > > So, I still like the "just use VLAN 1" proposal. > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9Q59JfW019296 for <rbridge@postel.org>; Thu, 25 Oct 2007 22:09:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,331,1188802800"; d="scan'208";a="13461840" Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 25 Oct 2007 22:09:18 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 7E5A72383C8; Thu, 25 Oct 2007 22:09:18 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 22:04:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Oct 2007 22:03:51 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E91FC2E@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXOekHlzaYfsJDTd6jJjeAXr4vqQAUB4MgAADNlJA= References: <4720E6A3.7010603@sun.com> <3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 26 Oct 2007 05:04:19.0646 (UTC) FILETIME=[AA625DE0:01C8178D] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9Q59JfW019296 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 05:09:42 -0000 Status: RO Content-Length: 6256 Donald, Once you've established connectivity over VLAN 1, you can then exchange the list of VLANs that are configured on that RBridge port and arbitrate which RBridge becomes designated for each VLAN. For example, if RB1 has VLANs {2,4,6,8} and RB2 has VLANs {3,5,7,9} configured, then they will both become DRBs for those set of VLANs because there is no overlap. For the ones that there is overlap, there will need to be a tie breaking mechanism. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Thursday, October 25, 2007 9:43 PM > To: Radia Perlman > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] A "multiple VLAN Hello" proposal > > Hi Radia, > > The proposal below appears to be written from the "one DRB per link" > point of view while the current draft claims to support "one > DRB per VLAN per link". Even if you have complete VLAN 1 > connectivity and use single Hellos, I'm not quite sure how > the one DRB per VLAN per link would work. In principle, the > per VLAN priority for a Rbridge port for all its configured > VLANs might not fit into a Hello... > > Thanks, > Donald > > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 25, 2007 2:56 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] A "multiple VLAN Hello" proposal > > It's a bit difficult to argue on the list about proposals > when one of them has not been specified, especially since I > can imagine lots of variations on multiple VLANs, and lots of > questions about choices for the details. > > Here's an attempt to specify a "send Hellos on multiple > VLANs" proposal. > > I've chosen details > where in many cases there are other options I could have > chosen. But I think we need some tangible proposal with > details worked out before advocating for it. > People should feel free > to suggest modifications to the details below, but I, as I > said, cannot argue between proposals if the proposals aren't > concrete. I've tried to make it as simple as possible, as low > overhead as possible, while adding the ability to configure > sending Hellos on lots of VLANs. > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > b) In addition, RBridges MAY be configured to send and > receive Hellos on > > some set of > VLANs in addition to 1 > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the > VLANs that > R1 is > configured to send (and receive) on. To clarify, as long as > R1 thinks itself is DRB, it will send Hellos on the complete > set of VLANs that R1 is configured to send on. In addition > (see point "e"), R1 may wind up having to send Hellos on some > set of VLANs in > > addition > to those it was configured to send on. > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges > R1 has heard Hellos from. In addition, > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > that R1 hears > > hellos from R2 on. > The one VLAN that R1 reports is the lowest numbered VLAN that > R1 hears a > > Hello from R2 on. > > e) If R1 does not hear a Hello from R2 on any of R1's > configured VLANs, but does hear on some other VLAN, say VLAN > x, then R1 adds "x" to the set of VLANs that > R1 transmits on, as long as it continues to hear Hellos on > VLAN x (and no other VLANs) from R2. Note that if R2's Hello > gives R2 better priority for being DRB, then R1 will not be > DRB any more, but MUST continue sending Hellos on VLAN x > (even though x is not in the set of VLANs that R1 was > configured to send on) to ensure that R2 continues to send > its Hellos on VLAN x. > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > the VLAN that the DRB reports that it has heard from you on. > This cuts down on Hellos since it means that non-DRB RBridges > will send on at most two VLANs. > {Note: An alternate option would have had every RBridge send > Hellos always on all VLANs they have been configured to send on}. > > f) all RBridge-RBridge traffic (other than Hellos) is always > sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, > then R2 cannot forward data to/from that cloud, or receive > LSPs on that cloud. In other words, that link will be broken > for R2. The > > purpose > of the Hellos is only to notice (through a means *in > addition* to the safeguards in the other > proposals) that R2 is not DRB for the link. > > g) We do the same safeguards as in the other proposals > (report the bridge root ID in the pseudonode LSP, don't > decapsulate from ingress Ra unless you have all the relevant > pseudonode LSPs attached to Ra to ensure that none of them > have the same root RBridge, and that you delay before > encapsulating data off the link until you've been DRB for > enough time to synchronize LSP databases with your > neighbors) > > ************** > My thoughts on this: > > a) I assume the only reason to send Hellos on multiple VLANs > is to minimize the probability of accidentally having two > DRBs, and therefore loops. I'm not convinced this adds safety > over the safeguards in the single VLAN proposals. > > b) this winds up with sending lots more Hellos, but does not > create additional pseudonodes, or complicate data forwarding, > because the Hellos is only to find neighbors, not to repair > use of the link for forwarding data (or propagating LSPs) if > VLAN 1 is partitioned on the link > > c) This is a lot more complicated. It might seem simpler to > not try to optimize the number of Hellos (like I did in point > e), but there seem to be scary corner cases where all the > VLANs common to R1 and R2 are partitioned. Saying there must > be an unpartitioned VLAN 1 seems the safest. > > So, I still like the "just use VLAN 1" proposal. > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9Q4j7SS013131 for <rbridge@postel.org>; Thu, 25 Oct 2007 21:45:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1193373900!26574436!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29155 invoked from network); 26 Oct 2007 04:45:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 26 Oct 2007 04:45:00 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9Q4ioJH023461 for <rbridge@postel.org>; Thu, 25 Oct 2007 21:45:00 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l9Q4inNA022882 for <rbridge@postel.org>; Thu, 25 Oct 2007 23:44:50 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9Q4inqU022870 for <rbridge@postel.org>; Thu, 25 Oct 2007 23:44:49 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 26 Oct 2007 00:43:01 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6BE0@de01exm64.ds.mot.com> In-Reply-To: <4720E6A3.7010603@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXOekHlzaYfsJDTd6jJjeAXr4vqQAUB4Mg References: <4720E6A3.7010603@sun.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9Q4j7SS013131 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 04:45:37 -0000 Status: RO Content-Length: 5033 Hi Radia, The proposal below appears to be written from the "one DRB per link" point of view while the current draft claims to support "one DRB per VLAN per link". Even if you have complete VLAN 1 connectivity and use single Hellos, I'm not quite sure how the one DRB per VLAN per link would work. In principle, the per VLAN priority for a Rbridge port for all its configured VLANs might not fit into a Hello... Thanks, Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Thursday, October 25, 2007 2:56 PM To: Developing a hybrid router/bridge. Subject: [rbridge] A "multiple VLAN Hello" proposal It's a bit difficult to argue on the list about proposals when one of them has not been specified, especially since I can imagine lots of variations on multiple VLANs, and lots of questions about choices for the details. Here's an attempt to specify a "send Hellos on multiple VLANs" proposal. I've chosen details where in many cases there are other options I could have chosen. But I think we need some tangible proposal with details worked out before advocating for it. People should feel free to suggest modifications to the details below, but I, as I said, cannot argue between proposals if the proposals aren't concrete. I've tried to make it as simple as possible, as low overhead as possible, while adding the ability to configure sending Hellos on lots of VLANs. a) RBridges send and receive IS-IS Hellos on VLAN 1 b) In addition, RBridges MAY be configured to send and receive Hellos on some set of VLANs in addition to 1 c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that R1 is configured to send (and receive) on. To clarify, as long as R1 thinks itself is DRB, it will send Hellos on the complete set of VLANs that R1 is configured to send on. In addition (see point "e"), R1 may wind up having to send Hellos on some set of VLANs in addition to those it was configured to send on. d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has heard Hellos from. In addition, R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears hellos from R2 on. The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a Hello from R2 on. e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs, but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the set of VLANs that R1 transmits on, as long as it continues to hear Hellos on VLAN x (and no other VLANs) from R2. Note that if R2's Hello gives R2 better priority for being DRB, then R1 will not be DRB any more, but MUST continue sending Hellos on VLAN x (even though x is not in the set of VLANs that R1 was configured to send on) to ensure that R2 continues to send its Hellos on VLAN x. e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN that the DRB reports that it has heard from you on. This cuts down on Hellos since it means that non-DRB RBridges will send on at most two VLANs. {Note: An alternate option would have had every RBridge send Hellos always on all VLANs they have been configured to send on}. f) all RBridge-RBridge traffic (other than Hellos) is always sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, then R2 cannot forward data to/from that cloud, or receive LSPs on that cloud. In other words, that link will be broken for R2. The purpose of the Hellos is only to notice (through a means *in addition* to the safeguards in the other proposals) that R2 is not DRB for the link. g) We do the same safeguards as in the other proposals (report the bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra unless you have all the relevant pseudonode LSPs attached to Ra to ensure that none of them have the same root RBridge, and that you delay before encapsulating data off the link until you've been DRB for enough time to synchronize LSP databases with your neighbors) ************** My thoughts on this: a) I assume the only reason to send Hellos on multiple VLANs is to minimize the probability of accidentally having two DRBs, and therefore loops. I'm not convinced this adds safety over the safeguards in the single VLAN proposals. b) this winds up with sending lots more Hellos, but does not create additional pseudonodes, or complicate data forwarding, because the Hellos is only to find neighbors, not to repair use of the link for forwarding data (or propagating LSPs) if VLAN 1 is partitioned on the link c) This is a lot more complicated. It might seem simpler to not try to optimize the number of Hellos (like I did in point e), but there seem to be scary corner cases where all the VLANs common to R1 and R2 are partitioned. Saying there must be an unpartitioned VLAN 1 seems the safest. So, I still like the "just use VLAN 1" proposal. _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9Q4j5oJ013113 for <rbridge@postel.org>; Thu, 25 Oct 2007 21:45:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1193373900!6669480!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14902 invoked from network); 26 Oct 2007 04:45:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 26 Oct 2007 04:45:00 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9Q4iobX023459 for <rbridge@postel.org>; Thu, 25 Oct 2007 21:45:00 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l9Q4inmO022878 for <rbridge@postel.org>; Thu, 25 Oct 2007 23:44:49 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9Q4inqS022870 for <rbridge@postel.org>; Thu, 25 Oct 2007 23:44:49 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 26 Oct 2007 00:44:48 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6BDF@de01exm64.ds.mot.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E91FB0D@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXOlfU4OOzyiioQ8GJPRkktrzbhAAFLipgAA2yR8A= References: <4720E6A3.7010603@sun.com> <4C94DE2070B172459E4F1EE14BD2364E91FB0D@HQ-EXCH-5.corp.brocade.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Anoop Ghanwani" <anoop@brocade.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9Q4j5oJ013113 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 04:45:37 -0000 Status: RO Content-Length: 5993 Hi Anoop, I don't look at it that way at all. We get to say what "correct" and "incorrect" behavior are for Rbridges. TRILL Ethertype frames are special. The Outer VLAN tag on a TRILL Ethertype frame is just a transport artifact added to enable the frame to get through a Bridged LAN that is in the way. It is unnecessary on point-to-point links. If an Outer VLAN tag is present on a TRILL frame, it shouldn't affect whether the frame is processed. Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Anoop Ghanwani Sent: Thursday, October 25, 2007 5:39 PM To: Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] A "multiple VLAN Hello" proposal Radia, Step "e" would be considered incorrect behavior w.r.t. VLANs. If an end station is not configured with a certain VLAN, it should not be receiving and trying to process packets from that VLAN. In this case, the end station is the management port running IS-IS. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 25, 2007 11:56 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] A "multiple VLAN Hello" proposal > > It's a bit difficult to argue on the list about proposals > when one of them has not been specified, especially since I > can imagine lots of variations on multiple VLANs, and lots of > questions about choices for the details. > > Here's an attempt to specify a "send Hellos on multiple > VLANs" proposal. > I've chosen details > where in many cases there are other options I could have > chosen. But I think we need some tangible proposal with > details worked out before advocating for it. > People should feel free > to suggest modifications to the details below, but I, as I > said, cannot argue between proposals if the proposals aren't > concrete. I've tried to make it as simple as possible, as low > overhead as possible, while adding the ability to configure > sending Hellos on lots of VLANs. > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > b) In addition, RBridges MAY be configured to send and > receive Hellos on some set of VLANs in addition to 1 > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the > VLANs that > R1 is > configured to send (and receive) on. To clarify, as long as > R1 thinks itself is DRB, it will send Hellos on the complete > set of VLANs that R1 is configured to send on. In addition > (see point "e"), R1 may wind up having to send Hellos on some > set of VLANs in addition to those it was configured to send on. > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges > R1 has heard Hellos from. In addition, > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > that R1 hears hellos from R2 on. > The one VLAN that R1 reports is the lowest numbered VLAN that > R1 hears a Hello from R2 on. > > e) If R1 does not hear a Hello from R2 on any of R1's > configured VLANs, but does hear on some other VLAN, say VLAN > x, then R1 adds "x" to the set of VLANs that > R1 transmits on, as long as it continues to hear Hellos on > VLAN x (and no other VLANs) from R2. Note that if R2's Hello > gives R2 better priority for being DRB, then R1 will not be > DRB any more, but MUST continue sending Hellos on VLAN x > (even though x is not in the set of VLANs that R1 was > configured to send on) to ensure that R2 continues to send > its Hellos on VLAN x. > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > the VLAN that the DRB reports that it has heard from you on. > This cuts down on Hellos since it means that non-DRB RBridges > will send on at most two VLANs. > {Note: An alternate option would have had every RBridge send > Hellos always on all VLANs they have been configured to send on}. > > f) all RBridge-RBridge traffic (other than Hellos) is always > sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, > then R2 cannot forward data to/from that cloud, or receive > LSPs on that cloud. In other words, that link will be broken > for R2. The purpose of the Hellos is only to notice (through > a means *in addition* to the safeguards in the other > proposals) that R2 is not DRB for the link. > > g) We do the same safeguards as in the other proposals > (report the bridge root ID in the pseudonode LSP, don't > decapsulate from ingress Ra unless you have all the relevant > pseudonode LSPs attached to Ra to ensure that none of them > have the same root RBridge, and that you delay before > encapsulating data off the link until you've been DRB for > enough time to synchronize LSP databases with your neighbors) > > ************** > My thoughts on this: > > a) I assume the only reason to send Hellos on multiple VLANs > is to minimize the probability of accidentally having two > DRBs, and therefore loops. I'm not convinced this adds safety > over the safeguards in the single VLAN proposals. > > b) this winds up with sending lots more Hellos, but does not > create additional pseudonodes, or complicate data forwarding, > because the Hellos is only to find neighbors, not to repair > use of the link for forwarding data (or propagating LSPs) if > VLAN 1 is partitioned on the link > > c) This is a lot more complicated. It might seem simpler to > not try to optimize the number of Hellos (like I did in point > e), but there seem to be scary corner cases where all the > VLANs common to R1 and R2 are partitioned. Saying there must > be an unpartitioned VLAN 1 seems the safest. > > So, I still like the "just use VLAN 1" proposal. > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9Q2jfvh010448 for <rbridge@postel.org>; Thu, 25 Oct 2007 19:45:41 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQH000GSZO1H000@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 19:45:37 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQH006YMZO0ZKG0@mail.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 19:45:37 -0700 (PDT) Date: Thu, 25 Oct 2007 19:47:03 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4C94DE2070B172459E4F1EE14BD2364E91FB0D@HQ-EXCH-5.corp.brocade.com> To: Anoop Ghanwani <anoop@brocade.com> Message-id: <47215527.4070501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4720E6A3.7010603@sun.com> <4C94DE2070B172459E4F1EE14BD2364E91FB0D@HQ-EXCH-5.corp.brocade.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2007 02:46:12 -0000 Status: RO Content-Length: 5879 Hmm. I was wondering if an RBridge might be able to receive on a VLAN that it isn't configured to officially support. But actually, what I meant was that I was assuming there might be a large subset of VLANs that the RBridge can send and receive on. and some smaller subset of those that it is configured to send IS-IS Hellos on. So if an RBridge does support all 4000 VLANs, by default it would only send IS-IS Hellos on VLAN 1, but would receive on any of them. And it might be configured to send on a subset of the supported VLANs, but hopefully not all 4000. So that's what I was trying to get at. Radia Anoop Ghanwani wrote: > Radia, > > Step "e" would be considered incorrect behavior > w.r.t. VLANs. If an end station is not configured > with a certain VLAN, it should not be receiving and > trying to process packets from that VLAN. In this > case, the end station is the management port running > IS-IS. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >> Sent: Thursday, October 25, 2007 11:56 AM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] A "multiple VLAN Hello" proposal >> >> It's a bit difficult to argue on the list about proposals >> when one of them has not been specified, especially since I >> can imagine lots of variations on multiple VLANs, and lots of >> questions about choices for the details. >> >> Here's an attempt to specify a "send Hellos on multiple >> VLANs" proposal. >> I've chosen details >> where in many cases there are other options I could have >> chosen. But I think we need some tangible proposal with >> details worked out before advocating for it. >> People should feel free >> to suggest modifications to the details below, but I, as I >> said, cannot argue between proposals if the proposals aren't >> concrete. I've tried to make it as simple as possible, as low >> overhead as possible, while adding the ability to configure >> sending Hellos on lots of VLANs. >> >> >> a) RBridges send and receive IS-IS Hellos on VLAN 1 >> >> b) In addition, RBridges MAY be configured to send and >> receive Hellos on some set of VLANs in addition to 1 >> >> c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the >> VLANs that >> R1 is >> configured to send (and receive) on. To clarify, as long as >> R1 thinks itself is DRB, it will send Hellos on the complete >> set of VLANs that R1 is configured to send on. In addition >> (see point "e"), R1 may wind up having to send Hellos on some >> set of VLANs in addition to those it was configured to send on. >> >> d) In IS-IS's Hello, R1 reports the set of neighbor RBridges >> R1 has heard Hellos from. In addition, >> R1 reports in R1's Hello, for each neighbor R2, *one* VLAN >> that R1 hears hellos from R2 on. >> The one VLAN that R1 reports is the lowest numbered VLAN that >> R1 hears a Hello from R2 on. >> >> e) If R1 does not hear a Hello from R2 on any of R1's >> configured VLANs, but does hear on some other VLAN, say VLAN >> x, then R1 adds "x" to the set of VLANs that >> R1 transmits on, as long as it continues to hear Hellos on >> VLAN x (and no other VLANs) from R2. Note that if R2's Hello >> gives R2 better priority for being DRB, then R1 will not be >> DRB any more, but MUST continue sending Hellos on VLAN x >> (even though x is not in the set of VLANs that R1 was >> configured to send on) to ensure that R2 continues to send >> its Hellos on VLAN x. >> >> e) if you are *not* the DRB, you send Hellos on VLAN 1 plus >> the VLAN that the DRB reports that it has heard from you on. >> This cuts down on Hellos since it means that non-DRB RBridges >> will send on at most two VLANs. >> {Note: An alternate option would have had every RBridge send >> Hellos always on all VLANs they have been configured to send on}. >> >> f) all RBridge-RBridge traffic (other than Hellos) is always >> sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, >> then R2 cannot forward data to/from that cloud, or receive >> LSPs on that cloud. In other words, that link will be broken >> for R2. The purpose of the Hellos is only to notice (through >> a means *in addition* to the safeguards in the other >> proposals) that R2 is not DRB for the link. >> >> g) We do the same safeguards as in the other proposals >> (report the bridge root ID in the pseudonode LSP, don't >> decapsulate from ingress Ra unless you have all the relevant >> pseudonode LSPs attached to Ra to ensure that none of them >> have the same root RBridge, and that you delay before >> encapsulating data off the link until you've been DRB for >> enough time to synchronize LSP databases with your neighbors) >> >> ************** >> My thoughts on this: >> >> a) I assume the only reason to send Hellos on multiple VLANs >> is to minimize the probability of accidentally having two >> DRBs, and therefore loops. I'm not convinced this adds safety >> over the safeguards in the single VLAN proposals. >> >> b) this winds up with sending lots more Hellos, but does not >> create additional pseudonodes, or complicate data forwarding, >> because the Hellos is only to find neighbors, not to repair >> use of the link for forwarding data (or propagating LSPs) if >> VLAN 1 is partitioned on the link >> >> c) This is a lot more complicated. It might seem simpler to >> not try to optimize the number of Hellos (like I did in point >> e), but there seem to be scary corner cases where all the >> VLANs common to R1 and R2 are partitioned. Saying there must >> be an unpartitioned VLAN 1 seems the safest. >> >> So, I still like the "just use VLAN 1" proposal. >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9PLdPec007822 for <rbridge@postel.org>; Thu, 25 Oct 2007 14:39:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,330,1188802800"; d="scan'208";a="20551818" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 25 Oct 2007 14:39:14 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id D89932383B5; Thu, 25 Oct 2007 14:39:14 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 14:39:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Oct 2007 14:38:57 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E91FB0D@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <4720E6A3.7010603@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A "multiple VLAN Hello" proposal Thread-Index: AcgXOlfU4OOzyiioQ8GJPRkktrzbhAAFLipg References: <4720E6A3.7010603@sun.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 25 Oct 2007 21:39:14.0824 (UTC) FILETIME=[7D11E880:01C8174F] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9PLdPec007822 Subject: Re: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 25 Oct 2007 21:40:00 -0000 Status: RO Content-Length: 5118 Radia, Step "e" would be considered incorrect behavior w.r.t. VLANs. If an end station is not configured with a certain VLAN, it should not be receiving and trying to process packets from that VLAN. In this case, the end station is the management port running IS-IS. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 25, 2007 11:56 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] A "multiple VLAN Hello" proposal > > It's a bit difficult to argue on the list about proposals > when one of them has not been specified, especially since I > can imagine lots of variations on multiple VLANs, and lots of > questions about choices for the details. > > Here's an attempt to specify a "send Hellos on multiple > VLANs" proposal. > I've chosen details > where in many cases there are other options I could have > chosen. But I think we need some tangible proposal with > details worked out before advocating for it. > People should feel free > to suggest modifications to the details below, but I, as I > said, cannot argue between proposals if the proposals aren't > concrete. I've tried to make it as simple as possible, as low > overhead as possible, while adding the ability to configure > sending Hellos on lots of VLANs. > > > a) RBridges send and receive IS-IS Hellos on VLAN 1 > > b) In addition, RBridges MAY be configured to send and > receive Hellos on some set of VLANs in addition to 1 > > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the > VLANs that > R1 is > configured to send (and receive) on. To clarify, as long as > R1 thinks itself is DRB, it will send Hellos on the complete > set of VLANs that R1 is configured to send on. In addition > (see point "e"), R1 may wind up having to send Hellos on some > set of VLANs in addition to those it was configured to send on. > > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges > R1 has heard Hellos from. In addition, > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN > that R1 hears hellos from R2 on. > The one VLAN that R1 reports is the lowest numbered VLAN that > R1 hears a Hello from R2 on. > > e) If R1 does not hear a Hello from R2 on any of R1's > configured VLANs, but does hear on some other VLAN, say VLAN > x, then R1 adds "x" to the set of VLANs that > R1 transmits on, as long as it continues to hear Hellos on > VLAN x (and no other VLANs) from R2. Note that if R2's Hello > gives R2 better priority for being DRB, then R1 will not be > DRB any more, but MUST continue sending Hellos on VLAN x > (even though x is not in the set of VLANs that R1 was > configured to send on) to ensure that R2 continues to send > its Hellos on VLAN x. > > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus > the VLAN that the DRB reports that it has heard from you on. > This cuts down on Hellos since it means that non-DRB RBridges > will send on at most two VLANs. > {Note: An alternate option would have had every RBridge send > Hellos always on all VLANs they have been configured to send on}. > > f) all RBridge-RBridge traffic (other than Hellos) is always > sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, > then R2 cannot forward data to/from that cloud, or receive > LSPs on that cloud. In other words, that link will be broken > for R2. The purpose of the Hellos is only to notice (through > a means *in addition* to the safeguards in the other > proposals) that R2 is not DRB for the link. > > g) We do the same safeguards as in the other proposals > (report the bridge root ID in the pseudonode LSP, don't > decapsulate from ingress Ra unless you have all the relevant > pseudonode LSPs attached to Ra to ensure that none of them > have the same root RBridge, and that you delay before > encapsulating data off the link until you've been DRB for > enough time to synchronize LSP databases with your neighbors) > > ************** > My thoughts on this: > > a) I assume the only reason to send Hellos on multiple VLANs > is to minimize the probability of accidentally having two > DRBs, and therefore loops. I'm not convinced this adds safety > over the safeguards in the single VLAN proposals. > > b) this winds up with sending lots more Hellos, but does not > create additional pseudonodes, or complicate data forwarding, > because the Hellos is only to find neighbors, not to repair > use of the link for forwarding data (or propagating LSPs) if > VLAN 1 is partitioned on the link > > c) This is a lot more complicated. It might seem simpler to > not try to optimize the number of Hellos (like I did in point > e), but there seem to be scary corner cases where all the > VLANs common to R1 and R2 are partitioned. Saying there must > be an unpartitioned VLAN 1 seems the safest. > > So, I still like the "just use VLAN 1" proposal. > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9PIs5MW011829 for <rbridge@postel.org>; Thu, 25 Oct 2007 11:54:05 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQH00LABDU5B310@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 11:54:05 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQH0066RDU4ZHH0@mail.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 11:54:05 -0700 (PDT) Date: Thu, 25 Oct 2007 11:55:31 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <4720E6A3.7010603@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] A "multiple VLAN Hello" proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 25 Oct 2007 18:54:27 -0000 Status: RO Content-Length: 4207 It's a bit difficult to argue on the list about proposals when one of them has not been specified, especially since I can imagine lots of variations on multiple VLANs, and lots of questions about choices for the details. Here's an attempt to specify a "send Hellos on multiple VLANs" proposal. I've chosen details where in many cases there are other options I could have chosen. But I think we need some tangible proposal with details worked out before advocating for it. People should feel free to suggest modifications to the details below, but I, as I said, cannot argue between proposals if the proposals aren't concrete. I've tried to make it as simple as possible, as low overhead as possible, while adding the ability to configure sending Hellos on lots of VLANs. a) RBridges send and receive IS-IS Hellos on VLAN 1 b) In addition, RBridges MAY be configured to send and receive Hellos on some set of VLANs in addition to 1 c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the VLANs that R1 is configured to send (and receive) on. To clarify, as long as R1 thinks itself is DRB, it will send Hellos on the complete set of VLANs that R1 is configured to send on. In addition (see point "e"), R1 may wind up having to send Hellos on some set of VLANs in addition to those it was configured to send on. d) In IS-IS's Hello, R1 reports the set of neighbor RBridges R1 has heard Hellos from. In addition, R1 reports in R1's Hello, for each neighbor R2, *one* VLAN that R1 hears hellos from R2 on. The one VLAN that R1 reports is the lowest numbered VLAN that R1 hears a Hello from R2 on. e) If R1 does not hear a Hello from R2 on any of R1's configured VLANs, but does hear on some other VLAN, say VLAN x, then R1 adds "x" to the set of VLANs that R1 transmits on, as long as it continues to hear Hellos on VLAN x (and no other VLANs) from R2. Note that if R2's Hello gives R2 better priority for being DRB, then R1 will not be DRB any more, but MUST continue sending Hellos on VLAN x (even though x is not in the set of VLANs that R1 was configured to send on) to ensure that R2 continues to send its Hellos on VLAN x. e) if you are *not* the DRB, you send Hellos on VLAN 1 plus the VLAN that the DRB reports that it has heard from you on. This cuts down on Hellos since it means that non-DRB RBridges will send on at most two VLANs. {Note: An alternate option would have had every RBridge send Hellos always on all VLANs they have been configured to send on}. f) all RBridge-RBridge traffic (other than Hellos) is always sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, then R2 cannot forward data to/from that cloud, or receive LSPs on that cloud. In other words, that link will be broken for R2. The purpose of the Hellos is only to notice (through a means *in addition* to the safeguards in the other proposals) that R2 is not DRB for the link. g) We do the same safeguards as in the other proposals (report the bridge root ID in the pseudonode LSP, don't decapsulate from ingress Ra unless you have all the relevant pseudonode LSPs attached to Ra to ensure that none of them have the same root RBridge, and that you delay before encapsulating data off the link until you've been DRB for enough time to synchronize LSP databases with your neighbors) ************** My thoughts on this: a) I assume the only reason to send Hellos on multiple VLANs is to minimize the probability of accidentally having two DRBs, and therefore loops. I'm not convinced this adds safety over the safeguards in the single VLAN proposals. b) this winds up with sending lots more Hellos, but does not create additional pseudonodes, or complicate data forwarding, because the Hellos is only to find neighbors, not to repair use of the link for forwarding data (or propagating LSPs) if VLAN 1 is partitioned on the link c) This is a lot more complicated. It might seem simpler to not try to optimize the number of Hellos (like I did in point e), but there seem to be scary corner cases where all the VLANs common to R1 and R2 are partitioned. Saying there must be an unpartitioned VLAN 1 seems the safest. So, I still like the "just use VLAN 1" proposal. Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9PI5wOl023793 for <rbridge@postel.org>; Thu, 25 Oct 2007 11:05:58 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQH00L5YBLOB310@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 11:05:48 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQH0062KBLNZ0H0@mail.sunlabs.com> for rbridge@postel.org; Thu, 25 Oct 2007 11:05:48 -0700 (PDT) Date: Thu, 25 Oct 2007 11:07:14 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <34BDD2A93E5FD84594BB230DD6C18EA20252A299@nuova-ex1.hq.nuovaimpresa.com> To: Silvano Gai <sgai@nuovasystems.com> Message-id: <4720DB52.7060305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <471FBC2E.5080705@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA20252A299@nuova-ex1.hq.nuovaimpresa.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 25 Oct 2007 18:07:00 -0000 Status: RO Content-Length: 13277 We should definitely arrange a phone call when you get back, though I've heard a rumor there are phones in Italy. :-) I do not understand most of what you said below. a) unmodified IS-IS: I fail to see why sending IS-IS Hellos on more VLANs is "less of a change" to IS-IS. I'm guessing, but perhaps you are suggesting that if we send Hellos on all the VLANs then we don't need to report the bridge root ID in the LSP or do the other safeguards (e.g., not decapsulating from ingress R1 unless you have checked all the pseudonodes that R1 is attached to to ensure R1 isn't reporting the same root bridge ID). I believe these safeguards are not complex or expensive and should be done no matter how many VLANs we send Hellos on. b) robustness: I believe that the single VLAN proposal *is* robust. Furthermore, I believe that if there is a cloud with lots of RBridges configured for sending and receiving on different subsets of VLANs, there is more likelihood of problems, especially if the "multiple VLAN proposal" (details still to be specified) does *not* include the root bridge ID in LSPs and the other safeguards. c) interoperability goal: I believe making fewer things configurable is the greatest way of enhancing interoperability That said....I was trying to imagine what a "send on multiple VLANs" proposal could possibly be. TRILL never worked it out -- my fault to a large extent since I hadn't been following the kinds of configuration that have been added to bridges that encourage partitioned VLANs on a cloud. Thank you, Anoop, for noticing. I think what we'd been assuming was that you'd form adjacencies based on VLAN tag, and R1 and R2 might talk with VLAN A, and R2 and R3 might talk with VLAN B, etc., on the same cloud. This not only multiplies the number of pseudonodes, but as Don pointed out, doesn't work with forwarding multicast data. So, I'll write a separate note with a proposal for multiple VLANs that might be palatable. Radia Silvano Gai wrote: > Radia, > > I am currently in Italy with limited connectivity. I'll write you a more > complete reply next week. > > I have also the additional issue that I find hard to discuss these > topics by email. I prefer face-to-face meeting in front of a whiteboard. > > Anyhow, let me try > > I think that the root of the disagreement is in the priority of the > requirements. > > For me and others robustness and interoperability are paramount, because > we look at TRILL in the Enterprise/Datacenter where there is no margin > for errors, even in the presence of misconfigurations. Moreover we want > to use ISIS unmodified with just few TLV added. If the price to pay for > this solution is to use a "robust" CPU for the RBridge supervisor, we > are happy to pay the price. Dinesh will present at the next IETF > robustness and interoperability issues. > > For Anoop, loading the supervisor switch as little as possible is > paramount. He seems to look more at green field installation, where > interoperability and robustness to misconfiguration are somehow > important, but not paramount. > > This difference in requirements causes differences in the preferred > solution: > - I prefer to use the standard ISIS with Hellos on all VLANs for > discovery and LSP only on one VLAN. > - Anoop prefers to not send the Hellos on all VLANs for discovery and he > is willing to follow your lead to somehow modifying ISIS, adding > additional steps to check Spanning tree roots, synchronize LSP > databases, etc. > > When you have done all the changes that you propose to ISIS, I am not > sure that we are using "an existing routing protocol" (as per TRILL > charter), I think we have designed something new. > > Summarizing my goals are: > - Robustness > - Interoperability > - Unmodified ISIS (e.g. no synchronization steps) > > My solution is to use what ISIS provides, i.e. > - Hellos on all configured VLANs for discovery and LSP only on one VLAN. > > > -- Silvano > > > >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman@sun.com] >> Sent: Wednesday, October 24, 2007 2:42 PM >> To: Silvano Gai >> Cc: Anoop Ghanwani; Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- >> RBridgepackets? >> >> It's always hard to catch up on a thread after being away from email >> > for > >> a couple of days, but >> Silvano --- both the tone and (lack of) content of your message below >> makes it really difficult. >> >> In order to do quality engineering, we need to understand what all the >> tradeoffs are, and we >> have to be able to do discourse in an atmosphere of mutual respect. >> >> Saying something like "not doing it my way is 'too weak to be >> practical', or 'holds water like >> a pasta strainer' is not engineering. It is attempting to ridicule >> anyone who disagrees with you, >> and also is completely uninformative because you are not saying what >> > the > >> tradeoffs are, or >> even the details of how the thing you want would work. >> >> I am usually proud of this WG because we usually do explore all the >> options and what the >> tradoffs are without resorting to bullying and ridicule. Let's strive >> > to > >> do engineering that way. >> >> So let me demonstrate by getting back to the thread. >> >> I think the "downsides" of sending all RBridge-RBridge messages on a >> single unconfigurable >> VLAN (proposal being VLAN 1) are: >> a) if VLAN 1 is indeed partitioned, the RBridges will not know through >> IS-IS Hellos that they have RBridge neighbors, and >> multiple DRBs will be elected. But the proposal also includes how >> to prevent multiple DRB, namely by being conservative about forwarding >> data traffic to/from the link until we discover, though reporting the >> bridge root ID in LSPs, >> that it is safe to do so >> b) a customer might want to not use that VLAN for RBridge-RBridge >> traffic. However, >> if that customer felt so strongly about minimizing RBridge-Rbridge >> traffic, they could reconfigure use of the VLANs to move what they >> > were > >> using VLAN 1 >> to, to some other VLAN. So saying "just use 1" might inconvenience one >> customer who is >> already very savvy and likes to do really fancy configuration things, >> but does not >> prevent them from accomplishing all the exotic things they are trying >> > to > >> do -- just means >> some more configuration. And is saves what hopefully is the vast >> majority of customers from >> having to do any configuration whatsoever, and simplifies the spec and >> prevents misconfiguration. >> >> The upside of saying "just use 1" is extreme simplicity, and with the >> safeguards, will not have >> any higher probabilty of loops than already exists due to repeaters >> coming up, or bridge >> spanning tree messages getting lost. >> >> The next more complex proposal was to allow configuration to still >> ultimately use one VLAN per >> cloud, but allow it to be configurable to be something other than 1. I >> gave a proposal for >> doing that in a previous message (the DRB tells all the other >> RBridges what VLAN to use, while the DRB still sends on VLAN 1 in >> > addition > >> to the VLAN the DRB tells everyone to send one). I think the upside >> > over > >> the simplest "just use 1", is >> that it allows a customer that doesn't want RBridge-RBridge traffic >> being used on VLAN 1, >> or intentionally wants data traffic on VLAN 1 to be partitioned on a >> cloud, to move to >> a VLAN on that cloud that is OK not to be partitioned. The downside is >> that steady state >> the DRB will send one more Hello (on VLAN 1) than it would have, once >> the DRB tells >> all the other RBridges what VLAN to send on, and it is one more >> configuration thing to >> have to explain. And it seems likely that the DRB will be >> > misconfigured > >> and declare that >> RBridges will use VLAN k instead of 1, when some other RBridge on the >> cloud is not >> configured to support k. It won't be fatal (since that other RBridge >> will still hear the DRB >> on VLAN 1 and will also know about the other DRB through link state >> messages). My opinion >> is that this extra complexity over "just use 1" is not warranted given >> the small upside. >> >> If there is another proposal, say "send all Hellos on all VLANs", I >> claim that the details of >> that have never been specified well enough for that proposal to be >> evaluated. So if someone >> who advocates that can do that, staying technical, covering all >> > details > >> like whether in your >> IS-IS Hello you list all the VLAN tags you've heard Hellos from for >> > each > >> neighbor, and >> how you send a multicast data message when you have adjacencies with >> different VLAN tags >> for different subsets of neighbors, I'd like to hear it. >> >> And by all means, if I have missed some of the downsides on "just use >> VLAN 1", or >> "just use a single VLAN, but it can be configured to be something >> > other > >> than 1", then >> by all means add to the arguments. >> >> Radia >> >> >> >> >> Silvano Gai wrote: >> >>> I want to restate that IMHO a design that sends messages on a single >>> VLAN is so week to be completely useless. >>> >>> I met Anoop on a plane back from a T11 meeting and we discussed the >>> issue of sending messages on all the configured VLANs. Anoop pointed >>> > out > >>> that, if these messages are ISIS messages, this can overload the >>> > RBrige > >>> supervisor. >>> >>> We identified a possible solution based on two different message >>> > types: > >>> - ISIS used on a single VLAN to compute adjacency >>> - simple per-VLAN checking on all the VLANs to verify reachability. >>> >>> The second kind of messages is much simpler and therefore they load >>> > less > >>> the RBrige supervisor. In the future, per-VLAN checking can be >>> implemented by the port ASIC. This seems a viable solution that >>> > requires > >>> design effort, but it is promising. >>> >>> Without the per-VLAN checking, running ISIS on a single VLAN holds >>> > water > >>> like a pasta-strainer. >>> >>> -- Silvano >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org >>>> > [mailto:rbridge-bounces@postel.org] > >>> On >>> >>> >>>> Behalf Of Anoop Ghanwani >>>> Sent: Monday, October 22, 2007 11:01 AM >>>> To: Radia Perlman; Developing a hybrid router/bridge. >>>> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- >>>> RBridgepackets? >>>> >>>> >>>> If we want to make implementations work with >>>> only a single Hello for all VLANs than the >>>> option is (a). I think that is what it should be. >>>> Basically, as a part of RBridge configuration >>>> there should be a "RBridge Control VLAN" configuration >>>> that applies to the whole device. It should default >>>> to VLAN 1, but an operator can choose to change it. >>>> A RBridge only emits Hellos on that VLAN. If it >>>> receives Hellos on any other VLAN that should >>>> be detected as an error condition and reported. >>>> >>>> There have been some problem corner cases that >>>> have been pointed out previously on the list >>>> that may result in temporary duplication of >>>> traffic when there is misconfiguration. Those >>>> should be documented. >>>> >>>> Anoop >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces@postel.org >>>>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >>>>> Sent: Saturday, October 20, 2007 9:47 PM >>>>> To: Developing a hybrid router/bridge. >>>>> Subject: [rbridge] Final outcome of outer VLAN tags on >>>>> RBridge-RBridgepackets? >>>>> >>>>> I'm not sure I understood the final consensus on what we >>>>> should do for outer VLAN tags on inter-RBridge packets. >>>>> >>>>> The possibilities I think the consensus might have been are: >>>>> >>>>> a) only use VLAN 1, explicit tag, no configuration possible. >>>>> b) default is VLAN 1, explicit tag, configuration is possible >>>>> to change sending with VLAN tag(s) something other than 1. If >>>>> this is what was decided, I don't believe we've worked out >>>>> the design details. I'd assume this would mean RBridges >>>>> should be willing to receive packets from other RBridges >>>>> regardless of outer VLAN tag. Would we then mark in the >>>>> Hellos what VLAN tag(s) you've heard from what other RBridges >>>>> with? What do we do with multicast if there isn't a single >>>>> VLAN tag that seems to work to send to everyone? Would we >>>>> allow configuration to send on a set of VLAN tags, or just on >>>>> one at a time (and we allow configuration to say which one it is)? >>>>> >>>>> Certainly a) is simpler. If the consensus was b), we'd better >>>>> work out the details. >>>>> >>>>> Radia >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge@postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge@postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> > > Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9PHJqmU007292 for <rbridge@postel.org>; Thu, 25 Oct 2007 10:19:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,329,1188802800"; d="scan'208";a="20537449" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 25 Oct 2007 10:19:48 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id DA1422383B5; Thu, 25 Oct 2007 10:19:47 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 10:19:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Oct 2007 10:19:47 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E91F9E5@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <471FBC2E.5080705@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? Thread-Index: AcgWhouop6vKgvVeR1eEbNP3V93vmAAoyO6A References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <471FBC2E.5080705@sun.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Silvano Gai" <sgai@nuovasystems.com> X-OriginalArrivalTime: 25 Oct 2007 17:19:47.0884 (UTC) FILETIME=[3E735EC0:01C8172B] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9PHJqmU007292 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 25 Oct 2007 17:20:18 -0000 Status: RO Content-Length: 9861 Hi Radia, I am fairly comfortable with adopting the single VLAN hello proposal and forcing that to be VLAN 1. I would rather not have to deal with the complexity of making it configurable because even that can be subject to misconfiguration and would have its own set of issues, but I am also not totally opposed to that if someone else feels strongly about it. The main argument for doing that would be point (b) in your message -- that VLAN 1 was already being used for something else and the operator didn't want to use it for RBridge control traffic. As you point out, it looks like the proposal for sending hellos on multiple VLANs would also require additional scrutiny/specification before it can be adopted. Unless shown to be absolutely necessary, this approach imposes a significant processing burden so I would rather see us solve the problem with the hellos on VLAN 1 only. Anoop > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Wednesday, October 24, 2007 2:42 PM > To: Silvano Gai > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN tags > onRBridge-RBridgepackets? > > It's always hard to catch up on a thread after being away > from email for a couple of days, but Silvano --- both the > tone and (lack of) content of your message below makes it > really difficult. > > In order to do quality engineering, we need to understand > what all the tradeoffs are, and we have to be able to do > discourse in an atmosphere of mutual respect. > > Saying something like "not doing it my way is 'too weak to be > practical', or 'holds water like a pasta strainer' is not > engineering. It is attempting to ridicule anyone who > disagrees with you, and also is completely uninformative > because you are not saying what the tradeoffs are, or even > the details of how the thing you want would work. > > I am usually proud of this WG because we usually do explore > all the options and what the tradoffs are without resorting > to bullying and ridicule. Let's strive to do engineering that way. > > So let me demonstrate by getting back to the thread. > > I think the "downsides" of sending all RBridge-RBridge > messages on a single unconfigurable VLAN (proposal being VLAN 1) are: > a) if VLAN 1 is indeed partitioned, the RBridges will not > know through IS-IS Hellos that they have RBridge neighbors, > and multiple DRBs will be elected. But the proposal also > includes how to prevent multiple DRB, namely by being > conservative about forwarding data traffic to/from the link > until we discover, though reporting the bridge root ID in > LSPs, that it is safe to do so > b) a customer might want to not use that VLAN for > RBridge-RBridge traffic. However, if that customer felt so > strongly about minimizing RBridge-Rbridge traffic, they could > reconfigure use of the VLANs to move what they were using > VLAN 1 to, to some other VLAN. So saying "just use 1" might > inconvenience one customer who is already very savvy and > likes to do really fancy configuration things, but does not > prevent them from accomplishing all the exotic things they > are trying to do -- just means some more configuration. And > is saves what hopefully is the vast majority of customers > from having to do any configuration whatsoever, and > simplifies the spec and prevents misconfiguration. > > The upside of saying "just use 1" is extreme simplicity, and > with the safeguards, will not have any higher probabilty of > loops than already exists due to repeaters coming up, or > bridge spanning tree messages getting lost. > > The next more complex proposal was to allow configuration to > still ultimately use one VLAN per cloud, but allow it to be > configurable to be something other than 1. I gave a proposal > for doing that in a previous message (the DRB tells all the > other RBridges what VLAN to use, while the DRB still sends on > VLAN 1 in addition to the VLAN the DRB tells everyone to send > one). I think the upside over the simplest "just use 1", is > that it allows a customer that doesn't want RBridge-RBridge > traffic being used on VLAN 1, or intentionally wants data > traffic on VLAN 1 to be partitioned on a cloud, to move to a > VLAN on that cloud that is OK not to be partitioned. The > downside is that steady state the DRB will send one more > Hello (on VLAN 1) than it would have, once the DRB tells all > the other RBridges what VLAN to send on, and it is one more > configuration thing to have to explain. And it seems likely > that the DRB will be misconfigured and declare that RBridges > will use VLAN k instead of 1, when some other RBridge on the > cloud is not configured to support k. It won't be fatal > (since that other RBridge will still hear the DRB on VLAN 1 > and will also know about the other DRB through link state > messages). My opinion is that this extra complexity over > "just use 1" is not warranted given the small upside. > > If there is another proposal, say "send all Hellos on all > VLANs", I claim that the details of that have never been > specified well enough for that proposal to be evaluated. So > if someone who advocates that can do that, staying technical, > covering all details like whether in your IS-IS Hello you > list all the VLAN tags you've heard Hellos from for each > neighbor, and how you send a multicast data message when you > have adjacencies with different VLAN tags for different > subsets of neighbors, I'd like to hear it. > > And by all means, if I have missed some of the downsides on > "just use VLAN 1", or "just use a single VLAN, but it can be > configured to be something other than 1", then by all means > add to the arguments. > > Radia > > > > > Silvano Gai wrote: > > I want to restate that IMHO a design that sends messages on > a single > > VLAN is so week to be completely useless. > > > > I met Anoop on a plane back from a T11 meeting and we discussed the > > issue of sending messages on all the configured VLANs. > Anoop pointed > > out that, if these messages are ISIS messages, this can > overload the > > RBrige supervisor. > > > > We identified a possible solution based on two different > message types: > > - ISIS used on a single VLAN to compute adjacency > > - simple per-VLAN checking on all the VLANs to verify reachability. > > > > The second kind of messages is much simpler and therefore they load > > less the RBrige supervisor. In the future, per-VLAN checking can be > > implemented by the port ASIC. This seems a viable solution that > > requires design effort, but it is promising. > > > > Without the per-VLAN checking, running ISIS on a single VLAN holds > > water like a pasta-strainer. > > > > -- Silvano > > > > > > > >> -----Original Message----- > >> From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] > >> > > On > > > >> Behalf Of Anoop Ghanwani > >> Sent: Monday, October 22, 2007 11:01 AM > >> To: Radia Perlman; Developing a hybrid router/bridge. > >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > >> RBridgepackets? > >> > >> > >> If we want to make implementations work with only a single > Hello for > >> all VLANs than the option is (a). I think that is what it > should be. > >> Basically, as a part of RBridge configuration there should be a > >> "RBridge Control VLAN" configuration that applies to the whole > >> device. It should default to VLAN 1, but an operator can > choose to > >> change it. > >> A RBridge only emits Hellos on that VLAN. If it receives > Hellos on > >> any other VLAN that should be detected as an error condition and > >> reported. > >> > >> There have been some problem corner cases that have been > pointed out > >> previously on the list that may result in temporary duplication of > >> traffic when there is misconfiguration. Those should be > documented. > >> > >> Anoop > >> > >> > >>> -----Original Message----- > >>> From: rbridge-bounces@postel.org > >>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > >>> Sent: Saturday, October 20, 2007 9:47 PM > >>> To: Developing a hybrid router/bridge. > >>> Subject: [rbridge] Final outcome of outer VLAN tags on > >>> RBridge-RBridgepackets? > >>> > >>> I'm not sure I understood the final consensus on what we > should do > >>> for outer VLAN tags on inter-RBridge packets. > >>> > >>> The possibilities I think the consensus might have been are: > >>> > >>> a) only use VLAN 1, explicit tag, no configuration possible. > >>> b) default is VLAN 1, explicit tag, configuration is possible to > >>> change sending with VLAN tag(s) something other than 1. > If this is > >>> what was decided, I don't believe we've worked out the design > >>> details. I'd assume this would mean RBridges should be willing to > >>> receive packets from other RBridges regardless of outer VLAN tag. > >>> Would we then mark in the Hellos what VLAN tag(s) you've > heard from > >>> what other RBridges with? What do we do with multicast if there > >>> isn't a single VLAN tag that seems to work to send to everyone? > >>> Would we allow configuration to send on a set of VLAN > tags, or just > >>> on one at a time (and we allow configuration to say which one it > >>> is)? > >>> > >>> Certainly a) is simpler. If the consensus was b), we'd > better work > >>> out the details. > >>> > >>> Radia > >>> _______________________________________________ > >>> rbridge mailing list > >>> rbridge@postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> > >>> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge@postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > >> > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9PGPg1F016301 for <rbridge@postel.org>; Thu, 25 Oct 2007 09:25:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Oct 2007 09:25:26 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20252A299@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <471FBC2E.5080705@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? thread-index: AcgWhosdYwh1MkzEQMKBk15Kh3psWwAmXpvg References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <471FBC2E.5080705@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9PGPg1F016301 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 25 Oct 2007 16:26:28 -0000 Status: RO Content-Length: 10708 Radia, I am currently in Italy with limited connectivity. I'll write you a more complete reply next week. I have also the additional issue that I find hard to discuss these topics by email. I prefer face-to-face meeting in front of a whiteboard. Anyhow, let me try I think that the root of the disagreement is in the priority of the requirements. For me and others robustness and interoperability are paramount, because we look at TRILL in the Enterprise/Datacenter where there is no margin for errors, even in the presence of misconfigurations. Moreover we want to use ISIS unmodified with just few TLV added. If the price to pay for this solution is to use a "robust" CPU for the RBridge supervisor, we are happy to pay the price. Dinesh will present at the next IETF robustness and interoperability issues. For Anoop, loading the supervisor switch as little as possible is paramount. He seems to look more at green field installation, where interoperability and robustness to misconfiguration are somehow important, but not paramount. This difference in requirements causes differences in the preferred solution: - I prefer to use the standard ISIS with Hellos on all VLANs for discovery and LSP only on one VLAN. - Anoop prefers to not send the Hellos on all VLANs for discovery and he is willing to follow your lead to somehow modifying ISIS, adding additional steps to check Spanning tree roots, synchronize LSP databases, etc. When you have done all the changes that you propose to ISIS, I am not sure that we are using "an existing routing protocol" (as per TRILL charter), I think we have designed something new. Summarizing my goals are: - Robustness - Interoperability - Unmodified ISIS (e.g. no synchronization steps) My solution is to use what ISIS provides, i.e. - Hellos on all configured VLANs for discovery and LSP only on one VLAN. -- Silvano > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Wednesday, October 24, 2007 2:42 PM > To: Silvano Gai > Cc: Anoop Ghanwani; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > It's always hard to catch up on a thread after being away from email for > a couple of days, but > Silvano --- both the tone and (lack of) content of your message below > makes it really difficult. > > In order to do quality engineering, we need to understand what all the > tradeoffs are, and we > have to be able to do discourse in an atmosphere of mutual respect. > > Saying something like "not doing it my way is 'too weak to be > practical', or 'holds water like > a pasta strainer' is not engineering. It is attempting to ridicule > anyone who disagrees with you, > and also is completely uninformative because you are not saying what the > tradeoffs are, or > even the details of how the thing you want would work. > > I am usually proud of this WG because we usually do explore all the > options and what the > tradoffs are without resorting to bullying and ridicule. Let's strive to > do engineering that way. > > So let me demonstrate by getting back to the thread. > > I think the "downsides" of sending all RBridge-RBridge messages on a > single unconfigurable > VLAN (proposal being VLAN 1) are: > a) if VLAN 1 is indeed partitioned, the RBridges will not know through > IS-IS Hellos that they have RBridge neighbors, and > multiple DRBs will be elected. But the proposal also includes how > to prevent multiple DRB, namely by being conservative about forwarding > data traffic to/from the link until we discover, though reporting the > bridge root ID in LSPs, > that it is safe to do so > b) a customer might want to not use that VLAN for RBridge-RBridge > traffic. However, > if that customer felt so strongly about minimizing RBridge-Rbridge > traffic, they could reconfigure use of the VLANs to move what they were > using VLAN 1 > to, to some other VLAN. So saying "just use 1" might inconvenience one > customer who is > already very savvy and likes to do really fancy configuration things, > but does not > prevent them from accomplishing all the exotic things they are trying to > do -- just means > some more configuration. And is saves what hopefully is the vast > majority of customers from > having to do any configuration whatsoever, and simplifies the spec and > prevents misconfiguration. > > The upside of saying "just use 1" is extreme simplicity, and with the > safeguards, will not have > any higher probabilty of loops than already exists due to repeaters > coming up, or bridge > spanning tree messages getting lost. > > The next more complex proposal was to allow configuration to still > ultimately use one VLAN per > cloud, but allow it to be configurable to be something other than 1. I > gave a proposal for > doing that in a previous message (the DRB tells all the other > RBridges what VLAN to use, while the DRB still sends on VLAN 1 in addition > to the VLAN the DRB tells everyone to send one). I think the upside over > the simplest "just use 1", is > that it allows a customer that doesn't want RBridge-RBridge traffic > being used on VLAN 1, > or intentionally wants data traffic on VLAN 1 to be partitioned on a > cloud, to move to > a VLAN on that cloud that is OK not to be partitioned. The downside is > that steady state > the DRB will send one more Hello (on VLAN 1) than it would have, once > the DRB tells > all the other RBridges what VLAN to send on, and it is one more > configuration thing to > have to explain. And it seems likely that the DRB will be misconfigured > and declare that > RBridges will use VLAN k instead of 1, when some other RBridge on the > cloud is not > configured to support k. It won't be fatal (since that other RBridge > will still hear the DRB > on VLAN 1 and will also know about the other DRB through link state > messages). My opinion > is that this extra complexity over "just use 1" is not warranted given > the small upside. > > If there is another proposal, say "send all Hellos on all VLANs", I > claim that the details of > that have never been specified well enough for that proposal to be > evaluated. So if someone > who advocates that can do that, staying technical, covering all details > like whether in your > IS-IS Hello you list all the VLAN tags you've heard Hellos from for each > neighbor, and > how you send a multicast data message when you have adjacencies with > different VLAN tags > for different subsets of neighbors, I'd like to hear it. > > And by all means, if I have missed some of the downsides on "just use > VLAN 1", or > "just use a single VLAN, but it can be configured to be something other > than 1", then > by all means add to the arguments. > > Radia > > > > > Silvano Gai wrote: > > I want to restate that IMHO a design that sends messages on a single > > VLAN is so week to be completely useless. > > > > I met Anoop on a plane back from a T11 meeting and we discussed the > > issue of sending messages on all the configured VLANs. Anoop pointed out > > that, if these messages are ISIS messages, this can overload the RBrige > > supervisor. > > > > We identified a possible solution based on two different message types: > > - ISIS used on a single VLAN to compute adjacency > > - simple per-VLAN checking on all the VLANs to verify reachability. > > > > The second kind of messages is much simpler and therefore they load less > > the RBrige supervisor. In the future, per-VLAN checking can be > > implemented by the port ASIC. This seems a viable solution that requires > > design effort, but it is promising. > > > > Without the per-VLAN checking, running ISIS on a single VLAN holds water > > like a pasta-strainer. > > > > -- Silvano > > > > > > > >> -----Original Message----- > >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > >> > > On > > > >> Behalf Of Anoop Ghanwani > >> Sent: Monday, October 22, 2007 11:01 AM > >> To: Radia Perlman; Developing a hybrid router/bridge. > >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > >> RBridgepackets? > >> > >> > >> If we want to make implementations work with > >> only a single Hello for all VLANs than the > >> option is (a). I think that is what it should be. > >> Basically, as a part of RBridge configuration > >> there should be a "RBridge Control VLAN" configuration > >> that applies to the whole device. It should default > >> to VLAN 1, but an operator can choose to change it. > >> A RBridge only emits Hellos on that VLAN. If it > >> receives Hellos on any other VLAN that should > >> be detected as an error condition and reported. > >> > >> There have been some problem corner cases that > >> have been pointed out previously on the list > >> that may result in temporary duplication of > >> traffic when there is misconfiguration. Those > >> should be documented. > >> > >> Anoop > >> > >> > >>> -----Original Message----- > >>> From: rbridge-bounces@postel.org > >>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > >>> Sent: Saturday, October 20, 2007 9:47 PM > >>> To: Developing a hybrid router/bridge. > >>> Subject: [rbridge] Final outcome of outer VLAN tags on > >>> RBridge-RBridgepackets? > >>> > >>> I'm not sure I understood the final consensus on what we > >>> should do for outer VLAN tags on inter-RBridge packets. > >>> > >>> The possibilities I think the consensus might have been are: > >>> > >>> a) only use VLAN 1, explicit tag, no configuration possible. > >>> b) default is VLAN 1, explicit tag, configuration is possible > >>> to change sending with VLAN tag(s) something other than 1. If > >>> this is what was decided, I don't believe we've worked out > >>> the design details. I'd assume this would mean RBridges > >>> should be willing to receive packets from other RBridges > >>> regardless of outer VLAN tag. Would we then mark in the > >>> Hellos what VLAN tag(s) you've heard from what other RBridges > >>> with? What do we do with multicast if there isn't a single > >>> VLAN tag that seems to work to send to everyone? Would we > >>> allow configuration to send on a set of VLAN tags, or just on > >>> one at a time (and we allow configuration to say which one it is)? > >>> > >>> Certainly a) is simpler. If the consensus was b), we'd better > >>> work out the details. > >>> > >>> Radia > >>> _______________________________________________ > >>> rbridge mailing list > >>> rbridge@postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> > >>> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge@postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > >> Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9OLg7s3023198 for <rbridge@postel.org>; Wed, 24 Oct 2007 14:42:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,326,1188802800"; d="scan'208";a="20498562" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 24 Oct 2007 14:42:02 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 4844D238373; Wed, 24 Oct 2007 14:42:02 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 14:42:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Oct 2007 14:42:00 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E91F876@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202529CD9@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets? Thread-Index: AcgTnrWi27PNk67MQpm5GuL1S8AbDABNgLkgABOuRiAAIBzRwAAvCFDwAAmOftA= References: <471AD9CE.7020405@sun.com><4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com><34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com><3870C46029D1F945B1472F170D2D9790032E6041@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA202529CD9@nuova-ex1.hq.nuovaimpresa.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-OriginalArrivalTime: 24 Oct 2007 21:42:01.0821 (UTC) FILETIME=[B631E0D0:01C81686] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9OLg7s3023198 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 21:42:38 -0000 Status: RO Content-Length: 7493 Silvano, I am not opposed to using per-VLAN connectivity detection (which we're saying should be done by hellos) if it is shown to be absolutely essential. As long as there is a way around it, I prefer to avoid having to send them. We should probably delay the decision until we understand what scenarios make it an absolute requirement before we make it such. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > Sent: Wednesday, October 24, 2007 10:13 AM > To: Eastlake III Donald-LDE008 > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer > VLANtagsonRBridge-RBridgepackets? > > > Donald, > > My concern is misconfiguration. > > If we don't send at least a simple Hello per VLAN misconfigurations go > undetected and can cause frame duplication. > > See also my latest reply to Anoop: we don't need to send an LSP. > > Whatever scheme that sends frames only on one VLAN cannot detect VLAN > misconfiguration by definition. > > We have a simple and tested solution: "Let's send Hellos on all VLANs > for discovery and LSP only on one VLAN." > > This solves the issue of Anoop, of not sending multiple LSPs. > > Let's use it > > -- Silvano > > P.S. I'll not be able to make the December TRILL meeting, > since it is at > the same time as T11/FCoE. Dinesh can present a slide set > with the most > important issues related to misconfiguration. > > > > > -----Original Message----- > > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake@motorola.com] > > Sent: Tuesday, October 23, 2007 1:46 PM > > To: Silvano Gai > > Cc: Developing a hybrid router/bridge. > > Subject: RE: [rbridge] Final outcome of outer VLAN tagsonRBridge- > > RBridgepackets? > > > > Hi Silvano, > > > > I have two questions: > > > > (1) What exactly is the problem you see with doing adjacency on one > > VLAN? It could be that you think that Hellos on one VLAN would be OK > but > > it is too much of a configuration burden to expect network > > administrators to figure out which VLAN and to then configure their > > Rbridges. Or it could be that you think that even if each > port on each > > Rbridge was configured to the "best" single VLAN, the adjacencies > found > > would be too sparse compared to those potentially possible. Or you > could > > think that both of these and/or other things are the main problem... > > > > (2) If multiple Hellos on different VLANs, or some other technique, > are > > used to learn the full VLAN connectivity, what are Rbriges > supposed to > > do when no single VLAN will get to all the desired destinations? For > > example, assume that Rbridge-A is connected as follows: > > > > On VLAN 2 to B and C > > On VLAN 3 to C, D, and E > > On VLAN 4 to F, G, and H > > On VLAN 5 to D, E, F, and G > > > > If Rbrdige-A wants to send a multi-destination frame to all of B > through > > H, it would seem that it has to send it at least three > times to get to > > all the one-Rbridge-hop destinations and to avoid duplication. For > > example, multicast on VLANs 3 and 4 and unicast to B. Or, > alternatively, > > multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity > > exceeds some threshold, Rbridge-A could just forget about optimality > and > > unicast the frame separately to B through H. > > > > How would you suggest handling such situations? > > > > Thanks, > > Donald > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Silvano Gai > > Sent: Tuesday, October 23, 2007 6:21 AM > > To: Anoop Ghanwani; Radia Perlman; Developing a hybrid > router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN > > tagsonRBridge-RBridgepackets? > > > > I want to restate that IMHO a design that sends messages on a single > > VLAN is so week to be completely useless. > > > > I met Anoop on a plane back from a T11 meeting and we discussed the > > issue of sending messages on all the configured VLANs. Anoop pointed > out > > that, if these messages are ISIS messages, this can overload the > RBrige > > supervisor. > > > > We identified a possible solution based on two different message > types: > > - ISIS used on a single VLAN to compute adjacency > > - simple per-VLAN checking on all the VLANs to verify reachability. > > > > The second kind of messages is much simpler and therefore they load > less > > the RBrige supervisor. In the future, per-VLAN checking can be > > implemented by the port ASIC. This seems a viable solution that > requires > > design effort, but it is promising. > > > > Without the per-VLAN checking, running ISIS on a single VLAN holds > water > > like a pasta-strainer. > > > > -- Silvano > > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] > > On > > > Behalf Of Anoop Ghanwani > > > Sent: Monday, October 22, 2007 11:01 AM > > > To: Radia Perlman; Developing a hybrid router/bridge. > > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > > RBridgepackets? > > > > > > > > > If we want to make implementations work with > > > only a single Hello for all VLANs than the > > > option is (a). I think that is what it should be. > > > Basically, as a part of RBridge configuration > > > there should be a "RBridge Control VLAN" configuration > > > that applies to the whole device. It should default > > > to VLAN 1, but an operator can choose to change it. > > > A RBridge only emits Hellos on that VLAN. If it > > > receives Hellos on any other VLAN that should > > > be detected as an error condition and reported. > > > > > > There have been some problem corner cases that > > > have been pointed out previously on the list > > > that may result in temporary duplication of > > > traffic when there is misconfiguration. Those > > > should be documented. > > > > > > Anoop > > > > > > > -----Original Message----- > > > > From: rbridge-bounces@postel.org > > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > > Sent: Saturday, October 20, 2007 9:47 PM > > > > To: Developing a hybrid router/bridge. > > > > Subject: [rbridge] Final outcome of outer VLAN tags on > > > > RBridge-RBridgepackets? > > > > > > > > I'm not sure I understood the final consensus on what we > > > > should do for outer VLAN tags on inter-RBridge packets. > > > > > > > > The possibilities I think the consensus might have been are: > > > > > > > > a) only use VLAN 1, explicit tag, no configuration possible. > > > > b) default is VLAN 1, explicit tag, configuration is possible > > > > to change sending with VLAN tag(s) something other than 1. If > > > > this is what was decided, I don't believe we've worked out > > > > the design details. I'd assume this would mean RBridges > > > > should be willing to receive packets from other RBridges > > > > regardless of outer VLAN tag. Would we then mark in the > > > > Hellos what VLAN tag(s) you've heard from what other RBridges > > > > with? What do we do with multicast if there isn't a single > > > > VLAN tag that seems to work to send to everyone? Would we > > > > allow configuration to send on a set of VLAN tags, or just on > > > > one at a time (and we allow configuration to say which > one it is)? > > > > > > > > Certainly a) is simpler. If the consensus was b), we'd better > > > > work out the details. > > > > > > > > Radia Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9OLexro022682 for <rbridge@postel.org>; Wed, 24 Oct 2007 14:40:59 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQF00L3JQVWB300@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 24 Oct 2007 14:40:44 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQF00616QVRZDH0@mail.sunlabs.com> for rbridge@postel.org; Wed, 24 Oct 2007 14:40:44 -0700 (PDT) Date: Wed, 24 Oct 2007 14:42:06 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> To: Silvano Gai <sgai@nuovasystems.com> Message-id: <471FBC2E.5080705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 21:42:15 -0000 Status: RO Content-Length: 8196 It's always hard to catch up on a thread after being away from email for a couple of days, but Silvano --- both the tone and (lack of) content of your message below makes it really difficult. In order to do quality engineering, we need to understand what all the tradeoffs are, and we have to be able to do discourse in an atmosphere of mutual respect. Saying something like "not doing it my way is 'too weak to be practical', or 'holds water like a pasta strainer' is not engineering. It is attempting to ridicule anyone who disagrees with you, and also is completely uninformative because you are not saying what the tradeoffs are, or even the details of how the thing you want would work. I am usually proud of this WG because we usually do explore all the options and what the tradoffs are without resorting to bullying and ridicule. Let's strive to do engineering that way. So let me demonstrate by getting back to the thread. I think the "downsides" of sending all RBridge-RBridge messages on a single unconfigurable VLAN (proposal being VLAN 1) are: a) if VLAN 1 is indeed partitioned, the RBridges will not know through IS-IS Hellos that they have RBridge neighbors, and multiple DRBs will be elected. But the proposal also includes how to prevent multiple DRB, namely by being conservative about forwarding data traffic to/from the link until we discover, though reporting the bridge root ID in LSPs, that it is safe to do so b) a customer might want to not use that VLAN for RBridge-RBridge traffic. However, if that customer felt so strongly about minimizing RBridge-Rbridge traffic, they could reconfigure use of the VLANs to move what they were using VLAN 1 to, to some other VLAN. So saying "just use 1" might inconvenience one customer who is already very savvy and likes to do really fancy configuration things, but does not prevent them from accomplishing all the exotic things they are trying to do -- just means some more configuration. And is saves what hopefully is the vast majority of customers from having to do any configuration whatsoever, and simplifies the spec and prevents misconfiguration. The upside of saying "just use 1" is extreme simplicity, and with the safeguards, will not have any higher probabilty of loops than already exists due to repeaters coming up, or bridge spanning tree messages getting lost. The next more complex proposal was to allow configuration to still ultimately use one VLAN per cloud, but allow it to be configurable to be something other than 1. I gave a proposal for doing that in a previous message (the DRB tells all the other RBridges what VLAN to use, while the DRB still sends on VLAN 1 in addition to the VLAN the DRB tells everyone to send one). I think the upside over the simplest "just use 1", is that it allows a customer that doesn't want RBridge-RBridge traffic being used on VLAN 1, or intentionally wants data traffic on VLAN 1 to be partitioned on a cloud, to move to a VLAN on that cloud that is OK not to be partitioned. The downside is that steady state the DRB will send one more Hello (on VLAN 1) than it would have, once the DRB tells all the other RBridges what VLAN to send on, and it is one more configuration thing to have to explain. And it seems likely that the DRB will be misconfigured and declare that RBridges will use VLAN k instead of 1, when some other RBridge on the cloud is not configured to support k. It won't be fatal (since that other RBridge will still hear the DRB on VLAN 1 and will also know about the other DRB through link state messages). My opinion is that this extra complexity over "just use 1" is not warranted given the small upside. If there is another proposal, say "send all Hellos on all VLANs", I claim that the details of that have never been specified well enough for that proposal to be evaluated. So if someone who advocates that can do that, staying technical, covering all details like whether in your IS-IS Hello you list all the VLAN tags you've heard Hellos from for each neighbor, and how you send a multicast data message when you have adjacencies with different VLAN tags for different subsets of neighbors, I'd like to hear it. And by all means, if I have missed some of the downsides on "just use VLAN 1", or "just use a single VLAN, but it can be configured to be something other than 1", then by all means add to the arguments. Radia Silvano Gai wrote: > I want to restate that IMHO a design that sends messages on a single > VLAN is so week to be completely useless. > > I met Anoop on a plane back from a T11 meeting and we discussed the > issue of sending messages on all the configured VLANs. Anoop pointed out > that, if these messages are ISIS messages, this can overload the RBrige > supervisor. > > We identified a possible solution based on two different message types: > - ISIS used on a single VLAN to compute adjacency > - simple per-VLAN checking on all the VLANs to verify reachability. > > The second kind of messages is much simpler and therefore they load less > the RBrige supervisor. In the future, per-VLAN checking can be > implemented by the port ASIC. This seems a viable solution that requires > design effort, but it is promising. > > Without the per-VLAN checking, running ISIS on a single VLAN holds water > like a pasta-strainer. > > -- Silvano > > > >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >> > On > >> Behalf Of Anoop Ghanwani >> Sent: Monday, October 22, 2007 11:01 AM >> To: Radia Perlman; Developing a hybrid router/bridge. >> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- >> RBridgepackets? >> >> >> If we want to make implementations work with >> only a single Hello for all VLANs than the >> option is (a). I think that is what it should be. >> Basically, as a part of RBridge configuration >> there should be a "RBridge Control VLAN" configuration >> that applies to the whole device. It should default >> to VLAN 1, but an operator can choose to change it. >> A RBridge only emits Hellos on that VLAN. If it >> receives Hellos on any other VLAN that should >> be detected as an error condition and reported. >> >> There have been some problem corner cases that >> have been pointed out previously on the list >> that may result in temporary duplication of >> traffic when there is misconfiguration. Those >> should be documented. >> >> Anoop >> >> >>> -----Original Message----- >>> From: rbridge-bounces@postel.org >>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >>> Sent: Saturday, October 20, 2007 9:47 PM >>> To: Developing a hybrid router/bridge. >>> Subject: [rbridge] Final outcome of outer VLAN tags on >>> RBridge-RBridgepackets? >>> >>> I'm not sure I understood the final consensus on what we >>> should do for outer VLAN tags on inter-RBridge packets. >>> >>> The possibilities I think the consensus might have been are: >>> >>> a) only use VLAN 1, explicit tag, no configuration possible. >>> b) default is VLAN 1, explicit tag, configuration is possible >>> to change sending with VLAN tag(s) something other than 1. If >>> this is what was decided, I don't believe we've worked out >>> the design details. I'd assume this would mean RBridges >>> should be willing to receive packets from other RBridges >>> regardless of outer VLAN tag. Would we then mark in the >>> Hellos what VLAN tag(s) you've heard from what other RBridges >>> with? What do we do with multicast if there isn't a single >>> VLAN tag that seems to work to send to everyone? Would we >>> allow configuration to send on a set of VLAN tags, or just on >>> one at a time (and we allow configuration to say which one it is)? >>> >>> Certainly a) is simpler. If the consensus was b), we'd better >>> work out the details. >>> >>> Radia >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9OL9iDJ013057 for <Rbridge@postel.org>; Wed, 24 Oct 2007 14:09:45 -0700 (PDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Oct 2007 17:09:41 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77026C8B40@nekter> In-Reply-To: <471F8DC7.2040203@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TRILL meeting in Vancouver Thread-Index: AcgWbCHaqQOo/YM8To+mVBHCZ2o8mwAFfCWQ References: <3870C46029D1F945B1472F170D2D9790032E6447@de01exm64.ds.mot.com> <471F8DC7.2040203@isi.edu> From: "Caitlin Bestler" <Caitlin.Bestler@neterion.com> To: "Joe Touch" <touch@ISI.EDU>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlin.bestler@neterion.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9OL9iDJ013057 Cc: Rbridge@postel.org Subject: Re: [rbridge] TRILL meeting in Vancouver X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 21:10:00 -0000 Status: RO Content-Length: 205 Joe touch wrote: >TRILL appears to be consistently scheduled on top of TSVWG. >I'm in favor of moving it unless it sits on top of TCPM. Seconded. Those are the three highest priority sessions for me. Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9OIORMA029619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 24 Oct 2007 11:24:28 -0700 (PDT) Received: from [128.9.176.226] (c2-vpn09.isi.edu [128.9.176.226]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9OIO9EX024223; Wed, 24 Oct 2007 11:24:10 -0700 (PDT) Message-ID: <471F8DC7.2040203@isi.edu> Date: Wed, 24 Oct 2007 11:24:07 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> References: <3870C46029D1F945B1472F170D2D9790032E6447@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032E6447@de01exm64.ds.mot.com> X-Enigmail-Version: 0.95.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig627519C66833ACE6BA63E905" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org Subject: Re: [rbridge] TRILL meeting in Vancouver X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 18:25:05 -0000 Status: RO Content-Length: 1629 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig627519C66833ACE6BA63E905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TRILL appears to be consistently scheduled on top of TSVWG. I'm in favor of moving it unless it sits on top of TCPM. Joe Eastlake III Donald-LDE008 wrote: > A draft agenda for the 70th IETF meeting in Vancouver, British Columbia= , > has been posted a few days ahead of schedule on the www.ietf.org web > site. It shows TRILL as being Thursday morning. However, a couple of ou= r > working group draft authors have requested that we attempt to have the > meeting move to Tuesday. Although it is not clear that we can do this, > keeping in mind other working group and meeting space constraints (for > example, as an Internet Area WG we can't conflict with the INTAREA > meeting Tuesday afternoon), we plan to request such a move to Tuesday. >=20 > Thanks, > Erik and Donald >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge --------------enig627519C66833ACE6BA63E905 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH43IE5f5cImnZrsRAq45AKC7Rwa8x+zBSdSEPhPbW1nl4DE21wCgoRa8 nGaur/iI+q/4nxtTh3NThz4= =4nzb -----END PGP SIGNATURE----- --------------enig627519C66833ACE6BA63E905-- Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9OI2KOJ019886 for <Rbridge@postel.org>; Wed, 24 Oct 2007 11:02:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1193248939!11467548!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17035 invoked from network); 24 Oct 2007 18:02:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 24 Oct 2007 18:02:19 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9OI2J8J021120 for <Rbridge@postel.org>; Wed, 24 Oct 2007 11:02:19 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l9OI2IEg019400 for <Rbridge@postel.org>; Wed, 24 Oct 2007 13:02:18 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9OI2IJT019393 for <Rbridge@postel.org>; Wed, 24 Oct 2007 13:02:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 24 Oct 2007 14:02:15 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6447@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TRILL meeting in Vancouver Thread-Index: AcgWaAKeh7I2ZgMQSe++0c142+wtVQ== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9OI2KOJ019886 Subject: [rbridge] TRILL meeting in Vancouver X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 18:03:26 -0000 Status: RO Content-Length: 592 A draft agenda for the 70th IETF meeting in Vancouver, British Columbia, has been posted a few days ahead of schedule on the www.ietf.org web site. It shows TRILL as being Thursday morning. However, a couple of our working group draft authors have requested that we attempt to have the meeting move to Tuesday. Although it is not clear that we can do this, keeping in mind other working group and meeting space constraints (for example, as an Internet Area WG we can't conflict with the INTAREA meeting Tuesday afternoon), we plan to request such a move to Tuesday. Thanks, Erik and Donald Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9OHFAo6003321 for <rbridge@postel.org>; Wed, 24 Oct 2007 10:15:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Oct 2007 10:13:06 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202529CD9@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032E6041@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? thread-index: AcgTnrWi27PNk67MQpm5GuL1S8AbDABNgLkgABOuRiAAIBzRwAAvCFDw References: <471AD9CE.7020405@sun.com><4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790032E6041@de01exm64.ds.mot.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9OHFAo6003321 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 17:16:04 -0000 Status: RO Content-Length: 6885 Donald, My concern is misconfiguration. If we don't send at least a simple Hello per VLAN misconfigurations go undetected and can cause frame duplication. See also my latest reply to Anoop: we don't need to send an LSP. Whatever scheme that sends frames only on one VLAN cannot detect VLAN misconfiguration by definition. We have a simple and tested solution: "Let's send Hellos on all VLANs for discovery and LSP only on one VLAN." This solves the issue of Anoop, of not sending multiple LSPs. Let's use it -- Silvano P.S. I'll not be able to make the December TRILL meeting, since it is at the same time as T11/FCoE. Dinesh can present a slide set with the most important issues related to misconfiguration. > -----Original Message----- > From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake@motorola.com] > Sent: Tuesday, October 23, 2007 1:46 PM > To: Silvano Gai > Cc: Developing a hybrid router/bridge. > Subject: RE: [rbridge] Final outcome of outer VLAN tagsonRBridge- > RBridgepackets? > > Hi Silvano, > > I have two questions: > > (1) What exactly is the problem you see with doing adjacency on one > VLAN? It could be that you think that Hellos on one VLAN would be OK but > it is too much of a configuration burden to expect network > administrators to figure out which VLAN and to then configure their > Rbridges. Or it could be that you think that even if each port on each > Rbridge was configured to the "best" single VLAN, the adjacencies found > would be too sparse compared to those potentially possible. Or you could > think that both of these and/or other things are the main problem... > > (2) If multiple Hellos on different VLANs, or some other technique, are > used to learn the full VLAN connectivity, what are Rbriges supposed to > do when no single VLAN will get to all the desired destinations? For > example, assume that Rbridge-A is connected as follows: > > On VLAN 2 to B and C > On VLAN 3 to C, D, and E > On VLAN 4 to F, G, and H > On VLAN 5 to D, E, F, and G > > If Rbrdige-A wants to send a multi-destination frame to all of B through > H, it would seem that it has to send it at least three times to get to > all the one-Rbridge-hop destinations and to avoid duplication. For > example, multicast on VLANs 3 and 4 and unicast to B. Or, alternatively, > multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity > exceeds some threshold, Rbridge-A could just forget about optimality and > unicast the frame separately to B through H. > > How would you suggest handling such situations? > > Thanks, > Donald > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Silvano Gai > Sent: Tuesday, October 23, 2007 6:21 AM > To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN > tagsonRBridge-RBridgepackets? > > I want to restate that IMHO a design that sends messages on a single > VLAN is so week to be completely useless. > > I met Anoop on a plane back from a T11 meeting and we discussed the > issue of sending messages on all the configured VLANs. Anoop pointed out > that, if these messages are ISIS messages, this can overload the RBrige > supervisor. > > We identified a possible solution based on two different message types: > - ISIS used on a single VLAN to compute adjacency > - simple per-VLAN checking on all the VLANs to verify reachability. > > The second kind of messages is much simpler and therefore they load less > the RBrige supervisor. In the future, per-VLAN checking can be > implemented by the port ASIC. This seems a viable solution that requires > design effort, but it is promising. > > Without the per-VLAN checking, running ISIS on a single VLAN holds water > like a pasta-strainer. > > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Anoop Ghanwani > > Sent: Monday, October 22, 2007 11:01 AM > > To: Radia Perlman; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > RBridgepackets? > > > > > > If we want to make implementations work with > > only a single Hello for all VLANs than the > > option is (a). I think that is what it should be. > > Basically, as a part of RBridge configuration > > there should be a "RBridge Control VLAN" configuration > > that applies to the whole device. It should default > > to VLAN 1, but an operator can choose to change it. > > A RBridge only emits Hellos on that VLAN. If it > > receives Hellos on any other VLAN that should > > be detected as an error condition and reported. > > > > There have been some problem corner cases that > > have been pointed out previously on the list > > that may result in temporary duplication of > > traffic when there is misconfiguration. Those > > should be documented. > > > > Anoop > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > Sent: Saturday, October 20, 2007 9:47 PM > > > To: Developing a hybrid router/bridge. > > > Subject: [rbridge] Final outcome of outer VLAN tags on > > > RBridge-RBridgepackets? > > > > > > I'm not sure I understood the final consensus on what we > > > should do for outer VLAN tags on inter-RBridge packets. > > > > > > The possibilities I think the consensus might have been are: > > > > > > a) only use VLAN 1, explicit tag, no configuration possible. > > > b) default is VLAN 1, explicit tag, configuration is possible > > > to change sending with VLAN tag(s) something other than 1. If > > > this is what was decided, I don't believe we've worked out > > > the design details. I'd assume this would mean RBridges > > > should be willing to receive packets from other RBridges > > > regardless of outer VLAN tag. Would we then mark in the > > > Hellos what VLAN tag(s) you've heard from what other RBridges > > > with? What do we do with multicast if there isn't a single > > > VLAN tag that seems to work to send to everyone? Would we > > > allow configuration to send on a set of VLAN tags, or just on > > > one at a time (and we allow configuration to say which one it is)? > > > > > > Certainly a) is simpler. If the consensus was b), we'd better > > > work out the details. > > > > > > Radia > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9OHF134003276 for <rbridge@postel.org>; Wed, 24 Oct 2007 10:15:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Oct 2007 10:11:19 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202529CD8@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E91F648@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets? thread-index: AcgVuTDh9PCJLIV5RcW86MOz8AbYnwAEGMbAACVyRkA= References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <1193149257.6081.10.camel@ddutt-laptop> <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> <1193173848.10023.42.camel@ddutt-laptop> <4C94DE2070B172459E4F1EE14BD2364E91F648@HQ-EXCH-5.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "Dinesh G Dutt" <ddutt@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9OHF134003276 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 24 Oct 2007 17:15:31 -0000 Status: RO Content-Length: 2878 Anoop, I disagree. We started all this discussion because you said that sending LSP on all the VLANs was not scalable. Now we discovered that there is a standard, existing solution that uses Hellos on multiple VLANs for discovery and send LSP only on one VLAN. This solution is robust and not subject to the corner cases that are possible if you don't send Hellos on all the VLANs. Let's use it, not invent anything new and close this topic. -- Silvano > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Tuesday, October 23, 2007 4:42 PM > To: Dinesh G Dutt > Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge. > Subject: RE: [rbridge] Final outcome of outer VLANtagsonRBridge- > RBridgepackets? > > Hi Dinesh, > > It doesn't look like it would be essential at > this point, so if we want to put it in for > faster detection of certain configuration problems > then it should be put in as optional. > > Anoop > > > -----Original Message----- > > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > > Sent: Tuesday, October 23, 2007 2:11 PM > > To: Anoop Ghanwani > > Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge. > > Subject: RE: [rbridge] Final outcome of outer > > VLANtagsonRBridge-RBridgepackets? > > > > Anoop, > > > > I spoke to David Ward, an IS-IS expert here at Cisco (and a > > co-author on the L2 ISIS draft) and he said that it's > > perfectly fine to use Hellos on multiple VLANs for discovery > > and send LSP only on one VLAN, one of the common ones. > > > > Can we then conclude that by default we send Hellos on a set > > of one or more configured VLANs with the set being equal to > > the active set of VLANs on that link by default ? > > > > Thanks, > > > > Dinesh > > On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote: > > > > -----Original Message----- > > > > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > > > > Sent: Tuesday, October 23, 2007 7:21 AM > > > > To: Silvano Gai > > > > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid > > router/bridge. > > > > Subject: Re: [rbridge] Final outcome of outer VLAN > > > > tagsonRBridge-RBridgepackets? > > > > > > > > I agree that using a single VLAN solution for IS-IS DRB is weak. > > > > However, I'm skeptical that another protocol that also just sends > > > > Hellos is much more scalabale or better than IS-IS sending only > > > > Hellos on all configured VLANs. > > > > > > Dinesh, > > > > > > The key here is just sending hellos as opposed to > > maintaining a full > > > IS-IS adjacency on the VLAN. As long maintaining the > > adjancency and > > > sending LSPs on every VLAN is not required, the protocol > > that is used > > > for it doesn't matter. > > > > > > Anoop > > -- > > "And those who were seen dancing were thought to be insane by > > those who could not hear the music." -- Angela Monet > > Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9NNgKJB012737 for <rbridge@postel.org>; Tue, 23 Oct 2007 16:42:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,320,1188802800"; d="scan'208";a="13434752" Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 23 Oct 2007 16:42:17 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id EFFDC238394; Tue, 23 Oct 2007 16:42:16 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 16:42:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Oct 2007 16:42:16 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E91F648@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <1193173848.10023.42.camel@ddutt-laptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets? Thread-Index: AcgVuTDh9PCJLIV5RcW86MOz8AbYnwAEGMbA References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <1193149257.6081.10.camel@ddutt-laptop> <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> <1193173848.10023.42.camel@ddutt-laptop> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Dinesh G Dutt" <ddutt@cisco.com> X-OriginalArrivalTime: 23 Oct 2007 23:42:16.0788 (UTC) FILETIME=[583CB940:01C815CE] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NNgKJB012737 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Final outcome of outer VLANtagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 23:42:59 -0000 Status: RO Content-Length: 2025 Hi Dinesh, It doesn't look like it would be essential at this point, so if we want to put it in for faster detection of certain configuration problems then it should be put in as optional. Anoop > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > Sent: Tuesday, October 23, 2007 2:11 PM > To: Anoop Ghanwani > Cc: Silvano Gai; Radia Perlman; Developing a hybrid router/bridge. > Subject: RE: [rbridge] Final outcome of outer > VLANtagsonRBridge-RBridgepackets? > > Anoop, > > I spoke to David Ward, an IS-IS expert here at Cisco (and a > co-author on the L2 ISIS draft) and he said that it's > perfectly fine to use Hellos on multiple VLANs for discovery > and send LSP only on one VLAN, one of the common ones. > > Can we then conclude that by default we send Hellos on a set > of one or more configured VLANs with the set being equal to > the active set of VLANs on that link by default ? > > Thanks, > > Dinesh > On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote: > > > -----Original Message----- > > > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > > > Sent: Tuesday, October 23, 2007 7:21 AM > > > To: Silvano Gai > > > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid > router/bridge. > > > Subject: Re: [rbridge] Final outcome of outer VLAN > > > tagsonRBridge-RBridgepackets? > > > > > > I agree that using a single VLAN solution for IS-IS DRB is weak. > > > However, I'm skeptical that another protocol that also just sends > > > Hellos is much more scalabale or better than IS-IS sending only > > > Hellos on all configured VLANs. > > > > Dinesh, > > > > The key here is just sending hellos as opposed to > maintaining a full > > IS-IS adjacency on the VLAN. As long maintaining the > adjancency and > > sending LSPs on every VLAN is not required, the protocol > that is used > > for it doesn't matter. > > > > Anoop > -- > "And those who were seen dancing were thought to be insane by > those who could not hear the music." -- Angela Monet > Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9NLEWFI025059 for <rbridge@postel.org>; Tue, 23 Oct 2007 14:14:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1193174071!20380031!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28651 invoked from network); 23 Oct 2007 21:14:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 23 Oct 2007 21:14:31 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9NLESN0019136 for <rbridge@postel.org>; Tue, 23 Oct 2007 14:14:30 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l9NLESdS015766 for <rbridge@postel.org>; Tue, 23 Oct 2007 16:14:28 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l9NLERf2015759 for <rbridge@postel.org>; Tue, 23 Oct 2007 16:14:27 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 23 Oct 2007 17:14:27 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6086@de01exm64.ds.mot.com> In-Reply-To: <18205.1801.701032.716262@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Thread-Index: AcgU7byAbjGxztA3SkKpWC9GGoU2+AAy4d/w References: <471AD7EB.10702@sun.com><3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com><18204.52048.420420.121051@gargle.gargle.HOWL><3870C46029D1F945B1472F170D2D9790032A5C98@de01exm64.ds.mot.com><18204.63842.478635.230742@gargle.gargle.HOWL><3870C46029D1F945B1472F170D2D9790032A5DD3@de01exm64.ds.mot.com> <18205.1801.701032.716262@gargle.gargle.HOWL> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "James Carlson" <james.d.carlson@sun.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NLEWFI025059 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 21:14:55 -0000 Status: RO Content-Length: 2257 Sorry, my smiley was in connection with the "not yet specified"ness, not to say that corruption isn't a serious problem when it occurs. At transit Rbridges, TRILL data frames can normally be transmitted unchanged from how they are received, including the FCS, or with only a change in VLAN (or possibly priority) for which the FCS adjustment shouldn't be too hard. Donald -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com] Sent: Monday, October 22, 2007 4:25 PM To: Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge. Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Eastlake III Donald-LDE008 writes: > Well, it doesn't seem that different from the situation with 802.1Q > bridges inserting and deleting C and S tags or 802.1AE interfaces > inserting or removing security tags or whatever. It's not. That's exactly why I said: That's not necessarily a horrible thing, in as much as most VLAN-capable bridges already do this today, but still a knowing choice. > But I guess I don't see any problem with putting in a sentence about > this. OK; thanks. > PS: :-) I suppose people that are really worried about corruption or > tampering with data inside their Rbridges should use the as yet to be > specified security option of the as yet to be fully specified option > feature... I know you have a smiley there, but the lingering concern is about message integrity being compromised by inadvertent errors rather than protection from some sort of active attack. End-to-end preservation of FCS does provide protection against simple blunders. Regeneration at each node does not. I wouldn't have made as big a deal out of it if we hadn't had our own frightening run-in with the problem. We had a "switch" (bridge) that enjoyed flipping bits every once in a while on large packets. The fact that it computed a new FCS on entry into the VLAN (addition of 802.1Q header) meant that the failure was hard to find and nasty in character. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9NLAnaA023534 for <rbridge@postel.org>; Tue, 23 Oct 2007 14:10:50 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2007 14:10:49 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9NLAme9016016; Tue, 23 Oct 2007 14:10:48 -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 l9NLAmsZ016231; Tue, 23 Oct 2007 21:10:48 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 14:10:48 -0700 Received: from 171.70.216.245 ([171.70.216.245]) by xmb-sjc-223.amer.cisco.com ([128.107.191.124]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Oct 2007 21:10:47 +0000 Received: from ddutt-laptop by email.cisco.com; 23 Oct 2007 14:10:48 -0700 From: Dinesh G Dutt <ddutt@cisco.com> To: Anoop Ghanwani <anoop@brocade.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <1193149257.6081.10.camel@ddutt-laptop> <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 23 Oct 2007 14:10:48 -0700 Message-Id: <1193173848.10023.42.camel@ddutt-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-OriginalArrivalTime: 23 Oct 2007 21:10:48.0111 (UTC) FILETIME=[2EF6ABF0:01C815B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1511; t=1193173848; x=1194037848; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20RE=3A=20[rbridge]=20Final=20outcome=20of=20outer=20VLAN=0A=09 tagsonRBridge-RBridgepackets? |Sender:=20; bh=ZtH0Xw/OFrJqKoK0QvGezBZlWKUpXcyxCA63ClJQijg=; b=0Wn+3eKJ8b8MZknU0l1lepdfKJ9KmUCXufgm2nEUo2H1+m5c1LkGavwLFIJhwR6Sa7JedCyP pI075RURHBlA1Hk71oQNWSjZRQfSPq9QZOFFr3jqJIfTac7f520wylW9; Authentication-Results: sj-dkim-2; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NLAnaA023534 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 21:11:39 -0000 Status: RO Content-Length: 1436 Anoop, I spoke to David Ward, an IS-IS expert here at Cisco (and a co-author on the L2 ISIS draft) and he said that it's perfectly fine to use Hellos on multiple VLANs for discovery and send LSP only on one VLAN, one of the common ones. Can we then conclude that by default we send Hellos on a set of one or more configured VLANs with the set being equal to the active set of VLANs on that link by default ? Thanks, Dinesh On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote: > > -----Original Message----- > > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > > Sent: Tuesday, October 23, 2007 7:21 AM > > To: Silvano Gai > > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN > > tagsonRBridge-RBridgepackets? > > > > I agree that using a single VLAN solution for IS-IS DRB is weak. > > However, I'm skeptical that another protocol that also just > > sends Hellos is much more scalabale or better than IS-IS > > sending only Hellos on all configured VLANs. > > Dinesh, > > The key here is just sending hellos as opposed to maintaining > a full IS-IS adjacency on the VLAN. As long maintaining the > adjancency and sending LSPs on every VLAN is not required, the > protocol that is used for it doesn't matter. > > Anoop -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? -- Angela Monet Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9NKk1Pc012911 for <rbridge@postel.org>; Tue, 23 Oct 2007 13:46:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1193172355!25286291!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2232 invoked from network); 23 Oct 2007 20:45:55 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 23 Oct 2007 20:45:55 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9NKjiNv012524 for <rbridge@postel.org>; Tue, 23 Oct 2007 13:45:54 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l9NKjiKr007988 for <rbridge@postel.org>; Tue, 23 Oct 2007 15:45:44 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9NKjhn7007979 for <rbridge@postel.org>; Tue, 23 Oct 2007 15:45:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 23 Oct 2007 16:45:42 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032E6041@de01exm64.ds.mot.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? Thread-Index: AcgTnrWi27PNk67MQpm5GuL1S8AbDABNgLkgABOuRiAAIBzRwA== References: <471AD9CE.7020405@sun.com><4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Silvano Gai" <sgai@nuovasystems.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NKk1Pc012911 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 20:46:57 -0000 Status: RO Content-Length: 5594 Hi Silvano, I have two questions: (1) What exactly is the problem you see with doing adjacency on one VLAN? It could be that you think that Hellos on one VLAN would be OK but it is too much of a configuration burden to expect network administrators to figure out which VLAN and to then configure their Rbridges. Or it could be that you think that even if each port on each Rbridge was configured to the "best" single VLAN, the adjacencies found would be too sparse compared to those potentially possible. Or you could think that both of these and/or other things are the main problem... (2) If multiple Hellos on different VLANs, or some other technique, are used to learn the full VLAN connectivity, what are Rbriges supposed to do when no single VLAN will get to all the desired destinations? For example, assume that Rbridge-A is connected as follows: On VLAN 2 to B and C On VLAN 3 to C, D, and E On VLAN 4 to F, G, and H On VLAN 5 to D, E, F, and G If Rbrdige-A wants to send a multi-destination frame to all of B through H, it would seem that it has to send it at least three times to get to all the one-Rbridge-hop destinations and to avoid duplication. For example, multicast on VLANs 3 and 4 and unicast to B. Or, alternatively, multicast on VLANs 2 and 5 and unicast to H. Or, if the complexity exceeds some threshold, Rbridge-A could just forget about optimality and unicast the frame separately to B through H. How would you suggest handling such situations? Thanks, Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai Sent: Tuesday, October 23, 2007 6:21 AM To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? I want to restate that IMHO a design that sends messages on a single VLAN is so week to be completely useless. I met Anoop on a plane back from a T11 meeting and we discussed the issue of sending messages on all the configured VLANs. Anoop pointed out that, if these messages are ISIS messages, this can overload the RBrige supervisor. We identified a possible solution based on two different message types: - ISIS used on a single VLAN to compute adjacency - simple per-VLAN checking on all the VLANs to verify reachability. The second kind of messages is much simpler and therefore they load less the RBrige supervisor. In the future, per-VLAN checking can be implemented by the port ASIC. This seems a viable solution that requires design effort, but it is promising. Without the per-VLAN checking, running ISIS on a single VLAN holds water like a pasta-strainer. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Anoop Ghanwani > Sent: Monday, October 22, 2007 11:01 AM > To: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > > If we want to make implementations work with > only a single Hello for all VLANs than the > option is (a). I think that is what it should be. > Basically, as a part of RBridge configuration > there should be a "RBridge Control VLAN" configuration > that applies to the whole device. It should default > to VLAN 1, but an operator can choose to change it. > A RBridge only emits Hellos on that VLAN. If it > receives Hellos on any other VLAN that should > be detected as an error condition and reported. > > There have been some problem corner cases that > have been pointed out previously on the list > that may result in temporary duplication of > traffic when there is misconfiguration. Those > should be documented. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Saturday, October 20, 2007 9:47 PM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] Final outcome of outer VLAN tags on > > RBridge-RBridgepackets? > > > > I'm not sure I understood the final consensus on what we > > should do for outer VLAN tags on inter-RBridge packets. > > > > The possibilities I think the consensus might have been are: > > > > a) only use VLAN 1, explicit tag, no configuration possible. > > b) default is VLAN 1, explicit tag, configuration is possible > > to change sending with VLAN tag(s) something other than 1. If > > this is what was decided, I don't believe we've worked out > > the design details. I'd assume this would mean RBridges > > should be willing to receive packets from other RBridges > > regardless of outer VLAN tag. Would we then mark in the > > Hellos what VLAN tag(s) you've heard from what other RBridges > > with? What do we do with multicast if there isn't a single > > VLAN tag that seems to work to send to everyone? Would we > > allow configuration to send on a set of VLAN tags, or just on > > one at a time (and we allow configuration to say which one it is)? > > > > Certainly a) is simpler. If the consensus was b), we'd better > > work out the details. > > > > Radia > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.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.13.8/8.13.8) with ESMTP id l9NH9sRB015603 for <rbridge@postel.org>; Tue, 23 Oct 2007 10:09:54 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2007 10:09:54 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9NH9rAg031255; Tue, 23 Oct 2007 10:09:53 -0700 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 l9NH9exf004227; Tue, 23 Oct 2007 17:09:53 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:09:52 -0700 Received: from 171.70.216.245 ([171.70.216.245]) by xmb-sjc-223.amer.cisco.com ([128.107.191.124]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Oct 2007 17:09:52 +0000 Received: from ddutt-laptop by email.cisco.com; 23 Oct 2007 10:09:53 -0700 From: Dinesh G Dutt <ddutt@cisco.com> To: Anoop Ghanwani <anoop@brocade.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <1193149257.6081.10.camel@ddutt-laptop> <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 23 Oct 2007 10:09:52 -0700 Message-Id: <1193159392.10023.4.camel@ddutt-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-OriginalArrivalTime: 23 Oct 2007 17:09:52.0980 (UTC) FILETIME=[8708B940:01C81597] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1237; t=1193159393; x=1194023393; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20RE=3A=20[rbridge]=20Final=20outcome=20of=20outer=20VLAN=0A=09 tagsonRBridge-RBridgepackets? |Sender:=20; bh=mQnjBa+3NYPu7xI/111Qa4/a0Td7NGJlnpfsM35g+QY=; b=DliUdO7WF20X1z6RzGkS81Xyiv12to2BH51a5TSfrIniPpjLqY6rkIgbprNx3PKzfMc4PW6J ZSIHlY7bmXJe1gL+NcTm/KMlorwodVvdHDmTNllOizIbY6PElKpo+5wW; Authentication-Results: sj-dkim-4; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NH9sRB015603 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 17:10:29 -0000 Status: RO Content-Length: 1169 I have always thought that we need only Hellos to be per active VLAN so that we can achieve reachability. I was not planning on sending LSPs per VLAN. Dinesh On Tue, 2007-10-23 at 10:04 -0700, Anoop Ghanwani wrote: > > -----Original Message----- > > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > > Sent: Tuesday, October 23, 2007 7:21 AM > > To: Silvano Gai > > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN > > tagsonRBridge-RBridgepackets? > > > > I agree that using a single VLAN solution for IS-IS DRB is weak. > > However, I'm skeptical that another protocol that also just > > sends Hellos is much more scalabale or better than IS-IS > > sending only Hellos on all configured VLANs. > > Dinesh, > > The key here is just sending hellos as opposed to maintaining > a full IS-IS adjacency on the VLAN. As long maintaining the > adjancency and sending LSPs on every VLAN is not required, the > protocol that is used for it doesn't matter. > > Anoop -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? -- Angela Monet Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9NH5A03013667 for <rbridge@postel.org>; Tue, 23 Oct 2007 10:05:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,318,1188802800"; d="scan'208";a="13428013" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 23 Oct 2007 10:05:10 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id BB22E238381; Tue, 23 Oct 2007 10:05:10 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 10:05:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Oct 2007 10:04:12 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E8A24A0@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <1193149257.6081.10.camel@ddutt-laptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? Thread-Index: AcgVf/We+wZMJLw2RsaiGZsHfR/MowAFm+mg References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> <1193149257.6081.10.camel@ddutt-laptop> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Dinesh G Dutt" <ddutt@cisco.com>, "Silvano Gai" <sgai@nuovasystems.com> X-OriginalArrivalTime: 23 Oct 2007 17:05:10.0899 (UTC) FILETIME=[DEE69430:01C81596] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NH5A03013667 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Final outcome of outer VLAN tagsonRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 17:06:25 -0000 Status: RO Content-Length: 785 > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > Sent: Tuesday, October 23, 2007 7:21 AM > To: Silvano Gai > Cc: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN > tagsonRBridge-RBridgepackets? > > I agree that using a single VLAN solution for IS-IS DRB is weak. > However, I'm skeptical that another protocol that also just > sends Hellos is much more scalabale or better than IS-IS > sending only Hellos on all configured VLANs. Dinesh, The key here is just sending hellos as opposed to maintaining a full IS-IS adjacency on the VLAN. As long maintaining the adjancency and sending LSPs on every VLAN is not required, the protocol that is used for it doesn't matter. Anoop Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9NH2K6A012561 for <rbridge@postel.org>; Tue, 23 Oct 2007 10:02:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,318,1188802800"; d="scan'208";a="13427933" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 23 Oct 2007 10:02:16 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 984F0238381; Tue, 23 Oct 2007 10:02:16 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 10:02:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Oct 2007 10:01:17 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E8A249B@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? Thread-Index: AcgTnrWi27PNk67MQpm5GuL1S8AbDABNgLkgABOuRiAAHGkm0A== References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 23 Oct 2007 17:02:16.0546 (UTC) FILETIME=[76FA6C20:01C81596] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NH2K6A012561 Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 17:03:23 -0000 Status: RO Content-Length: 4861 Silvano, If we require the database synchronization step in Radia's other email (#e) then we don't really need per VLAN messages. Even if we have per-VLAN messages there will still be scenarios that will break and we can at best only detect them. The only case where I think the per-VLAN scheme has an advantage over the database synchronization approach is when you have 2 ports that come up _simultaneously_ on a LAN and those have the misconfiguration problem of not being able to see each other on the "RBridge control VLAN". In that case, depending on the size of the network and how long it takes an LSP to propagate, the per VLAN messages may detect the problem a bit quicker. Anoop > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Tuesday, October 23, 2007 3:21 AM > To: Anoop Ghanwani; Radia Perlman; Developing a hybrid router/bridge. > Subject: RE: [rbridge] Final outcome of outer VLAN tags > onRBridge-RBridgepackets? > > > I want to restate that IMHO a design that sends messages on a > single VLAN is so week to be completely useless. > > I met Anoop on a plane back from a T11 meeting and we > discussed the issue of sending messages on all the configured > VLANs. Anoop pointed out that, if these messages are ISIS > messages, this can overload the RBrige supervisor. > > We identified a possible solution based on two different > message types: > - ISIS used on a single VLAN to compute adjacency > - simple per-VLAN checking on all the VLANs to verify reachability. > > The second kind of messages is much simpler and therefore > they load less the RBrige supervisor. In the future, per-VLAN > checking can be implemented by the port ASIC. This seems a > viable solution that requires design effort, but it is promising. > > Without the per-VLAN checking, running ISIS on a single VLAN > holds water like a pasta-strainer. > > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Anoop Ghanwani > > Sent: Monday, October 22, 2007 11:01 AM > > To: Radia Perlman; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > RBridgepackets? > > > > > > If we want to make implementations work with only a single > Hello for > > all VLANs than the option is (a). I think that is what it > should be. > > Basically, as a part of RBridge configuration there should be a > > "RBridge Control VLAN" configuration that applies to the > whole device. > > It should default to VLAN 1, but an operator can choose to > change it. > > A RBridge only emits Hellos on that VLAN. If it receives Hellos on > > any other VLAN that should be detected as an error condition and > > reported. > > > > There have been some problem corner cases that have been > pointed out > > previously on the list that may result in temporary duplication of > > traffic when there is misconfiguration. Those should be documented. > > > > Anoop > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > Sent: Saturday, October 20, 2007 9:47 PM > > > To: Developing a hybrid router/bridge. > > > Subject: [rbridge] Final outcome of outer VLAN tags on > > > RBridge-RBridgepackets? > > > > > > I'm not sure I understood the final consensus on what we > should do > > > for outer VLAN tags on inter-RBridge packets. > > > > > > The possibilities I think the consensus might have been are: > > > > > > a) only use VLAN 1, explicit tag, no configuration possible. > > > b) default is VLAN 1, explicit tag, configuration is possible to > > > change sending with VLAN tag(s) something other than 1. > If this is > > > what was decided, I don't believe we've worked out the design > > > details. I'd assume this would mean RBridges should be willing to > > > receive packets from other RBridges regardless of outer VLAN tag. > > > Would we then mark in the Hellos what VLAN tag(s) you've > heard from > > > what other RBridges with? What do we do with multicast if there > > > isn't a single VLAN tag that seems to work to send to everyone? > > > Would we allow configuration to send on a set of VLAN > tags, or just > > > on one at a time (and we allow configuration to say which one it > > > is)? > > > > > > Certainly a) is simpler. If the consensus was b), we'd > better work > > > out the details. > > > > > > Radia > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.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.13.8/8.13.8) with ESMTP id l9NEL9hQ009296 for <rbridge@postel.org>; Tue, 23 Oct 2007 07:21:09 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2007 07:21:08 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9NEL7CS009524; Tue, 23 Oct 2007 07:21:07 -0700 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 l9NEKnxD024591; Tue, 23 Oct 2007 14:21:06 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 07:20:58 -0700 Received: from 10.21.115.248 ([10.21.115.248]) by xmb-sjc-223.amer.cisco.com ([128.107.191.124]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Oct 2007 14:20:58 +0000 Received: from ddutt-laptop by email.cisco.com; 23 Oct 2007 07:20:58 -0700 From: Dinesh G Dutt <ddutt@cisco.com> To: Silvano Gai <sgai@nuovasystems.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 23 Oct 2007 07:20:57 -0700 Message-Id: <1193149257.6081.10.camel@ddutt-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-OriginalArrivalTime: 23 Oct 2007 14:20:58.0917 (UTC) FILETIME=[EEA96D50:01C8157F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4547; t=1193149267; x=1194013267; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Final=20outcome=20of=20outer=20VLAN=20tag s=0A=09onRBridge-RBridgepackets? |Sender:=20; bh=vyl8ifEjCW+9dKRfMcintMMdcxA2wb82dx18E1LG1qI=; b=bAWve1JRir/IxR97MJsoVdUGCt7LSLGglOFiibjeo3jsBxZFUjqMddDG9JJA6FAkyJW6r0v4 0bLtKn/jUpZ+q99Slicr6GGREb3SsN5vseBOepb4RpmOmddywB/nMEoG; Authentication-Results: sj-dkim-2; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NEL9hQ009296 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 14:21:48 -0000 Status: RO Content-Length: 4392 I agree that using a single VLAN solution for IS-IS DRB is weak. However, I'm skeptical that another protocol that also just sends Hellos is much more scalabale or better than IS-IS sending only Hellos on all configured VLANs. Dinesh On Tue, 2007-10-23 at 03:20 -0700, Silvano Gai wrote: > I want to restate that IMHO a design that sends messages on a single > VLAN is so week to be completely useless. > > I met Anoop on a plane back from a T11 meeting and we discussed the > issue of sending messages on all the configured VLANs. Anoop pointed out > that, if these messages are ISIS messages, this can overload the RBrige > supervisor. > > We identified a possible solution based on two different message types: > - ISIS used on a single VLAN to compute adjacency > - simple per-VLAN checking on all the VLANs to verify reachability. > > The second kind of messages is much simpler and therefore they load less > the RBrige supervisor. In the future, per-VLAN checking can be > implemented by the port ASIC. This seems a viable solution that requires > design effort, but it is promising. > > Without the per-VLAN checking, running ISIS on a single VLAN holds water > like a pasta-strainer. > > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Anoop Ghanwani > > Sent: Monday, October 22, 2007 11:01 AM > > To: Radia Perlman; Developing a hybrid router/bridge. > > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > > RBridgepackets? > > > > > > If we want to make implementations work with > > only a single Hello for all VLANs than the > > option is (a). I think that is what it should be. > > Basically, as a part of RBridge configuration > > there should be a "RBridge Control VLAN" configuration > > that applies to the whole device. It should default > > to VLAN 1, but an operator can choose to change it. > > A RBridge only emits Hellos on that VLAN. If it > > receives Hellos on any other VLAN that should > > be detected as an error condition and reported. > > > > There have been some problem corner cases that > > have been pointed out previously on the list > > that may result in temporary duplication of > > traffic when there is misconfiguration. Those > > should be documented. > > > > Anoop > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > Sent: Saturday, October 20, 2007 9:47 PM > > > To: Developing a hybrid router/bridge. > > > Subject: [rbridge] Final outcome of outer VLAN tags on > > > RBridge-RBridgepackets? > > > > > > I'm not sure I understood the final consensus on what we > > > should do for outer VLAN tags on inter-RBridge packets. > > > > > > The possibilities I think the consensus might have been are: > > > > > > a) only use VLAN 1, explicit tag, no configuration possible. > > > b) default is VLAN 1, explicit tag, configuration is possible > > > to change sending with VLAN tag(s) something other than 1. If > > > this is what was decided, I don't believe we've worked out > > > the design details. I'd assume this would mean RBridges > > > should be willing to receive packets from other RBridges > > > regardless of outer VLAN tag. Would we then mark in the > > > Hellos what VLAN tag(s) you've heard from what other RBridges > > > with? What do we do with multicast if there isn't a single > > > VLAN tag that seems to work to send to everyone? Would we > > > allow configuration to send on a set of VLAN tags, or just on > > > one at a time (and we allow configuration to say which one it is)? > > > > > > Certainly a) is simpler. If the consensus was b), we'd better > > > work out the details. > > > > > > Radia > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? -- Angela Monet Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9NAKYYT004555 for <rbridge@postel.org>; Tue, 23 Oct 2007 03:20:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Oct 2007 03:20:34 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2024C31CF@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? thread-index: AcgTnrWi27PNk67MQpm5GuL1S8AbDABNgLkgABOuRiA= References: <471AD9CE.7020405@sun.com> <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9NAKYYT004555 Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 10:21:30 -0000 Status: RO Content-Length: 3644 I want to restate that IMHO a design that sends messages on a single VLAN is so week to be completely useless. I met Anoop on a plane back from a T11 meeting and we discussed the issue of sending messages on all the configured VLANs. Anoop pointed out that, if these messages are ISIS messages, this can overload the RBrige supervisor. We identified a possible solution based on two different message types: - ISIS used on a single VLAN to compute adjacency - simple per-VLAN checking on all the VLANs to verify reachability. The second kind of messages is much simpler and therefore they load less the RBrige supervisor. In the future, per-VLAN checking can be implemented by the port ASIC. This seems a viable solution that requires design effort, but it is promising. Without the per-VLAN checking, running ISIS on a single VLAN holds water like a pasta-strainer. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Anoop Ghanwani > Sent: Monday, October 22, 2007 11:01 AM > To: Radia Perlman; Developing a hybrid router/bridge. > Subject: Re: [rbridge] Final outcome of outer VLAN tags onRBridge- > RBridgepackets? > > > If we want to make implementations work with > only a single Hello for all VLANs than the > option is (a). I think that is what it should be. > Basically, as a part of RBridge configuration > there should be a "RBridge Control VLAN" configuration > that applies to the whole device. It should default > to VLAN 1, but an operator can choose to change it. > A RBridge only emits Hellos on that VLAN. If it > receives Hellos on any other VLAN that should > be detected as an error condition and reported. > > There have been some problem corner cases that > have been pointed out previously on the list > that may result in temporary duplication of > traffic when there is misconfiguration. Those > should be documented. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Saturday, October 20, 2007 9:47 PM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] Final outcome of outer VLAN tags on > > RBridge-RBridgepackets? > > > > I'm not sure I understood the final consensus on what we > > should do for outer VLAN tags on inter-RBridge packets. > > > > The possibilities I think the consensus might have been are: > > > > a) only use VLAN 1, explicit tag, no configuration possible. > > b) default is VLAN 1, explicit tag, configuration is possible > > to change sending with VLAN tag(s) something other than 1. If > > this is what was decided, I don't believe we've worked out > > the design details. I'd assume this would mean RBridges > > should be willing to receive packets from other RBridges > > regardless of outer VLAN tag. Would we then mark in the > > Hellos what VLAN tag(s) you've heard from what other RBridges > > with? What do we do with multicast if there isn't a single > > VLAN tag that seems to work to send to everyone? Would we > > allow configuration to send on a set of VLAN tags, or just on > > one at a time (and we allow configuration to say which one it is)? > > > > Certainly a) is simpler. If the consensus was b), we'd better > > work out the details. > > > > Radia > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9N0Nj73024048 for <rbridge@postel.org>; Mon, 22 Oct 2007 17:23:45 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQC00GDK93AQ100@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 22 Oct 2007 17:23:34 -0700 (PDT) Received: from [129.145.154.106] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQC0063Y93AZ0G0@mail.sunlabs.com> for rbridge@postel.org; Mon, 22 Oct 2007 17:23:34 -0700 (PDT) Date: Mon, 22 Oct 2007 17:23:34 -0700 From: Radia.Perlman@sun.com In-reply-to: <46EF44C9.5030009@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <471D3F06.4080807@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aZKPm/MXYup5zLLATOxNmg)" X-Accept-Language: en-us, en References: <46E82549.7030102@sun.com> <46EADE53.2020305@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2020B8099@nuova-ex1.hq.nuovaimpresa.com> <46EC77A1.3070904@cisco.com> <46EF44C9.5030009@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Ambition with different VLAN configurations X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 23 Oct 2007 00:24:22 -0000 Status: RO Content-Length: 11529 This is a multi-part message in MIME format. --Boundary_(ID_aZKPm/MXYup5zLLATOxNmg) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT This goes along with the previous question I just posted, with subject line "Final outcome of outer VLAN tags on RBridge-RBridge packets?" After rereading the thread with this subject line, there were a few "Hmm, have to think about that" comments, and one person who seemed unhappy with not letting the VLAN be configurable, and then the thread seemed to just peter out. So I will reiterate what I think the details of the proposal are, along with a counterproposal if people *really* want it configurable. Though I prefer not configurable. Before editing the spec, I would like people to explicitly say whether they're happy with the proposal below, or if not, whether they're happy with the additional proposal below the line of stars, and perhaps they could say "I could live with either, I prefer nonconfigurable", or "I could only live with configurable, and am OK with the proposal below the stars", or "I don't like either one because....and I'd like to counterpropose ..." Thanks.....Radia ---------Nonconfigurable proposal------- a) on each layer 2 cloud, all RBrdge-RBridge communication (including IS-IS Hellos and encapsulated data packet forwarding) will be sent with one VLAN tag, VLAN 1, with an explicit outer VLAN tag. This would not be configurable. Therefore we would not need to worry about the case where there are different configurations of RBridges on the same cloud. b) it will be a MUST to listen to spanning tree messages and include the root bridge ID in the pseudonode LSP. Note that "listening to" either STP or RSTP is identical. In other words, an RBridge does not need to know or care whether the bridges are running STP or RSTP. As for MSTP, the only spanning tree RBridges need to listen to is the CIST (common and internal spanning tree). The only root bridge RBridges would report (in the case of MSTP) is the root bridge of the CIST. c) if R1 notices (in the link state database) a pseudonode with a root bridge that is the same as a link that R1 thinks R1 is designated on, R1 does not forward data to/from that link if R1's 6-byte IS-IS ID is less than the ID of the DRB for that pseudonode d) if R1 is DRB on a link, R1 will not decapsulate anything onto the link from ingress R2 unless R1 has received an LSP from R2 and all pseudonodes that R2 (in R2's LSP) claims to be attached to, and that R2 claims to be DRB for e) when R1 first comes up, it waits some amount of time on a link before deciding that it is DRB (several Hello intervals), and after becoming DRB, it still does not forward data off the link until it has synchronized LSP databases with its neighbors. "Synchronizing" means that it receives a CSNP from the neighbor, and winds up with LSPs at least as up-to-date as those reported in that CSNP. (Note: I think it would be a good idea to have a flag in the Hello message saying "I'd like to receive a CSNP from you" in case the neighbor sent one and it got lost -- on a LAN, the DRB should be sending them periodically, but if we have pt-to-pt links at least in current IS-IS, CSNPs are not sent periodically, though we could say RBridges should send them periodically on pt-to-pt links.) ******************** --------Proposal adding configurability------- If we *had* to make the VLAN in a) configurable, this is a suggestion for how to do it: 1) steady state on any VLAN cloud, all the RBridges would transmit on only one VLAN tag, and all would be using the same VLAN tag 2) the default would be VLAN 1 3) all RBridges would be willing to receive IS-IS Hellos with any VLAN tag (or maybe some subset that is configurable, that must always contain VLAN 1) 4) The DRB states in its Hello, what VLAN tag is to be used. If the DRB says "use VLAN 7", then all RBridges must switch to using VLAN tag 7, until they no longer hear that DRB's hellos. If they no longer hear the DRB's Hellos, (which means they think they are DRB at least temporarily) they revert to whatever they are configured to send on. "use VLAN 7" means that *all* RBridge-RBridge communication (data packet forwarding and IS-IS Hellos) will be sent using VLAN tag 7. Except (as noted in 6) below) the DRB will send its Hellos both on 7 and 1. (The reason I said this is that I think it might be safer). 5) The default is to send on VLAN 1. If you are configured to send on 7, then you send on *both* VLAN 1 and VLAN 7, until you are told by the DRB what to send on, and then you send ONLY on that one (whether it be 1, 7, or something else) 6) if you are DRB, and you are configured to send on 7, you always send both on 1 and 7, and report in your Hello "send on 7", which will cause all the other RBridges to send Hellos *only* on 7, where you will send on 1 and 7. You only report, in your Hello, the list of other RBridges on that cloud that you successfully hear Hellos from on 7 (even if you hear Hellos from them on 1 or some other VLAN tag) *However* I still recommend making VLAN 1 *not* configurable. I'd think if a customer is willing to do fancy configuration, and wanted to keep RBridge-RBridge traffic off VLAN 1, or wanted VLAN 1 to be partitioned on a layer 2 cloud, then that customer could renumber the use of their VLANs to make VLAN 1 be one that is not partitioned, and that is OK to send RBridge traffic on. But at any rate -- I want to make sure we all agree to one design. Radia --Boundary_(ID_aZKPm/MXYup5zLLATOxNmg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <small>This goes along with the previous question I just posted, with subject line<br> "Final outcome of outer VLAN tags on RBridge-RBridge packets?"</small><br> <br> <small>After rereading the thread with this subject line, there were a few "Hmm, have to think<br> about that" comments, and one person who seemed unhappy with<br> not letting the VLAN be configurable, and then the thread seemed to just<br> peter out.<br> So I will<br> reiterate what I think the details of the proposal are, along with<br> a counterproposal if people *really* want it configurable. Though I<br> prefer not configurable. Before editing the spec, I would like people<br> to explicitly say whether they're happy with the proposal below, or<br> if not, whether they're happy with the additional proposal below the<br> line of stars, and perhaps they could say "I could live with either, I<br> prefer nonconfigurable", or "I could only live with configurable, and<br> am OK with the proposal below the stars", or "I don't like either one<br> because....and I'd like to counterpropose ..."<br> <br> Thanks.....Radia<br> <br> <big>---------Nonconfigurable proposal-------<br> </big></small><br> <small>a) on each layer 2 cloud, all RBrdge-RBridge communication (including</small><br> <small>IS-IS Hellos and encapsulated data packet forwarding) will be sent with <br> </small> <pre wrap="">one VLAN tag, VLAN 1, with an explicit outer VLAN tag. This would not be configurable. Therefore we would not need to worry about the case where there are different configurations of RBridges on the same cloud. b) it will be a MUST to listen to spanning tree messages and include the root bridge ID in the pseudonode LSP. Note that "listening to" either STP or RSTP is identical. In other words, an RBridge does not need to know or care whether the bridges are running STP or RSTP. As for MSTP, the only spanning tree RBridges need to listen to is the CIST (common and internal spanning tree). The only root bridge RBridges would report (in the case of MSTP) is the root bridge of the CIST. c) if R1 notices (in the link state database) a pseudonode with a root bridge that is the same as a link that R1 thinks R1 is designated on, R1 does not forward data to/from that link if R1's 6-byte IS-IS ID is less than the ID of the DRB for that pseudonode d) if R1 is DRB on a link, R1 will not decapsulate anything onto the link from ingress R2 unless R1 has received an LSP from R2 and all pseudonodes that R2 (in R2's LSP) claims to be attached to, and that R2 claims to be DRB for e) when R1 first comes up, it waits some amount of time on a link before deciding that it is DRB (several Hello intervals), and after becoming DRB, it still does not forward data off the link until it has synchronized LSP databases with its neighbors. "Synchronizing" means that it receives a CSNP from the neighbor, and winds up with LSPs at least as up-to-date as those reported in that CSNP. (Note: I think it would be a good idea to have a flag in the Hello message saying "I'd like to receive a CSNP from you" in case the neighbor sent one and it got lost -- on a LAN, the DRB should be sending them periodically, but if we have pt-to-pt links at least in current IS-IS, CSNPs are not sent periodically, though we could say RBridges should send them periodically on pt-to-pt links.) ******************** <big>--------Proposal adding configurability-------</big> If we *had* to make the VLAN in a) configurable, this is a suggestion for how to do it: 1) steady state on any VLAN cloud, all the RBridges would transmit on only one VLAN tag, and all would be using the same VLAN tag 2) the default would be VLAN 1 3) all RBridges would be willing to receive IS-IS Hellos with any VLAN tag (or maybe some subset that is configurable, that must always contain VLAN 1) 4) The DRB states in its Hello, what VLAN tag is to be used. If the DRB says "use VLAN 7", then all RBridges must switch to using VLAN tag 7, until they no longer hear that DRB's hellos. If they no longer hear the DRB's Hellos, (which means they think they are DRB at least temporarily) they revert to whatever they are configured to send on. "use VLAN 7" means that *all* RBridge-RBridge communication (data packet forwarding and IS-IS Hellos) will be sent using VLAN tag 7. Except (as noted in 6) below) the DRB will send its Hellos both on 7 and 1. (The reason I said this is that I think it might be safer). 5) The default is to send on VLAN 1. If you are configured to send on 7, then you send on *both* VLAN 1 and VLAN 7, until you are told by the DRB what to send on, and then you send ONLY on that one (whether it be 1, 7, or something else) 6) if you are DRB, and you are configured to send on 7, you always send both on 1 and 7, and report in your Hello "send on 7", which will cause all the other RBridges to send Hellos *only* on 7, where you will send on 1 and 7. You only report, in your Hello, the list of other RBridges on that cloud that you successfully hear Hellos from on 7 (even if you hear Hellos from them on 1 or some other VLAN tag) *However* I still recommend making VLAN 1 *not* configurable. I'd think if a customer is willing to do fancy configuration, and wanted to keep RBridge-RBridge traffic off VLAN 1, or wanted VLAN 1 to be partitioned on a layer 2 cloud, then that customer could renumber the use of their VLANs to make VLAN 1 be one that is not partitioned, and that is OK to send RBridge traffic on. But at any rate -- I want to make sure we all agree to one design. Radia </pre> <br> </body> </html> --Boundary_(ID_aZKPm/MXYup5zLLATOxNmg)-- Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MKtCUY007488 for <rbridge@postel.org>; Mon, 22 Oct 2007 13:55:12 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9MKtBfD003026 for <rbridge@postel.org>; Mon, 22 Oct 2007 20:55:11 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9MKtB6Z051949 for <rbridge@postel.org>; Mon, 22 Oct 2007 16:55:11 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MKOgA4016049; Mon, 22 Oct 2007 16:24:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9MKOf1p016046; Mon, 22 Oct 2007 16:24:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18205.1801.701032.716262@gargle.gargle.HOWL> Date: Mon, 22 Oct 2007 16:24:41 -0400 From: James Carlson <james.d.carlson@sun.com> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032A5DD3@de01exm64.ds.mot.com> References: <471AD7EB.10702@sun.com> <3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com> <18204.52048.420420.121051@gargle.gargle.HOWL> <3870C46029D1F945B1472F170D2D9790032A5C98@de01exm64.ds.mot.com> <18204.63842.478635.230742@gargle.gargle.HOWL> <3870C46029D1F945B1472F170D2D9790032A5DD3@de01exm64.ds.mot.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 20:56:38 -0000 Status: RO Content-Length: 1603 Eastlake III Donald-LDE008 writes: > Well, it doesn't seem that different from the situation with 802.1Q > bridges inserting and deleting C and S tags or 802.1AE interfaces > inserting or removing security tags or whatever. It's not. That's exactly why I said: That's not necessarily a horrible thing, in as much as most VLAN-capable bridges already do this today, but still a knowing choice. > But I guess I don't see any problem with putting in a sentence about > this. OK; thanks. > PS: :-) I suppose people that are really worried about corruption or > tampering with data inside their Rbridges should use the as yet to be > specified security option of the as yet to be fully specified option > feature... I know you have a smiley there, but the lingering concern is about message integrity being compromised by inadvertent errors rather than protection from some sort of active attack. End-to-end preservation of FCS does provide protection against simple blunders. Regeneration at each node does not. I wouldn't have made as big a deal out of it if we hadn't had our own frightening run-in with the problem. We had a "switch" (bridge) that enjoyed flipping bits every once in a while on large packets. The fact that it computed a new FCS on entry into the VLAN (addition of 802.1Q header) meant that the failure was hard to find and nasty in character. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9MKDjBQ020999 for <rbridge@postel.org>; Mon, 22 Oct 2007 13:13:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1193084024!27113938!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 16850 invoked from network); 22 Oct 2007 20:13:44 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-15.tower-119.messagelabs.com with SMTP; 22 Oct 2007 20:13:44 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l9MKDhjR019290 for <rbridge@postel.org>; Mon, 22 Oct 2007 13:13:43 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l9MKDg8Q003742 for <rbridge@postel.org>; Mon, 22 Oct 2007 15:13:43 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9MKDffw003716 for <rbridge@postel.org>; Mon, 22 Oct 2007 15:13:42 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 22 Oct 2007 16:13:41 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A5DD3@de01exm64.ds.mot.com> In-Reply-To: <18204.63842.478635.230742@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Thread-Index: AcgU5LL+Y/X2vAoqRC+xbeheGB7zHgAArOhA References: <471AD7EB.10702@sun.com><3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com><18204.52048.420420.121051@gargle.gargle.HOWL><3870C46029D1F945B1472F170D2D9790032A5C98@de01exm64.ds.mot.com> <18204.63842.478635.230742@gargle.gargle.HOWL> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "James Carlson" <james.d.carlson@sun.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9MKDjBQ020999 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 20:14:10 -0000 Status: RO Content-Length: 2502 Well, it doesn't seem that different from the situation with 802.1Q bridges inserting and deleting C and S tags or 802.1AE interfaces inserting or removing security tags or whatever. But I guess I don't see any problem with putting in a sentence about this. Thanks, Donald PS: :-) I suppose people that are really worried about corruption or tampering with data inside their Rbridges should use the as yet to be specified security option of the as yet to be fully specified option feature... -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com] Sent: Monday, October 22, 2007 3:26 PM To: Eastlake III Donald-LDE008 Cc: Developing a hybrid router/bridge. Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Eastlake III Donald-LDE008 writes: > Another strategy is to keep the FCS on admitting a frame and whenever > you delete, insert, or change anything in the frame during processing to > do a compensating adjustment to the FCS, then transmit this modified FCS > with the frame. That's a tall order with insert or delete, though there seem to be (encumbered) mechanisms available. I suspect that most implementations will simply recompute unless a suitable adjustment algorithm is suggested as part of the final document. > This alternative to generating it from scratch when the > frame leaves the bridge/Rbridge would have a reasonable chance of > detecting something like memory corruption within the device. Sure. I doubt that we'll see this in practice, though, and I think we need to be aware that what we are really endorsing here is breaking the end-to-end CRC argument for Ethernet subnetworks. That's not necessarily a horrible thing, in as much as most VLAN-capable bridges already do this today, but still a knowing choice. > But I don't think we should say anything about which strategy Rbridge > implementations use other than requiring them to send frames with > correct FCS values and discard received frames with bad FCS values. In as much as it affects the correctness of the bits on the wire, I think mentioning the risks of the regeneration issue is in scope for this document. It's as much in-scope as it was to create an option to _avoid_ the very same problem in RFC 3518. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MJvK2j014033 for <rbridge@postel.org>; Mon, 22 Oct 2007 12:57:20 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9MJvJ9U016122 for <rbridge@postel.org>; Mon, 22 Oct 2007 19:57:19 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9MJvJg9034605 for <rbridge@postel.org>; Mon, 22 Oct 2007 15:57:19 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MJQWEW015770; Mon, 22 Oct 2007 15:26:32 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9MJQQqm015767; Mon, 22 Oct 2007 15:26:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18204.63842.478635.230742@gargle.gargle.HOWL> Date: Mon, 22 Oct 2007 15:26:26 -0400 From: James Carlson <james.d.carlson@sun.com> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032A5C98@de01exm64.ds.mot.com> References: <471AD7EB.10702@sun.com> <3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com> <18204.52048.420420.121051@gargle.gargle.HOWL> <3870C46029D1F945B1472F170D2D9790032A5C98@de01exm64.ds.mot.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 19:57:33 -0000 Status: RO Content-Length: 1726 Eastlake III Donald-LDE008 writes: > Another strategy is to keep the FCS on admitting a frame and whenever > you delete, insert, or change anything in the frame during processing to > do a compensating adjustment to the FCS, then transmit this modified FCS > with the frame. That's a tall order with insert or delete, though there seem to be (encumbered) mechanisms available. I suspect that most implementations will simply recompute unless a suitable adjustment algorithm is suggested as part of the final document. > This alternative to generating it from scratch when the > frame leaves the bridge/Rbridge would have a reasonable chance of > detecting something like memory corruption within the device. Sure. I doubt that we'll see this in practice, though, and I think we need to be aware that what we are really endorsing here is breaking the end-to-end CRC argument for Ethernet subnetworks. That's not necessarily a horrible thing, in as much as most VLAN-capable bridges already do this today, but still a knowing choice. > But I don't think we should say anything about which strategy Rbridge > implementations use other than requiring them to send frames with > correct FCS values and discard received frames with bad FCS values. In as much as it affects the correctness of the bits on the wire, I think mentioning the risks of the regeneration issue is in scope for this document. It's as much in-scope as it was to create an option to _avoid_ the very same problem in RFC 3518. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9MIMWQO005888 for <Rbridge@postel.org>; Mon, 22 Oct 2007 11:22:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1193077347!6777188!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 13125 invoked from network); 22 Oct 2007 18:22:27 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-153.messagelabs.com with SMTP; 22 Oct 2007 18:22:27 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9MIMRlX029294 for <Rbridge@postel.org>; Mon, 22 Oct 2007 11:22:27 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l9MIMQKo010080 for <Rbridge@postel.org>; Mon, 22 Oct 2007 13:22:26 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9MIMOOo010055 for <Rbridge@postel.org>; Mon, 22 Oct 2007 13:22:25 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 22 Oct 2007 14:22:23 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A5CFE@de01exm64.ds.mot.com> In-Reply-To: <47048846.5090605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Egress processing of unicast not locally known Thread-Index: AcgGT/TieMR9BcXdTFeD5f3X6K6HCwOhW8kg References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> <47048846.5090605@cisco.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Dinesh G Dutt" <ddutt@cisco.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9MIMWQO005888 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locally known X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 18:23:01 -0000 Status: RO Content-Length: 3717 Dinesh, Could you be more specific about your worries? I don't see that this normally has much to do with "configuration". This is only about the case where an ingress Rbridge receives a unicast frame where it has learned the egress Rbridge. So it is a known unicast which it encapsulates and sends off to the egress. The Egress Rbridge receives this TRILL data frame, can see that it is supposed to be a known unicast but, for whatever reason, it does not find the original destination MAC address in its cache of learned addresses. Generally speaking, this should be a rare occurrence. But you can imagine cases where you could get a burst of these or cases where you have a chronic trickle (something sending frames at an interval just slightly longer than the address cache time out for example). The alternatives discussed at the Chicago meeting included (1) broadcasting the frame as an unknown unicast (presumably what 802.1D bridges do), (2) just dropping the frame, or (3) decapsulating the frame and sending it out on local links for which this egress Rbridge is the DRB for the VLAN of the frame. Choice (3) was the consensus in Chicago. Is that what you are disagreeing with? There was also consensus in Chicago that the SHOULD do choice (3) did not apply to a local link where the egress Rbridge knows that a station with the destination MAC address could not be on that link. SHOULD means you must do it unless you have a good reason not to. The release of the "SHOULD" requirement if you know that the MAC address can't be on that link merely gives the egress Rbridge complete freedom to act. The consensus does NOT say that the egress Rbridge "SHOULD NOT" send the frame on such a link. It is free to send it or not on whatever basis it feels like and would still be in compliance with the standard. To emphasize this, it says "This is a local decision." Do you disagree with the consensus as explained in more detail above? Thanks, Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt@cisco.com] Sent: Thursday, October 04, 2007 2:29 AM To: Eastlake III Donald-LDE008 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locally known Donald, This is different from existing IEEE 802.1D bridges. I'm OK with it, as long as it is a MAY and not a MUST or a SHOULD. I'm worried that misconfigurations and such can cause silent packet drops which can be hard to debug. Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > Egress RBridges that receive a known unicast TRILL data frame whose > inner destination address is not known locally should send the > native form of the frame out on every link for which the RBridge > is DRB for the frame's VLAN unless it knows that an end station > with that MAC address could not be on that link. (For example, > there is a layer-2 registration procedure for end stations on that > link and the destination MAC address in question is not > registered.) This is a local decision. No "error" message will be > defined for this condition at this time. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MI2PbP028002 for <rbridge@postel.org>; Mon, 22 Oct 2007 11:02:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,312,1188802800"; d="scan'208";a="20347559" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 22 Oct 2007 11:02:16 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id E03A923836D; Mon, 22 Oct 2007 11:02:15 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.87]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 11:02:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Oct 2007 11:01:17 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E8A225F@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <471AD9CE.7020405@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Final outcome of outer VLAN tags on RBridge-RBridgepackets? Thread-Index: AcgTnrWi27PNk67MQpm5GuL1S8AbDABNgLkg References: <471AD9CE.7020405@sun.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 22 Oct 2007 18:02:15.0756 (UTC) FILETIME=[ADDC88C0:01C814D5] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9MI2PbP028002 Subject: Re: [rbridge] Final outcome of outer VLAN tags on RBridge-RBridgepackets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 18:03:40 -0000 Status: RO Content-Length: 2200 If we want to make implementations work with only a single Hello for all VLANs than the option is (a). I think that is what it should be. Basically, as a part of RBridge configuration there should be a "RBridge Control VLAN" configuration that applies to the whole device. It should default to VLAN 1, but an operator can choose to change it. A RBridge only emits Hellos on that VLAN. If it receives Hellos on any other VLAN that should be detected as an error condition and reported. There have been some problem corner cases that have been pointed out previously on the list that may result in temporary duplication of traffic when there is misconfiguration. Those should be documented. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Saturday, October 20, 2007 9:47 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Final outcome of outer VLAN tags on > RBridge-RBridgepackets? > > I'm not sure I understood the final consensus on what we > should do for outer VLAN tags on inter-RBridge packets. > > The possibilities I think the consensus might have been are: > > a) only use VLAN 1, explicit tag, no configuration possible. > b) default is VLAN 1, explicit tag, configuration is possible > to change sending with VLAN tag(s) something other than 1. If > this is what was decided, I don't believe we've worked out > the design details. I'd assume this would mean RBridges > should be willing to receive packets from other RBridges > regardless of outer VLAN tag. Would we then mark in the > Hellos what VLAN tag(s) you've heard from what other RBridges > with? What do we do with multicast if there isn't a single > VLAN tag that seems to work to send to everyone? Would we > allow configuration to send on a set of VLAN tags, or just on > one at a time (and we allow configuration to say which one it is)? > > Certainly a) is simpler. If the consensus was b), we'd better > work out the details. > > Radia > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9MHenZO019292 for <rbridge@postel.org>; Mon, 22 Oct 2007 10:40:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1193074848!29957652!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2192 invoked from network); 22 Oct 2007 17:40:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 22 Oct 2007 17:40:48 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9MHelji020054 for <rbridge@postel.org>; Mon, 22 Oct 2007 10:40:47 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l9MHelqK009250 for <rbridge@postel.org>; Mon, 22 Oct 2007 12:40:47 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l9MHeknC009244 for <rbridge@postel.org>; Mon, 22 Oct 2007 12:40:46 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 22 Oct 2007 13:40:45 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A5C98@de01exm64.ds.mot.com> In-Reply-To: <18204.52048.420420.121051@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Thread-Index: AcgUyTEKf1NG/tl2SUWUwG5oCgx6wwABXeDQ References: <471AD7EB.10702@sun.com><3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com> <18204.52048.420420.121051@gargle.gargle.HOWL> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "James Carlson" <james.d.carlson@Sun.COM> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9MHenZO019292 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 17:41:19 -0000 Status: RO Content-Length: 2637 I agree it is not as simple as I made out. Another strategy is to keep the FCS on admitting a frame and whenever you delete, insert, or change anything in the frame during processing to do a compensating adjustment to the FCS, then transmit this modified FCS with the frame. This alternative to generating it from scratch when the frame leaves the bridge/Rbridge would have a reasonable chance of detecting something like memory corruption within the device. But I don't think we should say anything about which strategy Rbridge implementations use other than requiring them to send frames with correct FCS values and discard received frames with bad FCS values. Thanks, Donald -----Original Message----- From: James Carlson [mailto:james.d.carlson@Sun.COM] Sent: Monday, October 22, 2007 12:10 PM To: Eastlake III Donald-LDE008 Cc: Radia Perlman; Developing a hybrid router/bridge. Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Eastlake III Donald-LDE008 writes: > The FCS is commonly something that's buried in the port hardware and > gets generated at the time of or just before frame transmission and > checked at the time of or just after receipt and sometimes doesn't exist > in the interior of a bridge/Rbridge. > > Since Figures 3 and 7 say they are a frame as it appears on the wire, > which is what IETF protocol descriptions are normally interested in, one > and only one FCS should be shown. I'm not sure that the question or the answer are 'trivial' here. In a regular (non-VLAN) bridge, the FCS is normally preserved end-to-end, so that it protects the frame in transit from molestation by intermediate bridges. This is why RFC 3518 (PPP Bridging) contains a LAN Frame Checksum Preservation feature. With VLANs, this is no longer true, and corruption introduced by an intermediate malfunctioning bridge was in fact the cause of a significant network outage at Sun several years ago -- so I think it's not a trivial matter to commit to non-preservation of FCS. All that said, I agree with the current plan: there's a single medium-dependent FCS, checked and regenerated at hop, and thus no protection of the frame contents while resident in system memory of one of the intermediate bridges. Adding an option (sigh!) for end-to-end preservation would be nice, but may well be fighting an uphill battle in terms of functionality and compexity. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MGeNnH015035 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Mon, 22 Oct 2007 09:40:23 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9MGeIcu011900 for <rbridge@postel.org>; Mon, 22 Oct 2007 16:40:22 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9MGeHgY020791 for <rbridge@postel.org>; Mon, 22 Oct 2007 12:40:17 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MG9rba015132; Mon, 22 Oct 2007 12:09:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9MG9q7n015129; Mon, 22 Oct 2007 12:09:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18204.52048.420420.121051@gargle.gargle.HOWL> Date: Mon, 22 Oct 2007 12:09:52 -0400 From: James Carlson <james.d.carlson@Sun.COM> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com> References: <471AD7EB.10702@sun.com> <3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: carlsonj@phorcys.east.sun.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia Perlman <Radia.Perlman@Sun.COM> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2007 16:56:17 -0000 Status: RO Content-Length: 1657 Eastlake III Donald-LDE008 writes: > The FCS is commonly something that's buried in the port hardware and > gets generated at the time of or just before frame transmission and > checked at the time of or just after receipt and sometimes doesn't exist > in the interior of a bridge/Rbridge. > > Since Figures 3 and 7 say they are a frame as it appears on the wire, > which is what IETF protocol descriptions are normally interested in, one > and only one FCS should be shown. I'm not sure that the question or the answer are 'trivial' here. In a regular (non-VLAN) bridge, the FCS is normally preserved end-to-end, so that it protects the frame in transit from molestation by intermediate bridges. This is why RFC 3518 (PPP Bridging) contains a LAN Frame Checksum Preservation feature. With VLANs, this is no longer true, and corruption introduced by an intermediate malfunctioning bridge was in fact the cause of a significant network outage at Sun several years ago -- so I think it's not a trivial matter to commit to non-preservation of FCS. All that said, I agree with the current plan: there's a single medium-dependent FCS, checked and regenerated at hop, and thus no protection of the frame contents while resident in system memory of one of the intermediate bridges. Adding an option (sigh!) for end-to-end preservation would be nice, but may well be fighting an uphill battle in terms of functionality and compexity. -- James Carlson, Solaris Networking <james.d.carlson@sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9LL2NN6028765 for <rbridge@postel.org>; Sun, 21 Oct 2007 14:02:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1193000539!3775472!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16847 invoked from network); 21 Oct 2007 21:02:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 21 Oct 2007 21:02:19 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9LL2Igb023691 for <rbridge@postel.org>; Sun, 21 Oct 2007 14:02:18 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l9LL2IiF027656 for <rbridge@postel.org>; Sun, 21 Oct 2007 16:02:18 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9LL2HoX027652 for <rbridge@postel.org>; Sun, 21 Oct 2007 16:02:17 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sun, 21 Oct 2007 17:02:17 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A5A0A@de01exm64.ds.mot.com> In-Reply-To: <471AD7EB.10702@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft Thread-Index: AcgTnj5kXLaxJav7Qmy/2nw7F7BgTAAhWV6w References: <471AD7EB.10702@sun.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9LL2NN6028765 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 21 Oct 2007 21:02:51 -0000 Status: RO Content-Length: 1227 See Section 4.1.4. The FCS is commonly something that's buried in the port hardware and gets generated at the time of or just before frame transmission and checked at the time of or just after receipt and sometimes doesn't exist in the interior of a bridge/Rbridge. Since Figures 3 and 7 say they are a frame as it appears on the wire, which is what IETF protocol descriptions are normally interested in, one and only one FCS should be shown. Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Sunday, October 21, 2007 12:39 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft Figure 3 (bottom of page 9) has "Ethernet FCS". Since there are two Ethernet headers (inner and outer), wouldn't there be two Ethernet FCS's? Should the diagram simply omit "Ethernet FCS" or put it twice? Or is it correct somehow and I'm not looking at it right, or do we actually intend to omit the inner Ethernet frame's FCS? Thanks, Radia _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9L4jiN4018707 for <rbridge@postel.org>; Sat, 20 Oct 2007 21:45:44 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQ800D9HVW8V300@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 20 Oct 2007 21:45:44 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQ8006CSVW7ZKE0@mail.sunlabs.com> for rbridge@postel.org; Sat, 20 Oct 2007 21:45:44 -0700 (PDT) Date: Sat, 20 Oct 2007 21:47:10 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <471AD9CE.7020405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Final outcome of outer VLAN tags on RBridge-RBridge packets? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 21 Oct 2007 04:46:04 -0000 Status: RO Content-Length: 998 I'm not sure I understood the final consensus on what we should do for outer VLAN tags on inter-RBridge packets. The possibilities I think the consensus might have been are: a) only use VLAN 1, explicit tag, no configuration possible. b) default is VLAN 1, explicit tag, configuration is possible to change sending with VLAN tag(s) something other than 1. If this is what was decided, I don't believe we've worked out the design details. I'd assume this would mean RBridges should be willing to receive packets from other RBridges regardless of outer VLAN tag. Would we then mark in the Hellos what VLAN tag(s) you've heard from what other RBridges with? What do we do with multicast if there isn't a single VLAN tag that seems to work to send to everyone? Would we allow configuration to send on a set of VLAN tags, or just on one at a time (and we allow configuration to say which one it is)? Certainly a) is simpler. If the consensus was b), we'd better work out the details. Radia Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9L4c3Su017344 for <rbridge@postel.org>; Sat, 20 Oct 2007 21:38:03 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JQ800D9AVIUV300@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 20 Oct 2007 21:37:42 -0700 (PDT) Received: from [129.150.16.118] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQ8006OJVISZHE0@mail.sunlabs.com> for rbridge@postel.org; Sat, 20 Oct 2007 21:37:42 -0700 (PDT) Date: Sat, 20 Oct 2007 21:39:07 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <471AD7EB.10702@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 21 Oct 2007 04:38:26 -0000 Status: RO Content-Length: 347 Figure 3 (bottom of page 9) has "Ethernet FCS". Since there are two Ethernet headers (inner and outer), wouldn't there be two Ethernet FCS's? Should the diagram simply omit "Ethernet FCS" or put it twice? Or is it correct somehow and I'm not looking at it right, or do we actually intend to omit the inner Ethernet frame's FCS? Thanks, Radia Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9JKQ5Rp016803 for <Rbridge@postel.org>; Fri, 19 Oct 2007 13:26:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1192825561!3842164!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18945 invoked from network); 19 Oct 2007 20:26:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 19 Oct 2007 20:26:01 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9JKPox1005705 for <Rbridge@postel.org>; Fri, 19 Oct 2007 13:26:00 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l9JKPoM8008818 for <Rbridge@postel.org>; Fri, 19 Oct 2007 15:25:50 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9JKPnrE008810 for <Rbridge@postel.org>; Fri, 19 Oct 2007 15:25:49 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 19 Oct 2007 16:25:48 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A591B@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Milestones have been updates Thread-Index: AcgSjjw3Wd1Qbc2oS+iOKpdx1lEl2w== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9JKQ5Rp016803 Subject: [rbridge] Milestones have been updates X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 19 Oct 2007 20:26:31 -0000 Status: RO Content-Length: 147 Hi, The TRILL WG Milestones have been updated on our charter page including elimination of the Routing Requirements deliverable. Thanks, Donald Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9IGbexb015751 for <Rbridge@postel.org>; Thu, 18 Oct 2007 09:37:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1192725459!25854700!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 14713 invoked from network); 18 Oct 2007 16:37:39 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-8.tower-119.messagelabs.com with SMTP; 18 Oct 2007 16:37:39 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9IGbc47011460 for <Rbridge@postel.org>; Thu, 18 Oct 2007 09:37:38 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l9IGbbL7024884 for <Rbridge@postel.org>; Thu, 18 Oct 2007 11:37:37 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9IGbZ1D024867 for <Rbridge@postel.org>; Thu, 18 Oct 2007 11:37:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 18 Oct 2007 12:37:34 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A5335@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B4@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Call: V-field reversion Thread-Index: AcfwjUYepJIzALPJQ+iN2Xwc+rzZ5QIMbscgAxSg6SADJNA/0A== References: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com><46E00624.3060302@isi.edu><3870C46029D1F945B1472F170D2D9790030B9103@de01exm64.ds.mot.com> <3870C46029D1F945B1472F170D2D9790031840B4@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9IGbexb015751 Subject: Re: [rbridge] Consensus Call: V-field reversion X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 18 Oct 2007 16:37:46 -0000 Status: RO Content-Length: 2456 Is there any objection to the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | R |M|Op-Length| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Nickname | Ingress RBridge Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where V = version, R = reserved, and M = multi-destination. Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Tuesday, October 02, 2007 11:18 PM To: Rbridge@postel.org Subject: [rbridge] Consensus Call: V-field reversion This consensus from the Chicago meeting has been confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, September 17, 2007 1:37 AM To: Joe Touch Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Right. (I'm generally using the somewhat less formal wording from the minutes in these consensus checks.) Thanks, Donald -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Thursday, September 06, 2007 9:53 AM To: Eastlake III Donald-LDE008 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Chicago meeting for a change from protocol draft -05: > > Eliminate different V field values and revert to two version bits > and two reserved bits with the previous provisions that this draft > specifies version zero, frames with an unknown version are > discarded, reserved bits MUST be zero and are ignored on receipt. Minor nit to avoid ambiguity: ...MUST be _set to_ zero... > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9IGXx3B014146 for <Rbridge@postel.org>; Thu, 18 Oct 2007 09:33:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1192725238!22298827!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2972 invoked from network); 18 Oct 2007 16:33:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 18 Oct 2007 16:33:58 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9IGXmOL012830 for <Rbridge@postel.org>; Thu, 18 Oct 2007 09:33:58 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l9IGXlYF027332 for <Rbridge@postel.org>; Thu, 18 Oct 2007 11:33:47 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l9IGXk8G027324 for <Rbridge@postel.org>; Thu, 18 Oct 2007 11:33:47 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 18 Oct 2007 12:33:45 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032A532B@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B8@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call: Inner Multicast Address of TRILL IS-ISFrames Thread-Index: AcgFbOlHEI6K3Ud2QiSrPBf/fZ2cTQMN6rwg References: <3870C46029D1F945B1472F170D2D9790031840B8@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9IGXx3B014146 Subject: [rbridge] Consensus Call: Inner Multicast Address of TRILL IS-ISFrames X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 18 Oct 2007 16:34:09 -0000 Status: RO Content-Length: 960 This consensus from the Chicago meeting has been confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Tuesday, October 02, 2007 11:25 PM To: Rbridge@postel.org Subject: [rbridge] Consensus Check: Inner Multicast Address of TRILL IS-ISFrames This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Utilize a different multicast address ("All-IS-IS-RBridges"), allocated to RBridges, as the inner MAC destination address of TRILL IS-IS Frames. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9CKRKTK004606 for <Rbridge@postel.org>; Fri, 12 Oct 2007 13:27:20 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Oct 2007 13:27:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202404568@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <3870C46029D1F945B1472F170D2D979003219323@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Announcing Root thread-index: AcgJXgj/P6j0arLXQFebq3JJMK3pSQAXQmtgANJkOOAAAmPiUA== References: <b1cde5dcd6e.470943b6@sunlabs.com><4C94DE2070B172459E4F1EE14BD2364E7B076C@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D979003219323@de01exm64.ds.mot.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Anoop Ghanwani" <anoop@brocade.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9CKRKTK004606 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Announcing Root X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Oct 2007 20:27:52 -0000 Status: RO Content-Length: 3388 I think the reserved value apply only to the OUI inside the SNAP, not the one in the MAC address. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Friday, October 12, 2007 12:21 PM > To: Anoop Ghanwani > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Announcing Root > > I'm fine with option (b) but it seems implausible that all 0's could > ever be a normal MAC address. Among other things, the 00-00-00 OUI is > reserved for expressing arbitrary EtherTypes in the SNAP SAP format... > > Donald > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Monday, October 08, 2007 10:56 AM > To: Radia.Perlman@sun.com; Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Announcing Root > > I would prefer (a) or (b) since 0 is technically > a valid address. (b) seems best since it's explicit. > > Anoop > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia.Perlman@sun.com > > Sent: Sunday, October 07, 2007 8:38 PM > > To: Eastlake III Donald-LDE008 > > Cc: Rbridge@postel.org > > Subject: Re: [rbridge] Consensus Check: Announcing Root > > > > Good point. There might be no bridges. So there has to be a > > way of encoding that. Anything such as: > > a) leaving out the TLV in which one announces the root bridge > > b) using a flag to say "no root" > > c) using a special address, say 0 > > or I'm sure there are lots of possibilities. > > > > Radia > > > > ----- Original Message ----- > > From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> > > Date: Saturday, October 6, 2007 12:46 pm > > Subject: [rbridge] Consensus Check: Announcing Root > > > > > This is a check via the mailing list on a slight modification of an > > > apparent consensus from the minutes of the Chicago meeting for a > > > changefrom protocol draft -05. The tentative consensus at > > the Chicago > > > meeting > > > was: > > > > > > It is mandatory for an RBridge to announce the bridge root that > > > it sees out each physical port. > > > > > > Based on mailing list discussion, I would like to tweak this as > > > follows: > > > An Rbridge MUST parse BPDUs it receives on a port and announce > > > in the core IS-IS instance the bridge root that it sees out > > > each port. For MSTP (Multiple Spanning Tree Protocol), this is > > > the CIST (Common and Internal Spanning Tree) root. > > > > > > I have a question in connection with this. What is > > announced for the > > > port if no BPDU has been received recently or ever? Should > > there be a > > > "root MAC address valid" flag per port or should there some > > > conventionalvalue, like zero, which is announced? > > > > > > Thanks, > > > Donald > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@postel.org > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9CJKlkE015101 for <Rbridge@postel.org>; Fri, 12 Oct 2007 12:20:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1192216845!25113190!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 15022 invoked from network); 12 Oct 2007 19:20:45 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 12 Oct 2007 19:20:45 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l9CJKgsn009449 for <Rbridge@postel.org>; Fri, 12 Oct 2007 12:20:44 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l9CJKfbv003567 for <Rbridge@postel.org>; Fri, 12 Oct 2007 14:20:42 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9CJKe6h003546 for <Rbridge@postel.org>; Fri, 12 Oct 2007 14:20:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 12 Oct 2007 15:20:38 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003219323@de01exm64.ds.mot.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7B076C@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Announcing Root Thread-Index: AcgJXgj/P6j0arLXQFebq3JJMK3pSQAXQmtgANJkOOA= References: <b1cde5dcd6e.470943b6@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E7B076C@HQ-EXCH-5.corp.brocade.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Anoop Ghanwani" <anoop@brocade.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9CJKlkE015101 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Announcing Root X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Oct 2007 19:21:54 -0000 Status: RO Content-Length: 2705 I'm fine with option (b) but it seems implausible that all 0's could ever be a normal MAC address. Among other things, the 00-00-00 OUI is reserved for expressing arbitrary EtherTypes in the SNAP SAP format... Donald -----Original Message----- From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, October 08, 2007 10:56 AM To: Radia.Perlman@sun.com; Eastlake III Donald-LDE008 Cc: Rbridge@postel.org Subject: RE: [rbridge] Consensus Check: Announcing Root I would prefer (a) or (b) since 0 is technically a valid address. (b) seems best since it's explicit. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia.Perlman@sun.com > Sent: Sunday, October 07, 2007 8:38 PM > To: Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Announcing Root > > Good point. There might be no bridges. So there has to be a > way of encoding that. Anything such as: > a) leaving out the TLV in which one announces the root bridge > b) using a flag to say "no root" > c) using a special address, say 0 > or I'm sure there are lots of possibilities. > > Radia > > ----- Original Message ----- > From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> > Date: Saturday, October 6, 2007 12:46 pm > Subject: [rbridge] Consensus Check: Announcing Root > > > This is a check via the mailing list on a slight modification of an > > apparent consensus from the minutes of the Chicago meeting for a > > changefrom protocol draft -05. The tentative consensus at > the Chicago > > meeting > > was: > > > > It is mandatory for an RBridge to announce the bridge root that > > it sees out each physical port. > > > > Based on mailing list discussion, I would like to tweak this as > > follows: > > An Rbridge MUST parse BPDUs it receives on a port and announce > > in the core IS-IS instance the bridge root that it sees out > > each port. For MSTP (Multiple Spanning Tree Protocol), this is > > the CIST (Common and Internal Spanning Tree) root. > > > > I have a question in connection with this. What is > announced for the > > port if no BPDU has been received recently or ever? Should > there be a > > "root MAC address valid" flag per port or should there some > > conventionalvalue, like zero, which is announced? > > > > Thanks, > > Donald > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l9CIkMvv005286 for <Rbridge@postel.org>; Fri, 12 Oct 2007 11:46:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1192214780!2443476!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 18529 invoked from network); 12 Oct 2007 18:46:20 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-128.messagelabs.com with SMTP; 12 Oct 2007 18:46:20 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l9CIkKOm012547 for <Rbridge@postel.org>; Fri, 12 Oct 2007 11:46:20 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l9CIkJOS013931 for <Rbridge@postel.org>; Fri, 12 Oct 2007 13:46:19 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9CIkIRf013914 for <Rbridge@postel.org>; Fri, 12 Oct 2007 13:46:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 12 Oct 2007 14:46:16 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790032192F4@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Check: Single Pseudo-node Announcment Thread-Index: AcgFbQQ7CB53pCMuQLq7lbwJdGzn5AHkhULQ References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l9CIkMvv005286 Subject: [rbridge] Consensus Check: Single Pseudo-node Announcment X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Oct 2007 18:46:49 -0000 Status: RO Content-Length: 672 This is the last of the consensus checks via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Each RBridge which is DRB for one or more VLANs out one physical port should announce only one pseudo-node for the port. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Please also post any other comments you have on the current -05 protocol draft. If a revision can be posted in 3 or 4 weeks, we may be able to do a working group last call before the December IETF TRILL meeting. Thanks, Donald & Erik Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l98EuZNa009061 for <Rbridge@postel.org>; Mon, 8 Oct 2007 07:56:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,243,1188802800"; d="scan'208";a="19538209" Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 08 Oct 2007 07:56:30 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 07983238307; Mon, 8 Oct 2007 07:56:30 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Oct 2007 07:56:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Oct 2007 07:55:36 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7B076C@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <b1cde5dcd6e.470943b6@sunlabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Announcing Root Thread-Index: AcgJXgj/P6j0arLXQFebq3JJMK3pSQAXQmtg References: <b1cde5dcd6e.470943b6@sunlabs.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: <Radia.Perlman@sun.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-OriginalArrivalTime: 08 Oct 2007 14:56:32.0632 (UTC) FILETIME=[6A423F80:01C809BB] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l98EuZNa009061 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Announcing Root X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 08 Oct 2007 14:57:44 -0000 Status: RO Content-Length: 2236 I would prefer (a) or (b) since 0 is technically a valid address. (b) seems best since it's explicit. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia.Perlman@sun.com > Sent: Sunday, October 07, 2007 8:38 PM > To: Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Announcing Root > > Good point. There might be no bridges. So there has to be a > way of encoding that. Anything such as: > a) leaving out the TLV in which one announces the root bridge > b) using a flag to say "no root" > c) using a special address, say 0 > or I'm sure there are lots of possibilities. > > Radia > > ----- Original Message ----- > From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> > Date: Saturday, October 6, 2007 12:46 pm > Subject: [rbridge] Consensus Check: Announcing Root > > > This is a check via the mailing list on a slight modification of an > > apparent consensus from the minutes of the Chicago meeting for a > > changefrom protocol draft -05. The tentative consensus at > the Chicago > > meeting > > was: > > > > It is mandatory for an RBridge to announce the bridge root that > > it sees out each physical port. > > > > Based on mailing list discussion, I would like to tweak this as > > follows: > > An Rbridge MUST parse BPDUs it receives on a port and announce > > in the core IS-IS instance the bridge root that it sees out > > each port. For MSTP (Multiple Spanning Tree Protocol), this is > > the CIST (Common and Internal Spanning Tree) root. > > > > I have a question in connection with this. What is > announced for the > > port if no BPDU has been received recently or ever? Should > there be a > > "root MAC address valid" flag per port or should there some > > conventionalvalue, like zero, which is announced? > > > > Thanks, > > Donald > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l983cZsa004791 for <Rbridge@postel.org>; Sun, 7 Oct 2007 20:38:35 -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 <0JPK009QBQ3QKJ00@dps.sfvic.sunlabs.com> for Rbridge@postel.org; Sun, 07 Oct 2007 20:38:14 -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 <0JPK008XTQ3Q5M00@mail-srv.sfvic.sunlabs.com> for Rbridge@postel.org; Sun, 07 Oct 2007 20:38:14 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [128.64.129.137]) by mail-srv.sfvic.sunlabs.com (mshttpd); Sun, 07 Oct 2007 20:38:14 -0700 Date: Sun, 07 Oct 2007 20:38:14 -0700 From: Radia.Perlman@sun.com To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Message-id: <b1cde5dcd6e.470943b6@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 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Announcing Root X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 08 Oct 2007 03:39:01 -0000 Status: RO Content-Length: 1575 Good point. There might be no bridges. So there has to be a way of encoding that. Anything such as: a) leaving out the TLV in which one announces the root bridge b) using a flag to say "no root" c) using a special address, say 0 or I'm sure there are lots of possibilities. Radia ----- Original Message ----- From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Date: Saturday, October 6, 2007 12:46 pm Subject: [rbridge] Consensus Check: Announcing Root > This is a check via the mailing list on a slight modification of an > apparent consensus from the minutes of the Chicago meeting for a > changefrom protocol draft -05. The tentative consensus at the > Chicago meeting > was: > > It is mandatory for an RBridge to announce the bridge root that > it sees out each physical port. > > Based on mailing list discussion, I would like to tweak this as > follows: > An Rbridge MUST parse BPDUs it receives on a port and announce > in the core IS-IS instance the bridge root that it sees out > each port. For MSTP (Multiple Spanning Tree Protocol), this is > the CIST (Common and Internal Spanning Tree) root. > > I have a question in connection with this. What is announced for the > port if no BPDU has been received recently or ever? Should there be a > "root MAC address valid" flag per port or should there some > conventionalvalue, like zero, which is announced? > > Thanks, > Donald > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l97HOt0R005496 for <Rbridge@postel.org>; Sun, 7 Oct 2007 10:24:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1191777894!2046241!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20949 invoked from network); 7 Oct 2007 17:24:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 7 Oct 2007 17:24:54 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l97HOiH8006424 for <Rbridge@postel.org>; Sun, 7 Oct 2007 10:24:54 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l97HOhPn026736 for <Rbridge@postel.org>; Sun, 7 Oct 2007 12:24:43 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l97HOhnJ026728 for <Rbridge@postel.org>; Sun, 7 Oct 2007 12:24:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sun, 7 Oct 2007 13:24:41 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CB0E0@de01exm64.ds.mot.com> In-Reply-To: <4706D5A8.3020800@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHsTnQmuyJOAZLRnCAOKWYf5eJngBCaxSg References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com><3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com><4705E200.4060006@isi.edu><4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com><4706A6CA.1080207@sun.com> <4706D5A8.3020800@isi.edu> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Joe Touch" <touch@ISI.EDU> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l97HOt0R005496 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 07 Oct 2007 17:25:31 -0000 Status: RO Content-Length: 1180 I don't see why the IEEE would be interested in this. It requires that the outer MAC addresses (except for certain control frames/addresses) be insignificant. This is true for point-to-point links between Rbridges and between routers but not for point-to-point links between Bridges. The IETF does routers and Rbridges. (I was there when one of the leaders in 802.1 said in front of the 802.1 working group (not their exact words) "Oh, RBridges swap the outer addresses on each hop. They are obviously routers, not bridges.") Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Friday, October 05, 2007 8:24 PM To: Radia Perlman Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Radia Perlman wrote: ... > So I'd prefer not having this feature at all, since I don't understand > its purpose, I would really like the purpose to be explained before we explore alternative solutions. And when I say purpose, I mean: - why the IETF rbridge WG should be addressing this issue now vs., e.g., the IEEE, for some future link technology, now or in the future. Joe Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l96JkcWU003484 for <Rbridge@postel.org>; Sat, 6 Oct 2007 12:46:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1191700021!4822034!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 5891 invoked from network); 6 Oct 2007 19:47:01 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-13.tower-128.messagelabs.com with SMTP; 6 Oct 2007 19:47:01 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l96JkR1O017151 for <Rbridge@postel.org>; Sat, 6 Oct 2007 12:46:37 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l96JkQs0007191 for <Rbridge@postel.org>; Sat, 6 Oct 2007 14:46:27 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l96JkPPv007187 for <Rbridge@postel.org>; Sat, 6 Oct 2007 14:46:26 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sat, 6 Oct 2007 15:46:16 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CB0C4@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Check: Announcing Root Thread-Index: AcgFbQQ7CB53pCMuQLq7lbwJdGzn5ACQDLCQ References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l96JkcWU003484 Subject: [rbridge] Consensus Check: Announcing Root X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 19:47:39 -0000 Status: RO Content-Length: 912 This is a check via the mailing list on a slight modification of an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05. The tentative consensus at the Chicago meeting was: It is mandatory for an RBridge to announce the bridge root that it sees out each physical port. Based on mailing list discussion, I would like to tweak this as follows: An Rbridge MUST parse BPDUs it receives on a port and announce in the core IS-IS instance the bridge root that it sees out each port. For MSTP (Multiple Spanning Tree Protocol), this is the CIST (Common and Internal Spanning Tree) root. I have a question in connection with this. What is announced for the port if no BPDU has been received recently or ever? Should there be a "root MAC address valid" flag per port or should there some conventional value, like zero, which is announced? Thanks, Donald Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l963ijgI000371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Fri, 5 Oct 2007 20:44:46 -0700 (PDT) Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l963iYM5028214; Fri, 5 Oct 2007 20:44:34 -0700 (PDT) Message-ID: <47070498.4000005@isi.edu> Date: Fri, 05 Oct 2007 20:44:24 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> <4706D553.9010802@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343F8A@nuova-ex1.hq.nuovaimpresa.com> <4706DE36.8010606@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343FE0@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202343FE0@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6395B1F83F4AF6369D24C8E1" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 03:45:14 -0000 Status: RO Content-Length: 1326 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6395B1F83F4AF6369D24C8E1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Silvano Gai wrote: =2E.. >> So what do I save again? Yes, on the rewriting and additional lookup. >> But space? >=20 > At 100 Gb/s you can send 150 millions frame/s, i.e. you have 6 ns/frame= =2E And solving that problem would be a fine issue for the IEEE 802.3 HSSG. There would be a similar benefit for any pt-pt 100 gbps link, as an optimization. However, this is at the level of optimizing a single link; unless this is a pt-pt device, there would be other links with similar lookup requirements, so the benefit would be fractional anyway. This remains, as a result, (a) in the margins of a (b) future problem. Joe --------------enig6395B1F83F4AF6369D24C8E1 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBwSYE5f5cImnZrsRAsPBAKDhYHk7RgYhBpY4cl/wtltqQ2/dCwCcCZvG ZSZXEc1ppDYi/vTKC+bVt6U= =RY/L -----END PGP SIGNATURE----- --------------enig6395B1F83F4AF6369D24C8E1-- Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l962tPSP020186 for <Rbridge@postel.org>; Fri, 5 Oct 2007 19:55:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,238,1188802800"; d="scan'208";a="13136611" Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 05 Oct 2007 19:55:21 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 16C3F238301; Fri, 5 Oct 2007 19:55:21 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Oct 2007 19:55:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Oct 2007 19:54:23 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7B06BC@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202343FE0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHtGF8rAgrwoyJRImtHcpYSWaDiAABIYKgAAKiWRA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com><4705E200.4060006@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com><4706D553.9010802@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA202343F8A@nuova-ex1.hq.nuovaimpresa.com><4706DE36.8010606@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343FE0@nuova-ex1.hq.nuovaimpresa.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-OriginalArrivalTime: 06 Oct 2007 02:55:19.0711 (UTC) FILETIME=[54C302F0:01C807C4] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l962tPSP020186 Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 02:56:11 -0000 Status: RO Content-Length: 714 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > Sent: Friday, October 05, 2007 6:40 PM > To: Joe Touch > Cc: Rbridge@postel.org; Radia Perlman > Subject: Re: [rbridge] Consensus Check: Point to Point links > > At 100 Gb/s you can send 150 millions frame/s, i.e. you have > 6 ns/frame. > Any operation you save it counts. Also the memory bandwidth > saved in retrieving the rewrite information may make the > difference from being able to use off chip memory (larger) or > being forced to stay on chip (smaller). I don't understand why memory bandwidth would be an issue. We are talking a single address per port. Anoop Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l961dokZ001510 for <Rbridge@postel.org>; Fri, 5 Oct 2007 18:39:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Oct 2007 18:39:30 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202343FE0@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4706DE36.8010606@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHtGF8rAgrwoyJRImtHcpYSWaDiAABIYKg References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> <4706D553.9010802@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343F8A@nuova-ex1.hq.nuovaimpresa.com> <4706DE36.8010606@isi.edu> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l961dokZ001510 Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 01:40:00 -0000 Status: RO Content-Length: 1576 Joe, inline > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, October 05, 2007 6:01 PM > To: Silvano Gai > Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Silvano Gai wrote: > > Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Friday, October 05, 2007 5:23 PM > >> To: Silvano Gai > >> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> > >> > >> Silvano Gai wrote: > >>> Joe, > >>> > >>> If there is a bridge in between two RBridges you need to have a full > >>> adjacency table. > >>> > >>> If the link is point to point, you can save the table. > >> If the link is point to point, I still need to know what to send over > >> the link, so each side still needs adjacency information. > > > > > > This is not correct; you need to do a lookup to find the port, that is > > it. > > Otherwise you need to do a lookup to find the MAC address, rewrite the > > MAC address and then another lookup to find the port. > > So what do I save again? Yes, on the rewriting and additional lookup. > But space? > At 100 Gb/s you can send 150 millions frame/s, i.e. you have 6 ns/frame. Any operation you save it counts. Also the memory bandwidth saved in retrieving the rewrite information may make the difference from being able to use off chip memory (larger) or being forced to stay on chip (smaller). -- Silvano Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l96118tZ022641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Fri, 5 Oct 2007 18:01:08 -0700 (PDT) Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9610lv7027355; Fri, 5 Oct 2007 18:00:47 -0700 (PDT) Message-ID: <4706DE36.8010606@isi.edu> Date: Fri, 05 Oct 2007 18:00:38 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> <4706D553.9010802@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343F8A@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202343F8A@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig20CCBFAF71ABF2EE759B67F9" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 01:01:45 -0000 Status: RO Content-Length: 1640 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig20CCBFAF71ABF2EE759B67F9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Silvano Gai wrote: > Joe, >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU] >> Sent: Friday, October 05, 2007 5:23 PM >> To: Silvano Gai >> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> >> >> Silvano Gai wrote: >>> Joe, >>> >>> If there is a bridge in between two RBridges you need to have a full >>> adjacency table. >>> >>> If the link is point to point, you can save the table. >> If the link is point to point, I still need to know what to send over >> the link, so each side still needs adjacency information. >=20 >=20 > This is not correct; you need to do a lookup to find the port, that is > it. > Otherwise you need to do a lookup to find the MAC address, rewrite the > MAC address and then another lookup to find the port. So what do I save again? Yes, on the rewriting and additional lookup. But space? Joe --------------enig20CCBFAF71ABF2EE759B67F9 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBt42E5f5cImnZrsRAskxAJ912cYfBMqv87CnfSfFXD6yFIMcIQCeN9iC skO/APtWPcTT3vElX7EEpN4= =Naxr -----END PGP SIGNATURE----- --------------enig20CCBFAF71ABF2EE759B67F9-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l960SInj013940 for <Rbridge@postel.org>; Fri, 5 Oct 2007 17:28:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Oct 2007 17:27:58 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202343F8A@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4706D553.9010802@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHryRKV5EyIDfuS8+NoSFL552+zwAAELzg References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> <4706D553.9010802@isi.edu> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l960SInj013940 Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 00:28:28 -0000 Status: RO Content-Length: 6333 Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, October 05, 2007 5:23 PM > To: Silvano Gai > Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Silvano Gai wrote: > > Joe, > > > > If there is a bridge in between two RBridges you need to have a full > > adjacency table. > > > > If the link is point to point, you can save the table. > > If the link is point to point, I still need to know what to send over > the link, so each side still needs adjacency information. This is not correct; you need to do a lookup to find the port, that is it. Otherwise you need to do a lookup to find the MAC address, rewrite the MAC address and then another lookup to find the port. -- Silvano > > > When the standard will be done, 40 and 100 Gb/s links will start to be > > used. > > On these links saving the adjacency table is a big deal. > > And when those links are defined, such pt-pt links can be usefully > defined within the IEEE. > > > It is not only the silicon cost, but also the memory bandwidth. > > > > I don't see the additional complexity of a statement that says: > > "on point-to-point link the MAC address xxxxxxxxx can be used as a > > destination MAC". > > I see absolutely no need for this group to make that recommendation. > > Joe > > > > > -- Silvano > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Friday, October 05, 2007 12:05 AM > >> To: Silvano Gai > >> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> I do not understand the need to avoid a single entry per link. This is > >> hyperoptimization at the expense of complexity, and isn't useful. > >> > >> Joe > >> > >> Silvano Gai wrote: > >>> I agree with Donald on all points. > >>> The saving comes from not having to maintain an adjacency table on > > high > >>> speed point-to-point links. > >>> > >>> -- Silvano > >>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] > >>> On > >>>> Behalf Of Eastlake III Donald-LDE008 > >>>> Sent: Thursday, October 04, 2007 9:24 PM > >>>> To: Radia Perlman > >>>> Cc: Rbridge@postel.org > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links > >>>> > >>>> Hi Radia, > >>>> > >>>> See below at @@@ > >>>> > >>>> -----Original Message----- > >>>> From: Radia Perlman [mailto:Radia.Perlman@sun.com] > >>>> Sent: Thursday, October 04, 2007 11:51 AM > >>>> To: Eastlake III Donald-LDE008 > >>>> Cc: Rbridge@postel.org > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links > >>>> > >>>> Personally, I need a reminder of what we are trying to accomplish > > with > >>>> this before I can have > >>>> any opinion. > >>>> > >>>> a) Is omitting the outer VLAN tag to save space? > >>>> > >>>> @@@ Yes. The outer VLAN tag does nothing for you on a > > point-to-point > >>>> link. > >>>> > >>>> b) Why put in anything for destination address other than the MAC > >>>> address of the next hop > >>>> RBridge, or put in anything into the source address other than your > >>> own > >>>> MAC address? > >>>> It won't save space. So what does it gain? > >>>> > >>>> @@@ While no one has given a really crisp response to that > > question, > >>> it > >>>> is my impression that some believe it will make it possible to > > produce > >>>> simpler, less expensive, or more efficient hardware for this case. > >>>> > >>>> c) Is there any danger if an RBridge is confused about whether this > > is > >>> a > >>>> pt-to-pt link or not? > >>>> > >>>> @@@ I think there might be. And because of this and the extreme > >>>> commonness of the point-to-point case, it may be reasonable to > >>> consider > >>>> this in designing TRILL. For example, if a fixed MAC address were > > used > >>>> (such as the unicast version of the All-Rbridges multicast address > >>> (just > >>>> turn off the group bit)), then an interface receiving a frame with > >>> that > >>>> source address would know there was a sender on the link who > > believes > >>>> the link was point-to-point. If the receiver knows it is not > >>>> point-to-point or is unwilling to handle such frames, it could take > >>>> appropriate action. Also, Rbridge would know to never bother > >>> "learning" > >>>> the location of that MAC address. > >>>> > >>>> @@@ Thanks, > >>>> @@@ Donald > >>>> > >>>> I can see the advantage of omitting the entire outer header if it > > is > >>>> somehow absolutely > >>>> known this is a pt-to-pt link, and both ends of the link understand > >>>> this. But that isn't what's > >>>> being proposed here. It seems to be only omitting the VLAN tag, and > >>>> allowing insertion of > >>>> random addresses into the source and destination fields in the > > outer > >>>> header, if I'm reading > >>>> it correctly. > >>>> > >>>> So anyway, clarification at this point would certainly help me. > >>>> > >>>> > >>>> Eastlake III Donald-LDE008 wrote: > >>>>> This is a check via the mailing list to confirm or refute an > >>> apparent > >>>>> consensus from the minutes of the Chicago meeting for a change > > from > >>>>> protocol draft -05: > >>>>> > >>>>> If it is known that a link is a point to point link between two > >>>>> RBridges, then the outer header, if it is an Ethernet header, > > can > >>>>> have any source and/or destination addresses, those addresses > >>> will > >>>>> be ignored on receipt, and the outer VLAN tag can be omitted. > >>>>> > >>>>> If no particular controversy arises over this in the next two > > weeks, > >>>> we > >>>>> will declare it to be the working group consensus. > >>>>> > >>>>> Thanks, > >>>>> Donald & Erik > >>>>> > >>>>> _______________________________________________ > >>>>> rbridge mailing list > >>>>> rbridge@postel.org > >>>>> http://mailman.postel.org/mailman/listinfo/rbridge > >>>>> > >>>> _______________________________________________ > >>>> rbridge mailing list > >>>> rbridge@postel.org > >>>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> _______________________________________________ > >>> rbridge mailing list > >>> rbridge@postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l960NcG9013097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Fri, 5 Oct 2007 17:23:38 -0700 (PDT) Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l960MrTj018836; Fri, 5 Oct 2007 17:22:53 -0700 (PDT) Message-ID: <4706D553.9010802@isi.edu> Date: Fri, 05 Oct 2007 17:22:43 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83F16098522DF34C30EAFBB7" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 00:25:00 -0000 Status: RO Content-Length: 6218 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83F16098522DF34C30EAFBB7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Silvano Gai wrote: > Joe, >=20 > If there is a bridge in between two RBridges you need to have a full > adjacency table. >=20 > If the link is point to point, you can save the table. If the link is point to point, I still need to know what to send over the link, so each side still needs adjacency information. > When the standard will be done, 40 and 100 Gb/s links will start to be > used. > On these links saving the adjacency table is a big deal. And when those links are defined, such pt-pt links can be usefully defined within the IEEE. > It is not only the silicon cost, but also the memory bandwidth. >=20 > I don't see the additional complexity of a statement that says: > "on point-to-point link the MAC address xxxxxxxxx can be used as a > destination MAC". I see absolutely no need for this group to make that recommendation. Joe >=20 > -- Silvano >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU] >> Sent: Friday, October 05, 2007 12:05 AM >> To: Silvano Gai >> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> I do not understand the need to avoid a single entry per link. This is= >> hyperoptimization at the expense of complexity, and isn't useful. >> >> Joe >> >> Silvano Gai wrote: >>> I agree with Donald on all points. >>> The saving comes from not having to maintain an adjacency table on > high >>> speed point-to-point links. >>> >>> -- Silvano >>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] >>> On >>>> Behalf Of Eastlake III Donald-LDE008 >>>> Sent: Thursday, October 04, 2007 9:24 PM >>>> To: Radia Perlman >>>> Cc: Rbridge@postel.org >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links >>>> >>>> Hi Radia, >>>> >>>> See below at @@@ >>>> >>>> -----Original Message----- >>>> From: Radia Perlman [mailto:Radia.Perlman@sun.com] >>>> Sent: Thursday, October 04, 2007 11:51 AM >>>> To: Eastlake III Donald-LDE008 >>>> Cc: Rbridge@postel.org >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links >>>> >>>> Personally, I need a reminder of what we are trying to accomplish > with >>>> this before I can have >>>> any opinion. >>>> >>>> a) Is omitting the outer VLAN tag to save space? >>>> >>>> @@@ Yes. The outer VLAN tag does nothing for you on a > point-to-point >>>> link. >>>> >>>> b) Why put in anything for destination address other than the MAC >>>> address of the next hop >>>> RBridge, or put in anything into the source address other than your >>> own >>>> MAC address? >>>> It won't save space. So what does it gain? >>>> >>>> @@@ While no one has given a really crisp response to that > question, >>> it >>>> is my impression that some believe it will make it possible to > produce >>>> simpler, less expensive, or more efficient hardware for this case. >>>> >>>> c) Is there any danger if an RBridge is confused about whether this > is >>> a >>>> pt-to-pt link or not? >>>> >>>> @@@ I think there might be. And because of this and the extreme >>>> commonness of the point-to-point case, it may be reasonable to >>> consider >>>> this in designing TRILL. For example, if a fixed MAC address were > used >>>> (such as the unicast version of the All-Rbridges multicast address >>> (just >>>> turn off the group bit)), then an interface receiving a frame with >>> that >>>> source address would know there was a sender on the link who > believes >>>> the link was point-to-point. If the receiver knows it is not >>>> point-to-point or is unwilling to handle such frames, it could take >>>> appropriate action. Also, Rbridge would know to never bother >>> "learning" >>>> the location of that MAC address. >>>> >>>> @@@ Thanks, >>>> @@@ Donald >>>> >>>> I can see the advantage of omitting the entire outer header if it > is >>>> somehow absolutely >>>> known this is a pt-to-pt link, and both ends of the link understand >>>> this. But that isn't what's >>>> being proposed here. It seems to be only omitting the VLAN tag, and >>>> allowing insertion of >>>> random addresses into the source and destination fields in the > outer >>>> header, if I'm reading >>>> it correctly. >>>> >>>> So anyway, clarification at this point would certainly help me. >>>> >>>> >>>> Eastlake III Donald-LDE008 wrote: >>>>> This is a check via the mailing list to confirm or refute an >>> apparent >>>>> consensus from the minutes of the Chicago meeting for a change > from >>>>> protocol draft -05: >>>>> >>>>> If it is known that a link is a point to point link between two >>>>> RBridges, then the outer header, if it is an Ethernet header, > can >>>>> have any source and/or destination addresses, those addresses >>> will >>>>> be ignored on receipt, and the outer VLAN tag can be omitted. >>>>> >>>>> If no particular controversy arises over this in the next two > weeks, >>>> we >>>>> will declare it to be the working group consensus. >>>>> >>>>> Thanks, >>>>> Donald & Erik >>>>> >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge@postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge@postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >=20 --------------enig83F16098522DF34C30EAFBB7 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBtVTE5f5cImnZrsRAnlNAJ9GPfFlMT6u7J4XFcU37sfmvno0PQCeMfzz QroA18aDRY069IhtUqYeW7A= =2LfA -----END PGP SIGNATURE----- --------------enig83F16098522DF34C30EAFBB7-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l960OXkS013305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Fri, 5 Oct 2007 17:24:33 -0700 (PDT) Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l960OH2F019065; Fri, 5 Oct 2007 17:24:18 -0700 (PDT) Message-ID: <4706D5A8.3020800@isi.edu> Date: Fri, 05 Oct 2007 17:24:08 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> <4706A6CA.1080207@sun.com> In-Reply-To: <4706A6CA.1080207@sun.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig055E4A4EDC94B3320BB19FE7" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 06 Oct 2007 00:24:58 -0000 Status: RO Content-Length: 1091 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig055E4A4EDC94B3320BB19FE7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Radia Perlman wrote: =2E.. > So I'd prefer not having this feature at all, since I don't understand > its purpose,=20 I would really like the purpose to be explained before we explore alternative solutions. And when I say purpose, I mean: - why the IETF rbridge WG should be addressing this issue now vs., e.g., the IEEE, for some future link technology, now or in the futur= e. Joe --------------enig055E4A4EDC94B3320BB19FE7 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBtWoE5f5cImnZrsRArJ5AKDFUnmgccIo+EgZyHWRDb6Y+g5HQACg8EGv 7/K5Qo+E7MagYy2GBAYGnCI= =rfcL -----END PGP SIGNATURE----- --------------enig055E4A4EDC94B3320BB19FE7-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95MxACK020236 for <Rbridge@postel.org>; Fri, 5 Oct 2007 15:59:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Oct 2007 15:58:50 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA202343EFA@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4705E200.4060006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHHhcp6vpN4ueCQQe1UeFqLp8o5gAhGeHg References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l95MxACK020236 Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 22:59:28 -0000 Status: RO Content-Length: 5120 Joe, If there is a bridge in between two RBridges you need to have a full adjacency table. If the link is point to point, you can save the table. When the standard will be done, 40 and 100 Gb/s links will start to be used. On these links saving the adjacency table is a big deal. It is not only the silicon cost, but also the memory bandwidth. I don't see the additional complexity of a statement that says: "on point-to-point link the MAC address xxxxxxxxx can be used as a destination MAC". -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, October 05, 2007 12:05 AM > To: Silvano Gai > Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > I do not understand the need to avoid a single entry per link. This is > hyperoptimization at the expense of complexity, and isn't useful. > > Joe > > Silvano Gai wrote: > > I agree with Donald on all points. > > The saving comes from not having to maintain an adjacency table on high > > speed point-to-point links. > > > > -- Silvano > > > >> -----Original Message----- > >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > > On > >> Behalf Of Eastlake III Donald-LDE008 > >> Sent: Thursday, October 04, 2007 9:24 PM > >> To: Radia Perlman > >> Cc: Rbridge@postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> Hi Radia, > >> > >> See below at @@@ > >> > >> -----Original Message----- > >> From: Radia Perlman [mailto:Radia.Perlman@sun.com] > >> Sent: Thursday, October 04, 2007 11:51 AM > >> To: Eastlake III Donald-LDE008 > >> Cc: Rbridge@postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> Personally, I need a reminder of what we are trying to accomplish with > >> this before I can have > >> any opinion. > >> > >> a) Is omitting the outer VLAN tag to save space? > >> > >> @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point > >> link. > >> > >> b) Why put in anything for destination address other than the MAC > >> address of the next hop > >> RBridge, or put in anything into the source address other than your > > own > >> MAC address? > >> It won't save space. So what does it gain? > >> > >> @@@ While no one has given a really crisp response to that question, > > it > >> is my impression that some believe it will make it possible to produce > >> simpler, less expensive, or more efficient hardware for this case. > >> > >> c) Is there any danger if an RBridge is confused about whether this is > > a > >> pt-to-pt link or not? > >> > >> @@@ I think there might be. And because of this and the extreme > >> commonness of the point-to-point case, it may be reasonable to > > consider > >> this in designing TRILL. For example, if a fixed MAC address were used > >> (such as the unicast version of the All-Rbridges multicast address > > (just > >> turn off the group bit)), then an interface receiving a frame with > > that > >> source address would know there was a sender on the link who believes > >> the link was point-to-point. If the receiver knows it is not > >> point-to-point or is unwilling to handle such frames, it could take > >> appropriate action. Also, Rbridge would know to never bother > > "learning" > >> the location of that MAC address. > >> > >> @@@ Thanks, > >> @@@ Donald > >> > >> I can see the advantage of omitting the entire outer header if it is > >> somehow absolutely > >> known this is a pt-to-pt link, and both ends of the link understand > >> this. But that isn't what's > >> being proposed here. It seems to be only omitting the VLAN tag, and > >> allowing insertion of > >> random addresses into the source and destination fields in the outer > >> header, if I'm reading > >> it correctly. > >> > >> So anyway, clarification at this point would certainly help me. > >> > >> > >> Eastlake III Donald-LDE008 wrote: > >>> This is a check via the mailing list to confirm or refute an > > apparent > >>> consensus from the minutes of the Chicago meeting for a change from > >>> protocol draft -05: > >>> > >>> If it is known that a link is a point to point link between two > >>> RBridges, then the outer header, if it is an Ethernet header, can > >>> have any source and/or destination addresses, those addresses > > will > >>> be ignored on receipt, and the outer VLAN tag can be omitted. > >>> > >>> If no particular controversy arises over this in the next two weeks, > >> we > >>> will declare it to be the working group consensus. > >>> > >>> Thanks, > >>> Donald & Erik > >>> > >>> _______________________________________________ > >>> rbridge mailing list > >>> rbridge@postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> > >> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge@postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95LdaLJ024367 for <Rbridge@postel.org>; Fri, 5 Oct 2007 14:39:36 -0700 (PDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Oct 2007 17:39:24 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77024E9CDC@nekter> In-Reply-To: <4706A6CA.1080207@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHlnOr9wMwyqKURJCCFZ9JflNYRwAAG/BA References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com><3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com><4705E200.4060006@isi.edu><4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> <4706A6CA.1080207@sun.com> From: "Caitlin Bestler" <Caitlin.Bestler@neterion.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Anoop Ghanwani" <anoop@brocade.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlin.bestler@neterion.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l95LdaLJ024367 Cc: Rbridge@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 21:40:29 -0000 Status: RO Content-Length: 795 Radia Perlman wrote: -----Original Message----- I also don't understand why this is important, but to the extent with which I do understand the implementation concern, how about instead of saying you can put whatever you want in source and destination, we instead define two constant MAC addresses, one that can always be used by an RBridge in the source field, say, RBridge-from-MAC, and another that can always be used in the destination field, say RBridge-to-MAC. --------------------------------- What I like about this proposal is that any RBridge that does not care to implement this feature will just see traffic that is not addressed to it. I think the only impact beyond the RBridges that are actually implementing the feature is the need to reserve the special MAC addresses. Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95L3B94012744 for <Rbridge@postel.org>; Fri, 5 Oct 2007 14:03:11 -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 <0JPG006ZKIGR4400@dps.sfvic.sunlabs.com> for Rbridge@postel.org; Fri, 05 Oct 2007 14:02:51 -0700 (PDT) Received: from [129.150.21.138] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JPG006KTIGPZDA0@mail.sunlabs.com> for Rbridge@postel.org; Fri, 05 Oct 2007 14:02:51 -0700 (PDT) Date: Fri, 05 Oct 2007 14:04:10 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> To: Anoop Ghanwani <anoop@brocade.com> Message-id: <4706A6CA.1080207@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: Rbridge@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 21:17:25 -0000 Status: RO Content-Length: 7388 I also don't understand why this is important, but to the extent with which I do understand the implementation concern, how about instead of saying you can put whatever you want in source and destination, we instead define two constant MAC addresses, one that can always be used by an RBridge in the source field, say, RBridge-from-MAC, and another that can always be used in the destination field, say RBridge-to-MAC. So if you think it's a pt-to-pt link, and you don't want to keep track of the MAC address of your neighbor, you can fill out the outer header with those two MAC addresses. If you are confused and there are bridges on the link, nobody will get confused. If "RBridge-from-MAC" is used by multiple RBridges on the same layer 2 cloud, bridges will have confused caches about the location of that address, but that won't matter if it's never used in the destination field. There is the problem that if there are multiple RBridges on the link (and the RBridges haven't yet figured that out), then packets will get duplicated because both RBridges will pick up the packet. (the same would be true if you think you're on a pt-to-pt link with the "allow random addresses in there proposal). This (constant addresses) is safer because you wouldn't have the problem of a confused RBridge on a link with hundreds of other RBridges picking up every packet that RBridges are trying to forward to each other. So I'd prefer not having this feature at all, since I don't understand its purpose, but if we are going to do it, because (to the extent to which I understand it) an RBridge might not have a MAC address on a pt-to-pt link to use as the source, and/or the RBridge doesn't want to keep track of the next hop RBridge address to fill out the destination address, then having a constant from and to address would seem a better and less mysterious solution than saying the addresses can be any random value. Radia Anoop Ghanwani wrote: > I agree with Joe on this point. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch >> Sent: Friday, October 05, 2007 12:05 AM >> To: Silvano Gai >> Cc: Rbridge@postel.org; Radia Perlman >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> I do not understand the need to avoid a single entry per >> link. This is hyperoptimization at the expense of complexity, >> and isn't useful. >> >> Joe >> >> Silvano Gai wrote: >> >>> I agree with Donald on all points. >>> The saving comes from not having to maintain an adjacency table on >>> high speed point-to-point links. >>> >>> -- Silvano >>> >>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org >>>> >> [mailto:rbridge-bounces@postel.org] >> >>> On >>> >>>> Behalf Of Eastlake III Donald-LDE008 >>>> Sent: Thursday, October 04, 2007 9:24 PM >>>> To: Radia Perlman >>>> Cc: Rbridge@postel.org >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links >>>> >>>> Hi Radia, >>>> >>>> See below at @@@ >>>> >>>> -----Original Message----- >>>> From: Radia Perlman [mailto:Radia.Perlman@sun.com] >>>> Sent: Thursday, October 04, 2007 11:51 AM >>>> To: Eastlake III Donald-LDE008 >>>> Cc: Rbridge@postel.org >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links >>>> >>>> Personally, I need a reminder of what we are trying to accomplish >>>> with this before I can have any opinion. >>>> >>>> a) Is omitting the outer VLAN tag to save space? >>>> >>>> @@@ Yes. The outer VLAN tag does nothing for you on a >>>> >> point-to-point >> >>>> link. >>>> >>>> b) Why put in anything for destination address other than the MAC >>>> address of the next hop RBridge, or put in anything into >>>> >> the source >> >>>> address other than your >>>> >>> own >>> >>>> MAC address? >>>> It won't save space. So what does it gain? >>>> >>>> @@@ While no one has given a really crisp response to that >>>> >> question, >> >>> it >>> >>>> is my impression that some believe it will make it possible to >>>> produce simpler, less expensive, or more efficient >>>> >> hardware for this case. >> >>>> c) Is there any danger if an RBridge is confused about >>>> >> whether this >> >>>> is >>>> >>> a >>> >>>> pt-to-pt link or not? >>>> >>>> @@@ I think there might be. And because of this and the extreme >>>> commonness of the point-to-point case, it may be reasonable to >>>> >>> consider >>> >>>> this in designing TRILL. For example, if a fixed MAC address were >>>> used (such as the unicast version of the All-Rbridges multicast >>>> address >>>> >>> (just >>> >>>> turn off the group bit)), then an interface receiving a frame with >>>> >>> that >>> >>>> source address would know there was a sender on the link >>>> >> who believes >> >>>> the link was point-to-point. If the receiver knows it is not >>>> point-to-point or is unwilling to handle such frames, it >>>> >> could take >> >>>> appropriate action. Also, Rbridge would know to never bother >>>> >>> "learning" >>> >>>> the location of that MAC address. >>>> >>>> @@@ Thanks, >>>> @@@ Donald >>>> >>>> I can see the advantage of omitting the entire outer >>>> >> header if it is >> >>>> somehow absolutely known this is a pt-to-pt link, and both ends of >>>> the link understand this. But that isn't what's being >>>> >> proposed here. >> >>>> It seems to be only omitting the VLAN tag, and allowing >>>> >> insertion of >> >>>> random addresses into the source and destination fields in >>>> >> the outer >> >>>> header, if I'm reading it correctly. >>>> >>>> So anyway, clarification at this point would certainly help me. >>>> >>>> >>>> Eastlake III Donald-LDE008 wrote: >>>> >>>>> This is a check via the mailing list to confirm or refute an >>>>> >>> apparent >>> >>>>> consensus from the minutes of the Chicago meeting for a >>>>> >> change from >> >>>>> protocol draft -05: >>>>> >>>>> If it is known that a link is a point to point link between two >>>>> RBridges, then the outer header, if it is an Ethernet >>>>> >> header, can >> >>>>> have any source and/or destination addresses, those addresses >>>>> >>> will >>> >>>>> be ignored on receipt, and the outer VLAN tag can be omitted. >>>>> >>>>> If no particular controversy arises over this in the next >>>>> >> two weeks, >> >>>> we >>>> >>>>> will declare it to be the working group consensus. >>>>> >>>>> Thanks, >>>>> Donald & Erik >>>>> >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge@postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge@postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >> Received: from mx20.brocade.com ([66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95Gs2dL016729 for <Rbridge@postel.org>; Fri, 5 Oct 2007 09:54:47 -0700 (PDT) Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 05 Oct 2007 09:53:52 -0700 X-IronPort-AV: i="4.21,236,1188802800"; d="scan'208"; a="13130000:sNHT32709887" Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 0AB802382F9; Fri, 5 Oct 2007 09:53:52 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Oct 2007 09:53:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Oct 2007 09:52:55 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <4705E200.4060006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHH7ZebrlEmqIRRMeL0xER19ersgAUGsbA References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Joe Touch" <touch@ISI.EDU>, "Silvano Gai" <sgai@nuovasystems.com> X-OriginalArrivalTime: 05 Oct 2007 16:53:51.0712 (UTC) FILETIME=[4EA35E00:01C80770] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l95Gs2dL016729 Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 16:55:02 -0000 Status: RO Content-Length: 4745 I agree with Joe on this point. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch > Sent: Friday, October 05, 2007 12:05 AM > To: Silvano Gai > Cc: Rbridge@postel.org; Radia Perlman > Subject: Re: [rbridge] Consensus Check: Point to Point links > > I do not understand the need to avoid a single entry per > link. This is hyperoptimization at the expense of complexity, > and isn't useful. > > Joe > > Silvano Gai wrote: > > I agree with Donald on all points. > > The saving comes from not having to maintain an adjacency table on > > high speed point-to-point links. > > > > -- Silvano > > > >> -----Original Message----- > >> From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] > > On > >> Behalf Of Eastlake III Donald-LDE008 > >> Sent: Thursday, October 04, 2007 9:24 PM > >> To: Radia Perlman > >> Cc: Rbridge@postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> Hi Radia, > >> > >> See below at @@@ > >> > >> -----Original Message----- > >> From: Radia Perlman [mailto:Radia.Perlman@sun.com] > >> Sent: Thursday, October 04, 2007 11:51 AM > >> To: Eastlake III Donald-LDE008 > >> Cc: Rbridge@postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> Personally, I need a reminder of what we are trying to accomplish > >> with this before I can have any opinion. > >> > >> a) Is omitting the outer VLAN tag to save space? > >> > >> @@@ Yes. The outer VLAN tag does nothing for you on a > point-to-point > >> link. > >> > >> b) Why put in anything for destination address other than the MAC > >> address of the next hop RBridge, or put in anything into > the source > >> address other than your > > own > >> MAC address? > >> It won't save space. So what does it gain? > >> > >> @@@ While no one has given a really crisp response to that > question, > > it > >> is my impression that some believe it will make it possible to > >> produce simpler, less expensive, or more efficient > hardware for this case. > >> > >> c) Is there any danger if an RBridge is confused about > whether this > >> is > > a > >> pt-to-pt link or not? > >> > >> @@@ I think there might be. And because of this and the extreme > >> commonness of the point-to-point case, it may be reasonable to > > consider > >> this in designing TRILL. For example, if a fixed MAC address were > >> used (such as the unicast version of the All-Rbridges multicast > >> address > > (just > >> turn off the group bit)), then an interface receiving a frame with > > that > >> source address would know there was a sender on the link > who believes > >> the link was point-to-point. If the receiver knows it is not > >> point-to-point or is unwilling to handle such frames, it > could take > >> appropriate action. Also, Rbridge would know to never bother > > "learning" > >> the location of that MAC address. > >> > >> @@@ Thanks, > >> @@@ Donald > >> > >> I can see the advantage of omitting the entire outer > header if it is > >> somehow absolutely known this is a pt-to-pt link, and both ends of > >> the link understand this. But that isn't what's being > proposed here. > >> It seems to be only omitting the VLAN tag, and allowing > insertion of > >> random addresses into the source and destination fields in > the outer > >> header, if I'm reading it correctly. > >> > >> So anyway, clarification at this point would certainly help me. > >> > >> > >> Eastlake III Donald-LDE008 wrote: > >>> This is a check via the mailing list to confirm or refute an > > apparent > >>> consensus from the minutes of the Chicago meeting for a > change from > >>> protocol draft -05: > >>> > >>> If it is known that a link is a point to point link between two > >>> RBridges, then the outer header, if it is an Ethernet > header, can > >>> have any source and/or destination addresses, those addresses > > will > >>> be ignored on receipt, and the outer VLAN tag can be omitted. > >>> > >>> If no particular controversy arises over this in the next > two weeks, > >> we > >>> will declare it to be the working group consensus. > >>> > >>> Thanks, > >>> Donald & Erik > >>> > >>> _______________________________________________ > >>> rbridge mailing list > >>> rbridge@postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> > >> > >> _______________________________________________ > >> rbridge mailing list > >> rbridge@postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l95CShQO022657 for <Rbridge@postel.org>; Fri, 5 Oct 2007 05:28:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1191587321!4840926!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 28178 invoked from network); 5 Oct 2007 12:28:42 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-6.tower-153.messagelabs.com with SMTP; 5 Oct 2007 12:28:42 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l95CSVnV011543 for <Rbridge@postel.org>; Fri, 5 Oct 2007 05:28:41 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l95CSUMv010338 for <Rbridge@postel.org>; Fri, 5 Oct 2007 07:28:30 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l95CSTLA010322 for <Rbridge@postel.org>; Fri, 5 Oct 2007 07:28:29 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 5 Oct 2007 08:28:27 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD65@de01exm64.ds.mot.com> In-Reply-To: <4705D433.5010902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgHFdHy07Qhd7VIQCC695OhXP4wbwANU8cQ References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> <4705D433.5010902@cisco.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Dinesh G Dutt" <ddutt@cisco.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l95CShQO022657 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 12:29:57 -0000 Status: RO Content-Length: 3639 I don't see any inconsistency between your statement and my statement. Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt@cisco.com] Sent: Friday, October 05, 2007 2:06 AM To: Eastlake III Donald-LDE008 Cc: Anoop Ghanwani; Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Hi Donald, BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM are identified by ethertype and there is supposedly a move to identify newer BPDUs using ethertype. The frames we're talking of sending with a fixed (or reserved) address are the data frames. BPDUs including IS-IS will use the regular MAC address. Dinesh Eastlake III Donald-LDE008 wrote: > Actually, although I'm not entirely sure, I believe that BPDUs, LLDP > PDUs, etc., all start with an Ethertype which identifies them so, in > principle, they could be made to work on a specially equipped point to > point link with no outer MAC addresses. However, I don't think anyone > has proposed that TRILL should consider omitting the outer MAC addresses > except when that suggestion appears as part of a question asking why, if > you want to do some optimization on a point-to-point link, you don't > want to do even more optimization. > > Donald > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Thursday, October 04, 2007 1:46 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > > > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >> Sent: Thursday, October 04, 2007 8:51 AM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge@postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Personally, I need a reminder of what we are trying to >> accomplish with this before I can have any opinion. >> >> a) Is omitting the outer VLAN tag to save space? >> b) Why put in anything for destination address other than the >> MAC address of the next hop RBridge, or put in anything into >> the source address other than your own MAC address? >> It won't save space. So what does it gain? >> c) Is there any danger if an RBridge is confused about >> whether this is a pt-to-pt link or not? >> >> I can see the advantage of omitting the entire outer header >> if it is somehow absolutely known this is a pt-to-pt link, >> and both ends of the link understand this. >> > > That wouldn't work because there are other frames that will > have to have MAC addresses, e.g. LACP, LLDP. > > >> But that isn't >> what's being proposed here. It seems to be only omitting the >> VLAN tag, and allowing insertion of random addresses into the >> source and destination fields in the outer header, if I'm >> reading it correctly. >> > > I don't like the idea of random addresses (is it that > a big a deal to set them correctly?), but as long as > it's completely optional, I don't really care. > [By the way, even though the proposal says that it > can be random, it really can't because we have to > say that they cannot be from the BPDU address space > or things like LACP and LLDP will break.] > > Anoop > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9575JGs017414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Fri, 5 Oct 2007 00:05:19 -0700 (PDT) Received: from [128.9.176.76] ([128.9.176.76]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9574hPL018579; Fri, 5 Oct 2007 00:04:43 -0700 (PDT) Message-ID: <4705E200.4060006@isi.edu> Date: Fri, 05 Oct 2007 00:04:32 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig96CF07652A6976A30F1E6CC0" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 07:06:50 -0000 Status: RO Content-Length: 4819 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig96CF07652A6976A30F1E6CC0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do not understand the need to avoid a single entry per link. This is hyperoptimization at the expense of complexity, and isn't useful. Joe Silvano Gai wrote: > I agree with Donald on all points. > The saving comes from not having to maintain an adjacency table on high= > speed point-to-point links. >=20 > -- Silvano >=20 >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On >> Behalf Of Eastlake III Donald-LDE008 >> Sent: Thursday, October 04, 2007 9:24 PM >> To: Radia Perlman >> Cc: Rbridge@postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Hi Radia, >> >> See below at @@@ >> >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman@sun.com] >> Sent: Thursday, October 04, 2007 11:51 AM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge@postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Personally, I need a reminder of what we are trying to accomplish with= >> this before I can have >> any opinion. >> >> a) Is omitting the outer VLAN tag to save space? >> >> @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point >> link. >> >> b) Why put in anything for destination address other than the MAC >> address of the next hop >> RBridge, or put in anything into the source address other than your > own >> MAC address? >> It won't save space. So what does it gain? >> >> @@@ While no one has given a really crisp response to that question, > it >> is my impression that some believe it will make it possible to produce= >> simpler, less expensive, or more efficient hardware for this case. >> >> c) Is there any danger if an RBridge is confused about whether this is= > a >> pt-to-pt link or not? >> >> @@@ I think there might be. And because of this and the extreme >> commonness of the point-to-point case, it may be reasonable to > consider >> this in designing TRILL. For example, if a fixed MAC address were used= >> (such as the unicast version of the All-Rbridges multicast address > (just >> turn off the group bit)), then an interface receiving a frame with > that >> source address would know there was a sender on the link who believes >> the link was point-to-point. If the receiver knows it is not >> point-to-point or is unwilling to handle such frames, it could take >> appropriate action. Also, Rbridge would know to never bother > "learning" >> the location of that MAC address. >> >> @@@ Thanks, >> @@@ Donald >> >> I can see the advantage of omitting the entire outer header if it is >> somehow absolutely >> known this is a pt-to-pt link, and both ends of the link understand >> this. But that isn't what's >> being proposed here. It seems to be only omitting the VLAN tag, and >> allowing insertion of >> random addresses into the source and destination fields in the outer >> header, if I'm reading >> it correctly. >> >> So anyway, clarification at this point would certainly help me. >> >> >> Eastlake III Donald-LDE008 wrote: >>> This is a check via the mailing list to confirm or refute an > apparent >>> consensus from the minutes of the Chicago meeting for a change from >>> protocol draft -05: >>> >>> If it is known that a link is a point to point link between two >>> RBridges, then the outer header, if it is an Ethernet header, can >>> have any source and/or destination addresses, those addresses > will >>> be ignored on receipt, and the outer VLAN tag can be omitted. >>> >>> If no particular controversy arises over this in the next two weeks, >> we >>> will declare it to be the working group consensus. >>> >>> Thanks, >>> Donald & Erik >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >> >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge --------------enig96CF07652A6976A30F1E6CC0 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBeIEE5f5cImnZrsRAomtAJ4ljDfRyJxCqOxow9ekv2i9gvcUuQCeLJsV RVe+Y/hCH0p4X0mimxR4Ni4= =+ABZ -----END PGP SIGNATURE----- --------------enig96CF07652A6976A30F1E6CC0-- Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95663VJ001155 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:06:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,233,1188802800"; d="scan'208";a="230989050" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Oct 2007 23:05:53 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9565rek018561; Thu, 4 Oct 2007 23:05:53 -0700 Received: from [10.21.113.140] (sjc-vpn2-396.cisco.com [10.21.113.140]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9565d0W016644; Fri, 5 Oct 2007 06:05:40 GMT Message-ID: <4705D433.5010902@cisco.com> Date: Thu, 04 Oct 2007 23:05:39 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3402; t=1191564353; x=1192428353; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Point=20to=20Point =20links |Sender:=20; bh=+IJllkcte5R3qqZJnzO1XPJw4y1ueyGZDE1JiFqF2AE=; b=DS7hLyps3FwKeccoAEkbsRXqxcfu2wddgmTdXMEa+TcZJ8Y2hDPGZ1oKidS5Fl/jgd1k2kOP NdbRS/kL57AaddxXc8BWLJLLPzfGkffXebDeE/HaWLijfOmcWE5Abe+H14rlAtc6bdpteNjaMa iIFKk+8hykTYpwB5Hnvxsw5/E=; Authentication-Results: sj-dkim-1; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 06:06:54 -0000 Status: RO Content-Length: 3313 Hi Donald, BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM are identified by ethertype and there is supposedly a move to identify newer BPDUs using ethertype. The frames we're talking of sending with a fixed (or reserved) address are the data frames. BPDUs including IS-IS will use the regular MAC address. Dinesh Eastlake III Donald-LDE008 wrote: > Actually, although I'm not entirely sure, I believe that BPDUs, LLDP > PDUs, etc., all start with an Ethertype which identifies them so, in > principle, they could be made to work on a specially equipped point to > point link with no outer MAC addresses. However, I don't think anyone > has proposed that TRILL should consider omitting the outer MAC addresses > except when that suggestion appears as part of a question asking why, if > you want to do some optimization on a point-to-point link, you don't > want to do even more optimization. > > Donald > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Thursday, October 04, 2007 1:46 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > > > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >> Sent: Thursday, October 04, 2007 8:51 AM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge@postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Personally, I need a reminder of what we are trying to >> accomplish with this before I can have any opinion. >> >> a) Is omitting the outer VLAN tag to save space? >> b) Why put in anything for destination address other than the >> MAC address of the next hop RBridge, or put in anything into >> the source address other than your own MAC address? >> It won't save space. So what does it gain? >> c) Is there any danger if an RBridge is confused about >> whether this is a pt-to-pt link or not? >> >> I can see the advantage of omitting the entire outer header >> if it is somehow absolutely known this is a pt-to-pt link, >> and both ends of the link understand this. >> > > That wouldn't work because there are other frames that will > have to have MAC addresses, e.g. LACP, LLDP. > > >> But that isn't >> what's being proposed here. It seems to be only omitting the >> VLAN tag, and allowing insertion of random addresses into the >> source and destination fields in the outer header, if I'm >> reading it correctly. >> > > I don't like the idea of random addresses (is it that > a big a deal to set them correctly?), but as long as > it's completely optional, I don't really care. > [By the way, even though the proposal says that it > can be random, it really can't because we have to > say that they cannot be from the BPDU address space > or things like LACP and LLDP will break.] > > Anoop > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l954s8tB009311 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:54:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 21:53:48 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGnivDxiNLgN1JTPaPI4gAWDL9rQAYkKVgAALIEIA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l954s8tB009311 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 04:54:45 -0000 Status: RO Content-Length: 3707 I agree with Donald on all points. The saving comes from not having to maintain an adjacency table on high speed point-to-point links. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Thursday, October 04, 2007 9:24 PM > To: Radia Perlman > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Hi Radia, > > See below at @@@ > > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Thursday, October 04, 2007 11:51 AM > To: Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Personally, I need a reminder of what we are trying to accomplish with > this before I can have > any opinion. > > a) Is omitting the outer VLAN tag to save space? > > @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point > link. > > b) Why put in anything for destination address other than the MAC > address of the next hop > RBridge, or put in anything into the source address other than your own > MAC address? > It won't save space. So what does it gain? > > @@@ While no one has given a really crisp response to that question, it > is my impression that some believe it will make it possible to produce > simpler, less expensive, or more efficient hardware for this case. > > c) Is there any danger if an RBridge is confused about whether this is a > > pt-to-pt link or not? > > @@@ I think there might be. And because of this and the extreme > commonness of the point-to-point case, it may be reasonable to consider > this in designing TRILL. For example, if a fixed MAC address were used > (such as the unicast version of the All-Rbridges multicast address (just > turn off the group bit)), then an interface receiving a frame with that > source address would know there was a sender on the link who believes > the link was point-to-point. If the receiver knows it is not > point-to-point or is unwilling to handle such frames, it could take > appropriate action. Also, Rbridge would know to never bother "learning" > the location of that MAC address. > > @@@ Thanks, > @@@ Donald > > I can see the advantage of omitting the entire outer header if it is > somehow absolutely > known this is a pt-to-pt link, and both ends of the link understand > this. But that isn't what's > being proposed here. It seems to be only omitting the VLAN tag, and > allowing insertion of > random addresses into the source and destination fields in the outer > header, if I'm reading > it correctly. > > So anyway, clarification at this point would certainly help me. > > > Eastlake III Donald-LDE008 wrote: > > This is a check via the mailing list to confirm or refute an apparent > > consensus from the minutes of the Chicago meeting for a change from > > protocol draft -05: > > > > If it is known that a link is a point to point link between two > > RBridges, then the outer header, if it is an Ethernet header, can > > have any source and/or destination addresses, those addresses will > > be ignored on receipt, and the outer VLAN tag can be omitted. > > > > If no particular controversy arises over this in the next two weeks, > we > > will declare it to be the working group consensus. > > > > Thanks, > > Donald & Erik > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l954TrrX023026 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:29:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1191558588!1243853!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 8708 invoked from network); 5 Oct 2007 04:29:48 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-128.messagelabs.com with SMTP; 5 Oct 2007 04:29:48 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l954Tmrk006311 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:29:48 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l954TlxU000997 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:29:47 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l954TjG1000991 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:29:46 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 5 Oct 2007 00:29:44 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD2D@de01exm64.ds.mot.com> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77024E983F@nekter> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGSiudpHVGIcRJSS2cWZ7TtrqdwgAAQycgAA2OddAAA7QrsAAF0nnwABb4F+A= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com><941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se><34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> <78C9135A3D2ECE4B8162EBDCE82CAD77024E983F@nekter> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Caitlin Bestler" <Caitlin.Bestler@neterion.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l954TrrX023026 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 04:30:41 -0000 Status: RO Content-Length: 1078 Hi Caitlin, It is my understanding that some IETF routing protocols do have special provisions for "un-numbered links" but by that they mean that IP addresses are not allocated for the ends of the links. This is a precedent for not allocating layer-N addresses for a layer-N protocol on a layer-N-point-to-point link, although in this case N=3. Layer-3 routing protocols generally aren't concerned with layer-2 addresses or even what layer-2 protocol is running on the link... Donald -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler Sent: Thursday, October 04, 2007 12:58 PM To: Silvano Gai; Eric Gray; Joe Touch Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Why wouldn't a "other end of the link" reserved MAC address be just as applicable for core Routers that are directly connected to each other point-to-point? _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l954Sebg019577 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:28:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1191558542!4642966!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 5097 invoked from network); 5 Oct 2007 04:29:02 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-128.messagelabs.com with SMTP; 5 Oct 2007 04:29:02 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l954SdFo006197 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:28:39 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l954Sc8Y000589 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:28:39 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l954SbMY000583 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:28:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 5 Oct 2007 00:28:36 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD2C@de01exm64.ds.mot.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B374C2@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgATWlnAAAtVxQAAAikIcAAN9u2A References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01B374C2@eusrcmw721.eamcs.ericsson.se> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l954Sebg019577 Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 04:29:17 -0000 Status: RO Content-Length: 7923 Eric, Well, even if a consensus of the working group wanted to do maple walnut waffle-cones with caramel, there is a problem that, as far as I can see, that isn't in our Charter. But I think that this is related enough to TRILL, as I will explain, that it would be OK to include in our output if the working group wants to do so. 802.3-like interfaces for point-to-point use as indicated here can be practical for Rbridge but not for 802.1 bridges because of the characteristics of the TRILL protocol. In TRILL, the outer VLAN tag is just an artifact for getting to the next Rbridge (or Rbridges) for TRILL EtherType frames. In a point-to-point link between Rbridges, that tag and the outer MAC addresses are not logically necessary for TRILL frames. Then tag can be omitted and the addresses can be a value ignored on receipt. However, whether you could implenent this feature is influenced by the design of TRILL. For example, I believe the current protocol spec says that local sources/sinks of frames on an Rbridge (for example SNMP) are treated as if they were on a virtual port out of the Rbridge. That means that, between two Rbridges, such frames area always encapsulated, even if we has an Rbridge with a co-located management station talking to an SNMP implementtion in a second Rbridge just one point-to-point link away. If, in this case, such frames were sent in native form, it seems to me it would at least make it a more difficult to use, for example, a fixed MAC address interface or to correctly detect when the assumption that the interface in point-to-point is incorrect. Thus, even if this feature isn't mentioned in the TRILL effect, the difficulty and perhaps even the possibility of implementing it could be affected by details of the TRILL protocol. There is also the question of whether the use of such an interface for a link should be indicated in the Rbridge MIB, although if a fixed know MAC address were used, I believe that could simply be checked for in the MIB. Donald -----Original Message----- From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Wednesday, October 03, 2007 3:10 PM To: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links Donald, Perhaps all of these things are true. So what? The argument that a lot of people would like to do X could be used to do a lot of things. I'd like us to make maple walnut waffle-cones - possibly with caramel on top. Ummm, does that sound good! What does ANY of this have to do with TRILL? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Wednesday, October 03, 2007 2:25 PM > To: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Hi Eric, > > I believe the generally understood meaning of point-to-point is a link > with exactly two devices on it, in this case RBridges. > > It is true that one could always do this sort of thing outside the > standards. But in Chicago the working group appeared to > believe this was > sufficiently important to say in the standard and, while the consensus > in the room was not that detailed, I got the general impression that > people would be favorable to, in a later management document, having a > MIB variable that would enable one to configure an interface as being > known point-to-point, possibly point-to-point, or prohibited > from using > this point-to-point outer address flexibility, or some such management > configuration feature. There also seemed to have been at least some > interest in an automated way of determining that an interface was > point-to-point, perhaps based on the receive of 802.1AB frames all > containing appropriate indications coupled with the receipt > of no native > frames. > > Point-to-point links are, in fact, very common in modern > 802.3 networks. > > Donald > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Wednesday, October 03, 2007 11:11 AM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > Donald, > > Given that it is not crystal clear what you mean by > "point to point link", I am not sure I agree with this, at > least as you have worded it here. > > If you mean that the link is a full-duplex Ethernet > link and the two end-points have some definitive mechansim > for determining that they are the only entities using the > link between them, there may be issues with doing this. > > For example, if the link is technically an Ethernet > link, then it is not unlikely that one or the other devices > may have multiple roles - i.e. - it may be both an RBridge > for some frames and either a regular bridge or end station > (for example, a router) for others. It's arguable that, in > this case, the multi-role device is two (or more) separate > entities - thus invalidating a "point to point" definition > for this case (though only two distinct physical devices > are connected via this link). > > Without a clear agreement between involved entities, > this sort of "short-cut" addressing is likely to result in > higher-level (slow path) processing of many (if not all) > of the frames transiting the link for some implementations. > Moreover, without an unambiguous determination of exactly > when this would apply, it will not be unambiguously clear > when a receiving implementation would have to switch to a > "promiscuous listening" mode. > > I believe omission of the outer VLAN tag suffers from > the same ambiguity. For instance, it is possible for two > devices to have a "point to point" relationship within a > VLAN context that would not be the case without the VLAN > context. > > Hence it appears we would have to be explicit in what > we mean by "point to point" link and how we expect that the > entities (RBridges) involved would be able to disambiguate > this p2p status for any given link. > > If we are saying that two devices - using some means > out of scope for our specification - are somehow aware of an > unambiguous point-to-point relationship between them and can > therefore use any MAC DA on transmission, and ignore it on > receipt, we could make the same argument for virtually any > encapsulation choice we might prefer. But, it would be as > valid to observe that we don't need to specify what is - in > essence - an out-of-context (mis)behavior between consenting > implementations... > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, October 02, 2007 11:27 PM > > To: Rbridge@postel.org > > Subject: [rbridge] Consensus Check: Point to Point links > > > > This is a check via the mailing list to confirm or refute > an apparent > > consensus from the minutes of the Chicago meeting for a change from > > protocol draft -05: > > > > If it is known that a link is a point to point link between two > > RBridges, then the outer header, if it is an Ethernet header, can > > have any source and/or destination addresses, those > addresses will > > be ignored on receipt, and the outer VLAN tag can be omitted. > > > > If no particular controversy arises over this in the next two > > weeks, we > > will declare it to be the working group consensus. > > > > Thanks, > > Donald & Erik > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l954OPlR007391 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:24:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1191558260!21622262!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 14818 invoked from network); 5 Oct 2007 04:24:20 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-119.messagelabs.com with SMTP; 5 Oct 2007 04:24:20 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l954OKuf005799 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:24:20 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l954OJ1J001471 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:24:19 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l954OHhv001461 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:24:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 5 Oct 2007 00:24:16 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> In-Reply-To: <47050BCA.5030003@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGnivDxiNLgN1JTPaPI4gAWDL9rQAYkKVg References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l954OPlR007391 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 04:24:43 -0000 Status: RO Content-Length: 2955 Hi Radia, See below at @@@ -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@sun.com] Sent: Thursday, October 04, 2007 11:51 AM To: Eastlake III Donald-LDE008 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Personally, I need a reminder of what we are trying to accomplish with this before I can have any opinion. a) Is omitting the outer VLAN tag to save space? @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point link. b) Why put in anything for destination address other than the MAC address of the next hop RBridge, or put in anything into the source address other than your own MAC address? It won't save space. So what does it gain? @@@ While no one has given a really crisp response to that question, it is my impression that some believe it will make it possible to produce simpler, less expensive, or more efficient hardware for this case. c) Is there any danger if an RBridge is confused about whether this is a pt-to-pt link or not? @@@ I think there might be. And because of this and the extreme commonness of the point-to-point case, it may be reasonable to consider this in designing TRILL. For example, if a fixed MAC address were used (such as the unicast version of the All-Rbridges multicast address (just turn off the group bit)), then an interface receiving a frame with that source address would know there was a sender on the link who believes the link was point-to-point. If the receiver knows it is not point-to-point or is unwilling to handle such frames, it could take appropriate action. Also, Rbridge would know to never bother "learning" the location of that MAC address. @@@ Thanks, @@@ Donald I can see the advantage of omitting the entire outer header if it is somehow absolutely known this is a pt-to-pt link, and both ends of the link understand this. But that isn't what's being proposed here. It seems to be only omitting the VLAN tag, and allowing insertion of random addresses into the source and destination fields in the outer header, if I'm reading it correctly. So anyway, clarification at this point would certainly help me. Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l954GJCT014211 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:16:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1191557778!2023477!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23336 invoked from network); 5 Oct 2007 04:16:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 5 Oct 2007 04:16:19 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l954GIZ6027324 for <Rbridge@postel.org>; Thu, 4 Oct 2007 21:16:18 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l954GHrM008616 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:16:17 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l954GHSh008608 for <Rbridge@postel.org>; Thu, 4 Oct 2007 23:16:17 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 5 Oct 2007 00:14:14 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGn205Y5IzPy5+SZ2sQwDZyNsOmwAC7igQABUJ4hA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Anoop Ghanwani" <anoop@brocade.com> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l954GJCT014211 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 05 Oct 2007 04:16:32 -0000 Status: RO Content-Length: 2452 Actually, although I'm not entirely sure, I believe that BPDUs, LLDP PDUs, etc., all start with an Ethertype which identifies them so, in principle, they could be made to work on a specially equipped point to point link with no outer MAC addresses. However, I don't think anyone has proposed that TRILL should consider omitting the outer MAC addresses except when that suggestion appears as part of a question asking why, if you want to do some optimization on a point-to-point link, you don't want to do even more optimization. Donald -----Original Message----- From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Thursday, October 04, 2007 1:46 PM To: Radia Perlman; Eastlake III Donald-LDE008 Cc: Rbridge@postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 04, 2007 8:51 AM > To: Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Personally, I need a reminder of what we are trying to > accomplish with this before I can have any opinion. > > a) Is omitting the outer VLAN tag to save space? > b) Why put in anything for destination address other than the > MAC address of the next hop RBridge, or put in anything into > the source address other than your own MAC address? > It won't save space. So what does it gain? > c) Is there any danger if an RBridge is confused about > whether this is a pt-to-pt link or not? > > I can see the advantage of omitting the entire outer header > if it is somehow absolutely known this is a pt-to-pt link, > and both ends of the link understand this. That wouldn't work because there are other frames that will have to have MAC addresses, e.g. LACP, LLDP. > But that isn't > what's being proposed here. It seems to be only omitting the > VLAN tag, and allowing insertion of random addresses into the > source and destination fields in the outer header, if I'm > reading it correctly. I don't like the idea of random addresses (is it that a big a deal to set them correctly?), but as long as it's completely optional, I don't really care. [By the way, even though the proposal says that it can be random, it really can't because we have to say that they cannot be from the BPDU address space or things like LACP and LLDP will break.] Anoop Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94J93AC027152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Thu, 4 Oct 2007 12:09:04 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l94JGjH7027724; Thu, 4 Oct 2007 14:16:45 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 14:08:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 14:08:52 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B3802A@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGn205Y5IzPy5+SZ2sQwDZyNsOmwAC7igQAAOSa8A= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-OriginalArrivalTime: 04 Oct 2007 19:08:53.0522 (UTC) FILETIME=[0147B720:01C806BA] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94J93AC027152 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 19:09:23 -0000 Status: RO Content-Length: 2821 Anoop, Making it completely optional is a problem as well, and this is where I am having the most difficulty - particular with "random" addresses that require ignoring. The issue is that this is a wrong-way-around unilateral choice - i.e. - it is the sender that we say might have the option of doing this, but the receiver that has the complexity of supporting either way of doing it. If the entity making the choice was also the one having to pay for it, then I would agree that making it a choice would be okay. That does not seem to be the case! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Anoop Ghanwani > Sent: Thursday, October 04, 2007 1:46 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Thursday, October 04, 2007 8:51 AM > > To: Eastlake III Donald-LDE008 > > Cc: Rbridge@postel.org > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Personally, I need a reminder of what we are trying to > > accomplish with this before I can have any opinion. > > > > a) Is omitting the outer VLAN tag to save space? > > b) Why put in anything for destination address other than the > > MAC address of the next hop RBridge, or put in anything into > > the source address other than your own MAC address? > > It won't save space. So what does it gain? > > c) Is there any danger if an RBridge is confused about > > whether this is a pt-to-pt link or not? > > > > I can see the advantage of omitting the entire outer header > > if it is somehow absolutely known this is a pt-to-pt link, > > and both ends of the link understand this. > > That wouldn't work because there are other frames that will > have to have MAC addresses, e.g. LACP, LLDP. > > > But that isn't > > what's being proposed here. It seems to be only omitting the > > VLAN tag, and allowing insertion of random addresses into the > > source and destination fields in the outer header, if I'm > > reading it correctly. > > I don't like the idea of random addresses (is it that > a big a deal to set them correctly?), but as long as > it's completely optional, I don't really care. > [By the way, even though the proposal says that it > can be random, it really can't because we have to > say that they cannot be from the BPDU address space > or things like LACP and LLDP will break.] > > Anoop > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94Hkefg029627 for <Rbridge@postel.org>; Thu, 4 Oct 2007 10:46:40 -0700 (PDT) Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 04 Oct 2007 10:46:40 -0700 X-IronPort-AV: i="4.21,231,1188802800"; d="scan'208"; a="19383320:sNHT19640131" Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 8D7572382F9; Thu, 4 Oct 2007 10:46:40 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Oct 2007 10:46:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 10:45:47 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <47050BCA.5030003@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGn205Y5IzPy5+SZ2sQwDZyNsOmwAC7igQ References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> X-OriginalArrivalTime: 04 Oct 2007 17:46:40.0258 (UTC) FILETIME=[84D35E20:01C806AE] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94Hkefg029627 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 17:47:53 -0000 Status: RO Content-Length: 1666 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 04, 2007 8:51 AM > To: Eastlake III Donald-LDE008 > Cc: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Personally, I need a reminder of what we are trying to > accomplish with this before I can have any opinion. > > a) Is omitting the outer VLAN tag to save space? > b) Why put in anything for destination address other than the > MAC address of the next hop RBridge, or put in anything into > the source address other than your own MAC address? > It won't save space. So what does it gain? > c) Is there any danger if an RBridge is confused about > whether this is a pt-to-pt link or not? > > I can see the advantage of omitting the entire outer header > if it is somehow absolutely known this is a pt-to-pt link, > and both ends of the link understand this. That wouldn't work because there are other frames that will have to have MAC addresses, e.g. LACP, LLDP. > But that isn't > what's being proposed here. It seems to be only omitting the > VLAN tag, and allowing insertion of random addresses into the > source and destination fields in the outer header, if I'm > reading it correctly. I don't like the idea of random addresses (is it that a big a deal to set them correctly?), but as long as it's completely optional, I don't really care. [By the way, even though the proposal says that it can be random, it really can't because we have to say that they cannot be from the BPDU address space or things like LACP and LLDP will break.] Anoop Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94GwBdf008332 for <Rbridge@postel.org>; Thu, 4 Oct 2007 09:58:11 -0700 (PDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 12:58:09 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77024E983F@nekter> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGSiudpHVGIcRJSS2cWZ7TtrqdwgAAQycgAA2OddAAA7QrsAAF0nnw References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> From: "Caitlin Bestler" <Caitlin.Bestler@neterion.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray" <eric.gray@ericsson.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlin.bestler@neterion.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94GwBdf008332 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 16:59:06 -0000 Status: RO Content-Length: 160 Why wouldn't a "other end of the link" reserved MAC address be just as applicable for core Routers that are directly connected to each other point-to-point? Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94Fnl2P010538 for <Rbridge@postel.org>; Thu, 4 Oct 2007 08:49:47 -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 <0JPE003GS9AHSW00@dps.sfvic.sunlabs.com> for Rbridge@postel.org; Thu, 04 Oct 2007 08:49:29 -0700 (PDT) Received: from [192.168.1.39] ([64.105.38.106]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JPE006S59A2ZI90@mail.sunlabs.com> for Rbridge@postel.org; Thu, 04 Oct 2007 08:49:29 -0700 (PDT) Date: Thu, 04 Oct 2007 08:50:34 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Message-id: <47050BCA.5030003@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 15:50:12 -0000 Status: RO Content-Length: 1717 Personally, I need a reminder of what we are trying to accomplish with this before I can have any opinion. a) Is omitting the outer VLAN tag to save space? b) Why put in anything for destination address other than the MAC address of the next hop RBridge, or put in anything into the source address other than your own MAC address? It won't save space. So what does it gain? c) Is there any danger if an RBridge is confused about whether this is a pt-to-pt link or not? I can see the advantage of omitting the entire outer header if it is somehow absolutely known this is a pt-to-pt link, and both ends of the link understand this. But that isn't what's being proposed here. It seems to be only omitting the VLAN tag, and allowing insertion of random addresses into the source and destination fields in the outer header, if I'm reading it correctly. So anyway, clarification at this point would certainly help me. Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94EIIbw007360 for <Rbridge@postel.org>; Thu, 4 Oct 2007 07:18:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 07:17:59 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGSiudpHVGIcRJSS2cWZ7TtrqdwgAAQycgAA2OddAAA7QrsA== References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray" <eric.gray@ericsson.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94EIIbw007360 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 14:18:45 -0000 Status: RO Content-Length: 2817 A frame that is switched by a Bridge is NEVER addressed to the Bridge. An encapsulated frame that is switched by an RBridge is ALWAYS addressed to the RBridge. I understand management frames; it is not what we are discussing here. Using a reserved MAC address or ignoring the MAC address on point-to-point links achieves the same goal. Pick one, I don't care. This is a simple and effective solution; I don't understand the need to deny it. -- Silvano > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Thursday, October 04, 2007 5:29 AM > To: Silvano Gai; Joe Touch > Cc: Rbridge@postel.org; Caitlin Bestler > Subject: RE: [rbridge] Consensus Check: Point to Point links > > Silvano, > > It is not exactly true that bridges are never addressed at the > MAC layer. Consider, for example, how bridges are typically managed > using SNMP, or HTML. > > However, the case is still general, because everything you say > about RBridges - and the likelihood that they might be connected via > P2P links - similarly applies to other devices (L2 end-stations, such > as routers, for example. And objecting that it may (or may not) be > easy for these devices to determine that a link is P2P is an argument > that applies equally to RBridges. > > I think it is not possible at this point to argue that there is > consensus to do this work here, in the TRILL working group. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > > Sent: Thursday, October 04, 2007 1:56 AM > > To: Joe Touch > > Cc: Rbridge@postel.org; Caitlin Bestler > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Because Bridges are never addressed at the MAC layer, > > RBridges instead are! > > > > -- Silvano > > > > > -----Original Message----- > > > From: Joe Touch [mailto:touch@ISI.EDU] > > > Sent: Wednesday, October 03, 2007 10:48 PM > > > To: Silvano Gai > > > Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > > > > > > > > Silvano Gai wrote: > > > > Joe, > > > > > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > > > > > We are just asking to have a reserved MAC address that means "the > > other > > > > end of the link". > > > > > > > > The frame is still 100% compliant with Ethernet. > > > > > > If regular ethernet and regular bridges don't need this, why do > > rbridges? > > > > > > (bridges are already connected by such pt-pt links) > > > > > > Joe > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94CXIoi003268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Thu, 4 Oct 2007 05:33:18 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l94Cf7QW004134; Thu, 4 Oct 2007 07:41:07 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 07:33:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 07:33:15 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B3791B@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <47047E8E.5040600@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGTKnCQaPI5BqmSx2EG3+aaaXVnQANY9oA References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> <47047E8E.5040600@isi.edu> From: "Eric Gray" <eric.gray@ericsson.com> To: "Joe Touch" <touch@ISI.EDU>, "Silvano Gai" <sgai@nuovasystems.com> X-OriginalArrivalTime: 04 Oct 2007 12:33:15.0952 (UTC) FILETIME=[BC95FB00:01C80682] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94CXIoi003268 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 12:33:49 -0000 Status: RO Content-Length: 1248 Joe, While what Silvano says about bridges not (typically) being addressed by MAC address is true, and it is even more likely to be true for neighbor to neighbor communications, I agree that this is a general problem. I can hardly believe that this is the only example ever to come up of a layer-2 forwarding device wanting to have direct - neighbor to neighbor - protocol exchanges. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch > Sent: Thursday, October 04, 2007 1:48 AM > To: Silvano Gai > Cc: Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > * PGP Signed: 10/04/2007 at 07:47:58 AM > > > Silvano Gai wrote: > > Joe, > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > We are just asking to have a reserved MAC address that > means "the other > > end of the link". > > > > The frame is still 100% compliant with Ethernet. > > If regular ethernet and regular bridges don't need this, why > do rbridges? > > (bridges are already connected by such pt-pt links) > > Joe > > * Joe Touch <touch@isi.edu> > * 0x89A766BB (L) > > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94CSeQj002004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Thu, 4 Oct 2007 05:28:41 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l94CSbm6003700; Thu, 4 Oct 2007 07:28:37 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 07:28:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 07:28:36 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGSiudpHVGIcRJSS2cWZ7TtrqdwgAAQycgAA2OddA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-OriginalArrivalTime: 04 Oct 2007 12:28:37.0395 (UTC) FILETIME=[168D8E30:01C80682] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94CSeQj002004 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 12:29:27 -0000 Status: RO Content-Length: 1981 Silvano, It is not exactly true that bridges are never addressed at the MAC layer. Consider, for example, how bridges are typically managed using SNMP, or HTML. However, the case is still general, because everything you say about RBridges - and the likelihood that they might be connected via P2P links - similarly applies to other devices (L2 end-stations, such as routers, for example. And objecting that it may (or may not) be easy for these devices to determine that a link is P2P is an argument that applies equally to RBridges. I think it is not possible at this point to argue that there is consensus to do this work here, in the TRILL working group. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > Sent: Thursday, October 04, 2007 1:56 AM > To: Joe Touch > Cc: Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Because Bridges are never addressed at the MAC layer, > RBridges instead are! > > -- Silvano > > > -----Original Message----- > > From: Joe Touch [mailto:touch@ISI.EDU] > > Sent: Wednesday, October 03, 2007 10:48 PM > > To: Silvano Gai > > Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > > > > Silvano Gai wrote: > > > Joe, > > > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > > > We are just asking to have a reserved MAC address that means "the > other > > > end of the link". > > > > > > The frame is still 100% compliant with Ethernet. > > > > If regular ethernet and regular bridges don't need this, why do > rbridges? > > > > (bridges are already connected by such pt-pt links) > > > > Joe > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l94CNeoN000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Thu, 4 Oct 2007 05:23:40 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l94CVPln032602; Thu, 4 Oct 2007 07:31:26 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 07:23:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Oct 2007 07:23:33 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B37906@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGRwYLHaHSncEARKKQkFEoYj8qPQAAgTMwAA3062A= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-OriginalArrivalTime: 04 Oct 2007 12:23:34.0198 (UTC) FILETIME=[61D55D60:01C80681] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l94CNeoN000796 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 12:24:04 -0000 Status: RO Content-Length: 5295 Silvano, This is NOT AT ALL what Donald said. Having a reserved MAC address for the other end of a link is completely different from saying "any MAC address may be used and MUST be ignored on receipt." As for this - cleary different - proposal, I think it is quite reasonable, but almost certainly not something for us to do - HERE. As Joe points out, this is a general problem that should be addresses generally, rather than here and just for RBridges. This should be done via the IEEE. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > Sent: Thursday, October 04, 2007 1:42 AM > To: Joe Touch > Cc: Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Joe, > > Nobody is asking "to specify a new, non-ethernet link layer." > > We are just asking to have a reserved MAC address that means > "the other > end of the link". > > The frame is still 100% compliant with Ethernet. > > -- Silvano > > > -----Original Message----- > > From: Joe Touch [mailto:touch@ISI.EDU] > > Sent: Wednesday, October 03, 2007 10:26 PM > > To: Silvano Gai > > Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > > > > Silvano Gai wrote: > > > Joe, > > > > > > The majority of RBridges will be deployed in backbone where they > will be > > > connected by point-to-point links. The classical case will be 10GE > links > > > (which are only full-duplex). There will be no bridges > between them. > > > > > > What we are asking is a sentence that guarantees a simplified > > > interoperability in this case. > > > > > > I don't see what harm it can do. > > > > I don't see the need to specify a new, non-ethernet link layer. > > > > If this maps to "point to point links can use encapsulation-only > > ethernet" (I'm familiar with such a thing; does it ignore addresses > and > > use the MAC only for the CRC? if so, what is it called > exactly?), and > we > > can point to that, then there's no need for us to define it. > > > > If no such thing exists, then it might be useful to raise > this in the > > IEEE. I don't see why it is more relevant to rbridges than to any > other > > kind of bridge - for which pt-pt interconnections are also already > used. > > > > Joe > > > > > > > > -- Silvano > > > > > > > > >> -----Original Message----- > > >> From: Joe Touch [mailto:touch@ISI.EDU] > > >> Sent: Wednesday, October 03, 2007 10:06 PM > > >> To: Silvano Gai > > >> Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > > >> > > >> I can't speak for others, but I'm completely lost on this point. > > > Rbridge > > >> is defining a layer on top of ethernet. This pt-pt link stuff > sounds > > >> like it's redefining the ethernet layer for a special case. > > >> > > >> Whether it's useful to have ethernet have a definition > for a pt-pt > > > case > > >> is not relevant to this WG, IMO. It seems at best out of scope, > even > > > if > > >> it is useful. > > >> > > >> Can anyone explain why this shouldn't be already handled by > ethernet, > > >> and if it isn't, why we need to handle it as a special case here? > > >> > > >> Joe > > >> > > >> Silvano Gai wrote: > > >>> I totally agree with Dinesh > > >>> > > >>> -- Silvano > > >>> > > >>>> -----Original Message----- > > >>>> From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] > > >>> On > > >>>> Behalf Of Dinesh G Dutt > > >>>> Sent: Wednesday, October 03, 2007 5:24 PM > > >>>> To: Joe Touch > > >>>> Cc: Rbridge@postel.org; Caitlin Bestler > > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links > > >>>> > > >>>> The reason this is useful in the spec is that we can have > > >>>> interoperability. The situation is common enough that allowing > > >>>> interoperability simplifies implementations. > > >>>> > > >>>> Dinesh > > >>>> Joe Touch wrote: > > >>>>> Eric Gray wrote: > > >>>>> > > >>>>>> Caitlin, > > >>>>>> > > >>>>> ... > > >>>>> > > >>>>>> I get the sense that you're not disagreeing with > either Joe or > > >>>>>> myself. > > >>>>>> > > >>>>> I agree with the nuances Caitlin is raising; the conclusion is > > > that > > >>> this > > >>>>> need not be in the spec, as far as we three appear to agree. > > >>>>> > > >>>>> Joe > > >>>>> > > >>>>> > > >>>>> > > > > -------------------------------------------------------------- > ---------- > > >>>>> _______________________________________________ > > >>>>> rbridge mailing list > > >>>>> rbridge@postel.org > > >>>>> http://mailman.postel.org/mailman/listinfo/rbridge > > >>>>> > > >>>> -- > > >>>> We make our world significant by the courage of our > questions and > > > by > > >>>> the depth of our answers. - Carl > > > Sagan > > >>>> _______________________________________________ > > >>>> rbridge mailing list > > >>>> rbridge@postel.org > > >>>> http://mailman.postel.org/mailman/listinfo/rbridge > > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.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.13.8/8.13.8) with ESMTP id l946XCMt015952 for <Rbridge@postel.org>; Wed, 3 Oct 2007 23:33:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,228,1188802800"; d="scan'208";a="531233143" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2007 23:33:09 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l946X8kT018451; Wed, 3 Oct 2007 23:33:08 -0700 Received: from [10.21.85.210] (sjc-vpn4-1491.cisco.com [10.21.85.210]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l946X8Yt015636; Thu, 4 Oct 2007 06:33:08 GMT Message-ID: <47048924.9040102@cisco.com> Date: Wed, 03 Oct 2007 23:33:08 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Anoop Ghanwani <anoop@brocade.com> References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E7AFE55@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7AFE55@HQ-EXCH-5.corp.brocade.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2589; t=1191479588; x=1192343588; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Egress=20processin g=20of=20unicast=20not=09locallyknown |Sender:=20; bh=Z/23WHAonh+TXrVd7Sd2qP3+B1/bUlh+G3fgRzMfbGc=; b=RAFD7t+A90QLOD3R2pz/hMT5XyyJWqy4yxdWx82nxelx797iGRMlcaAotCFyFVda1dHpx3NI R3dqOGu0QHcqp6OyUX9n9IUIwGWCjDiWboGHV8hARoTnfsKhyGU98EPS; Authentication-Results: sj-dkim-3; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locallyknown X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 06:33:29 -0000 Status: RO Content-Length: 2519 Anoop, Did you mean that in the example that he quoted the reason for dropping the frame was access control (such as 802.1x authenticated) ? To me access control is a very generic term that can also include things such as security ACLs. "Access Control" is orthogonal to forwarding. For example, I can have IP FIB entries or MAC table entries associated with a frame, but can drop a specific frame such as those going to "port 80" as part of access control. What Donald is specifying *seems* to be in addition to access control. Dinesh Anoop Ghanwani wrote: > I'm not sure why the case of "MAC address could > not be on that link" needs to be called out at all. > That is an access control issue. But I am OK > with having it if someone really feels strongly > about it. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III >> Donald-LDE008 >> Sent: Tuesday, October 02, 2007 8:25 PM >> To: Rbridge@postel.org >> Subject: [rbridge] Consensus Check: Egress processing of >> unicast not locallyknown >> >> This is a check via the mailing list to confirm or refute an >> apparent consensus from the minutes of the Chicago meeting >> for a change from protocol draft -05: >> >> Egress RBridges that receive a known unicast TRILL data frame whose >> inner destination address is not known locally should send the >> native form of the frame out on every link for which the RBridge >> is DRB for the frame's VLAN unless it knows that an end station >> with that MAC address could not be on that link. (For example, >> there is a layer-2 registration procedure for end stations on that >> link and the destination MAC address in question is not >> registered.) This is a local decision. No "error" message will be >> defined for this condition at this time. >> >> If no particular controversy arises over this in the next two >> weeks, we will declare it to be the working group consensus. >> >> Thanks, >> Donald & Erik >> >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l946TlWX011468 for <Rbridge@postel.org>; Wed, 3 Oct 2007 23:29:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,228,1188802800"; d="scan'208";a="230249511" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 23:29:32 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l946TWjX013673; Wed, 3 Oct 2007 23:29:32 -0700 Received: from [10.21.85.210] (sjc-vpn4-1491.cisco.com [10.21.85.210]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l946TQYt012352; Thu, 4 Oct 2007 06:29:27 GMT Message-ID: <47048846.5090605@cisco.com> Date: Wed, 03 Oct 2007 23:29:26 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1536; t=1191479372; x=1192343372; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Egress=20processin g=20of=20unicast=20not=20locally=0A=20known |Sender:=20; bh=pniMitQh5k/P8yUZpHYqsCK/EOfr+Ri2cKA7EOYXzRA=; b=Tp3dbS+/ScKSWfZWnoI2LDWyESQpjv+CGJtiETlIyBYlAOFkVvHrPRcaQqzjmz+W9P8tGHmy vaHUIsXhhgUfKbZCatUmrmY6RzSAbCGxWC4TojprfhHgnSgg3UTaOxq7; Authentication-Results: sj-dkim-3; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locally known X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 06:30:32 -0000 Status: RO Content-Length: 1497 Donald, This is different from existing IEEE 802.1D bridges. I'm OK with it, as long as it is a MAY and not a MUST or a SHOULD. I'm worried that misconfigurations and such can cause silent packet drops which can be hard to debug. Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > Egress RBridges that receive a known unicast TRILL data frame whose > inner destination address is not known locally should send the > native form of the frame out on every link for which the RBridge > is DRB for the frame's VLAN unless it knows that an end station > with that MAC address could not be on that link. (For example, > there is a layer-2 registration procedure for end stations on that > link and the destination MAC address in question is not > registered.) This is a local decision. No "error" message will be > defined for this condition at this time. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l945ukxh001061 for <Rbridge@postel.org>; Wed, 3 Oct 2007 22:56:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 22:56:27 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <47047E8E.5040600@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGSiudpHVGIcRJSS2cWZ7TtrqdwgAAQycg References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> <4704794C.3080707@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> <47047E8E.5040600@isi.edu> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l945ukxh001061 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 05:57:21 -0000 Status: RO Content-Length: 757 Because Bridges are never addressed at the MAC layer, RBridges instead are! -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Wednesday, October 03, 2007 10:48 PM > To: Silvano Gai > Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Silvano Gai wrote: > > Joe, > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > We are just asking to have a reserved MAC address that means "the other > > end of the link". > > > > The frame is still 100% compliant with Ethernet. > > If regular ethernet and regular bridges don't need this, why do rbridges? > > (bridges are already connected by such pt-pt links) > > Joe Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l945mKwf028086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 22:48:20 -0700 (PDT) Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l945m1wa013746; Wed, 3 Oct 2007 22:48:01 -0700 (PDT) Message-ID: <47047E8E.5040600@isi.edu> Date: Wed, 03 Oct 2007 22:47:58 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> <4704794C.3080707@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A4EF94378C9754934695B86" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 05:48:55 -0000 Status: RO Content-Length: 1090 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A4EF94378C9754934695B86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Silvano Gai wrote: > Joe, >=20 > Nobody is asking "to specify a new, non-ethernet link layer." >=20 > We are just asking to have a reserved MAC address that means "the other= > end of the link". >=20 > The frame is still 100% compliant with Ethernet. If regular ethernet and regular bridges don't need this, why do rbridges?= (bridges are already connected by such pt-pt links) Joe --------------enig0A4EF94378C9754934695B86 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBH6OE5f5cImnZrsRApFCAJ40No8X2dTGjvH6472a9zQf1PXWvACgps+g KLAgvRBn4olxZNv+F955aW4= =xbIE -----END PGP SIGNATURE----- --------------enig0A4EF94378C9754934695B86-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l945gMPd026207 for <Rbridge@postel.org>; Wed, 3 Oct 2007 22:42:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 22:41:59 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <4704794C.3080707@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGRwYLHaHSncEARKKQkFEoYj8qPQAAgTMw References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> <4704794C.3080707@isi.edu> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l945gMPd026207 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 05:43:31 -0000 Status: RO Content-Length: 4004 Joe, Nobody is asking "to specify a new, non-ethernet link layer." We are just asking to have a reserved MAC address that means "the other end of the link". The frame is still 100% compliant with Ethernet. -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Wednesday, October 03, 2007 10:26 PM > To: Silvano Gai > Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Silvano Gai wrote: > > Joe, > > > > The majority of RBridges will be deployed in backbone where they will be > > connected by point-to-point links. The classical case will be 10GE links > > (which are only full-duplex). There will be no bridges between them. > > > > What we are asking is a sentence that guarantees a simplified > > interoperability in this case. > > > > I don't see what harm it can do. > > I don't see the need to specify a new, non-ethernet link layer. > > If this maps to "point to point links can use encapsulation-only > ethernet" (I'm familiar with such a thing; does it ignore addresses and > use the MAC only for the CRC? if so, what is it called exactly?), and we > can point to that, then there's no need for us to define it. > > If no such thing exists, then it might be useful to raise this in the > IEEE. I don't see why it is more relevant to rbridges than to any other > kind of bridge - for which pt-pt interconnections are also already used. > > Joe > > > > > -- Silvano > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Wednesday, October 03, 2007 10:06 PM > >> To: Silvano Gai > >> Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> I can't speak for others, but I'm completely lost on this point. > > Rbridge > >> is defining a layer on top of ethernet. This pt-pt link stuff sounds > >> like it's redefining the ethernet layer for a special case. > >> > >> Whether it's useful to have ethernet have a definition for a pt-pt > > case > >> is not relevant to this WG, IMO. It seems at best out of scope, even > > if > >> it is useful. > >> > >> Can anyone explain why this shouldn't be already handled by ethernet, > >> and if it isn't, why we need to handle it as a special case here? > >> > >> Joe > >> > >> Silvano Gai wrote: > >>> I totally agree with Dinesh > >>> > >>> -- Silvano > >>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] > >>> On > >>>> Behalf Of Dinesh G Dutt > >>>> Sent: Wednesday, October 03, 2007 5:24 PM > >>>> To: Joe Touch > >>>> Cc: Rbridge@postel.org; Caitlin Bestler > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links > >>>> > >>>> The reason this is useful in the spec is that we can have > >>>> interoperability. The situation is common enough that allowing > >>>> interoperability simplifies implementations. > >>>> > >>>> Dinesh > >>>> Joe Touch wrote: > >>>>> Eric Gray wrote: > >>>>> > >>>>>> Caitlin, > >>>>>> > >>>>> ... > >>>>> > >>>>>> I get the sense that you're not disagreeing with either Joe or > >>>>>> myself. > >>>>>> > >>>>> I agree with the nuances Caitlin is raising; the conclusion is > > that > >>> this > >>>>> need not be in the spec, as far as we three appear to agree. > >>>>> > >>>>> Joe > >>>>> > >>>>> > >>>>> > > ------------------------------------------------------------------------ > >>>>> _______________________________________________ > >>>>> rbridge mailing list > >>>>> rbridge@postel.org > >>>>> http://mailman.postel.org/mailman/listinfo/rbridge > >>>>> > >>>> -- > >>>> We make our world significant by the courage of our questions and > > by > >>>> the depth of our answers. - Carl > > Sagan > >>>> _______________________________________________ > >>>> rbridge mailing list > >>>> rbridge@postel.org > >>>> http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l945PmTT021343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 22:25:48 -0700 (PDT) Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l945PZqw008441; Wed, 3 Oct 2007 22:25:35 -0700 (PDT) Message-ID: <4704794C.3080707@isi.edu> Date: Wed, 03 Oct 2007 22:25:32 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2AF5F76AFB8EC16381EFC62" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 05:26:19 -0000 Status: RO Content-Length: 4034 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2AF5F76AFB8EC16381EFC62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Silvano Gai wrote: > Joe, >=20 > The majority of RBridges will be deployed in backbone where they will b= e > connected by point-to-point links. The classical case will be 10GE link= s > (which are only full-duplex). There will be no bridges between them. >=20 > What we are asking is a sentence that guarantees a simplified > interoperability in this case. >=20 > I don't see what harm it can do. I don't see the need to specify a new, non-ethernet link layer. If this maps to "point to point links can use encapsulation-only ethernet" (I'm familiar with such a thing; does it ignore addresses and use the MAC only for the CRC? if so, what is it called exactly?), and we can point to that, then there's no need for us to define it. If no such thing exists, then it might be useful to raise this in the IEEE. I don't see why it is more relevant to rbridges than to any other kind of bridge - for which pt-pt interconnections are also already used. Joe >=20 > -- Silvano >=20 >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU] >> Sent: Wednesday, October 03, 2007 10:06 PM >> To: Silvano Gai >> Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> I can't speak for others, but I'm completely lost on this point. > Rbridge >> is defining a layer on top of ethernet. This pt-pt link stuff sounds >> like it's redefining the ethernet layer for a special case. >> >> Whether it's useful to have ethernet have a definition for a pt-pt > case >> is not relevant to this WG, IMO. It seems at best out of scope, even > if >> it is useful. >> >> Can anyone explain why this shouldn't be already handled by ethernet, >> and if it isn't, why we need to handle it as a special case here? >> >> Joe >> >> Silvano Gai wrote: >>> I totally agree with Dinesh >>> >>> -- Silvano >>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] >>> On >>>> Behalf Of Dinesh G Dutt >>>> Sent: Wednesday, October 03, 2007 5:24 PM >>>> To: Joe Touch >>>> Cc: Rbridge@postel.org; Caitlin Bestler >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links >>>> >>>> The reason this is useful in the spec is that we can have >>>> interoperability. The situation is common enough that allowing >>>> interoperability simplifies implementations. >>>> >>>> Dinesh >>>> Joe Touch wrote: >>>>> Eric Gray wrote: >>>>> >>>>>> Caitlin, >>>>>> >>>>> ... >>>>> >>>>>> I get the sense that you're not disagreeing with either Joe or >>>>>> myself. >>>>>> >>>>> I agree with the nuances Caitlin is raising; the conclusion is > that >>> this >>>>> need not be in the spec, as far as we three appear to agree. >>>>> >>>>> Joe >>>>> >>>>> >>>>> > -----------------------------------------------------------------------= - >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge@postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>> -- >>>> We make our world significant by the courage of our questions and > by >>>> the depth of our answers. - Carl > Sagan >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge@postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >=20 --------------enigA2AF5F76AFB8EC16381EFC62 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBHlME5f5cImnZrsRAsdjAKDL/VJsmaq8WyCCV9VdaLKo8S4lggCgwPkf YoDQUV/QCGWUk3mhIHSaalY= =JvOL -----END PGP SIGNATURE----- --------------enigA2AF5F76AFB8EC16381EFC62-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l945CQa3018196 for <Rbridge@postel.org>; Wed, 3 Oct 2007 22:12:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 22:12:07 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <470474B4.20901@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGRE7aB6dbncJwQmCuQnhnzgx/HAAADRdw References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l945CQa3018196 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 05:12:55 -0000 Status: RO Content-Length: 2677 Joe, The majority of RBridges will be deployed in backbone where they will be connected by point-to-point links. The classical case will be 10GE links (which are only full-duplex). There will be no bridges between them. What we are asking is a sentence that guarantees a simplified interoperability in this case. I don't see what harm it can do. -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Wednesday, October 03, 2007 10:06 PM > To: Silvano Gai > Cc: Dinesh G Dutt; Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > I can't speak for others, but I'm completely lost on this point. Rbridge > is defining a layer on top of ethernet. This pt-pt link stuff sounds > like it's redefining the ethernet layer for a special case. > > Whether it's useful to have ethernet have a definition for a pt-pt case > is not relevant to this WG, IMO. It seems at best out of scope, even if > it is useful. > > Can anyone explain why this shouldn't be already handled by ethernet, > and if it isn't, why we need to handle it as a special case here? > > Joe > > Silvano Gai wrote: > > I totally agree with Dinesh > > > > -- Silvano > > > >> -----Original Message----- > >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > > On > >> Behalf Of Dinesh G Dutt > >> Sent: Wednesday, October 03, 2007 5:24 PM > >> To: Joe Touch > >> Cc: Rbridge@postel.org; Caitlin Bestler > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> The reason this is useful in the spec is that we can have > >> interoperability. The situation is common enough that allowing > >> interoperability simplifies implementations. > >> > >> Dinesh > >> Joe Touch wrote: > >>> Eric Gray wrote: > >>> > >>>> Caitlin, > >>>> > >>> ... > >>> > >>>> I get the sense that you're not disagreeing with either Joe or > >>>> myself. > >>>> > >>> I agree with the nuances Caitlin is raising; the conclusion is that > > this > >>> need not be in the spec, as far as we three appear to agree. > >>> > >>> Joe > >>> > >>> > >>> > > ------------------------------------------------------------------------ > >>> _______________________________________________ > >>> rbridge mailing list > >>> rbridge@postel.org > >>> http://mailman.postel.org/mailman/listinfo/rbridge > >>> > >> -- > >> We make our world significant by the courage of our questions and by > >> the depth of our answers. - Carl Sagan > >> _______________________________________________ > >> rbridge mailing list > >> rbridge@postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9456Ivb016851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 22:06:18 -0700 (PDT) Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l94562et004387; Wed, 3 Oct 2007 22:06:03 -0700 (PDT) Message-ID: <470474B4.20901@isi.edu> Date: Wed, 03 Oct 2007 22:05:56 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD1E08DA8E6AC49518C1057BC" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 05:06:52 -0000 Status: RO Content-Length: 2638 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD1E08DA8E6AC49518C1057BC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can't speak for others, but I'm completely lost on this point. Rbridge is defining a layer on top of ethernet. This pt-pt link stuff sounds like it's redefining the ethernet layer for a special case. Whether it's useful to have ethernet have a definition for a pt-pt case is not relevant to this WG, IMO. It seems at best out of scope, even if it is useful. Can anyone explain why this shouldn't be already handled by ethernet, and if it isn't, why we need to handle it as a special case here? Joe Silvano Gai wrote: > I totally agree with Dinesh >=20 > -- Silvano >=20 >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On >> Behalf Of Dinesh G Dutt >> Sent: Wednesday, October 03, 2007 5:24 PM >> To: Joe Touch >> Cc: Rbridge@postel.org; Caitlin Bestler >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> The reason this is useful in the spec is that we can have >> interoperability. The situation is common enough that allowing >> interoperability simplifies implementations. >> >> Dinesh >> Joe Touch wrote: >>> Eric Gray wrote: >>> >>>> Caitlin, >>>> >>> ... >>> >>>> I get the sense that you're not disagreeing with either Joe or >>>> myself. >>>> >>> I agree with the nuances Caitlin is raising; the conclusion is that > this >>> need not be in the spec, as far as we three appear to agree. >>> >>> Joe >>> >>> >>> > -----------------------------------------------------------------------= - >>> _______________________________________________ >>> rbridge mailing list >>> rbridge@postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >> -- >> We make our world significant by the courage of our questions and by >> the depth of our answers. - Carl Sagan >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge --------------enigD1E08DA8E6AC49518C1057BC 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBHS4E5f5cImnZrsRAmEIAKC9ek7azdsanxEZSrL3yzwyjwB+5QCfYd/T 4VVYVm/+KGsRyWkVjYD/nuc= =CezZ -----END PGP SIGNATURE----- --------------enigD1E08DA8E6AC49518C1057BC-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l944G8qa004070 for <Rbridge@postel.org>; Wed, 3 Oct 2007 21:16:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 21:15:48 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <47043291.5080201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgGHhLzG0+lDA9qSkelqD28YAyXAwAHxq9Q References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Dinesh G Dutt" <ddutt@cisco.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l944G8qa004070 Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 04:16:20 -0000 Status: RO Content-Length: 1387 I totally agree with Dinesh -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Dinesh G Dutt > Sent: Wednesday, October 03, 2007 5:24 PM > To: Joe Touch > Cc: Rbridge@postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > The reason this is useful in the spec is that we can have > interoperability. The situation is common enough that allowing > interoperability simplifies implementations. > > Dinesh > Joe Touch wrote: > > Eric Gray wrote: > > > >> Caitlin, > >> > > ... > > > >> I get the sense that you're not disagreeing with either Joe or > >> myself. > >> > > > > I agree with the nuances Caitlin is raising; the conclusion is that this > > need not be in the spec, as far as we three appear to agree. > > > > Joe > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > -- > We make our world significant by the courage of our questions and by > the depth of our answers. - Carl Sagan > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.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.13.8/8.13.8) with ESMTP id l940Nub7023908 for <Rbridge@postel.org>; Wed, 3 Oct 2007 17:23:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,226,1188802800"; d="scan'208";a="531126874" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2007 17:23:46 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l940NjVD008967; Wed, 3 Oct 2007 17:23:45 -0700 Received: from [10.21.85.210] (sjc-vpn4-1491.cisco.com [10.21.85.210]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l940Nj0W020156; Thu, 4 Oct 2007 00:23:45 GMT Message-ID: <47043291.5080201@cisco.com> Date: Wed, 03 Oct 2007 17:23:45 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: Joe Touch <touch@ISI.EDU> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> <4703DF1E.8020904@isi.edu> In-Reply-To: <4703DF1E.8020904@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=895; t=1191457426; x=1192321426; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:=20Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Consensus=20Check=3A=20Point=20to=20Point =20links |Sender:=20; bh=t9RbWAyywglkcIIPayZXewsuhOHco9pwZpmahCT/+sk=; b=F0DUAorPruH4BKy7YHgt11C/Z3gCPciRYFrUtgz5/VgjW4bdxh9B42vmjXzXsaiLduNdirIi 7Zg0ENKS43S2WndISS0bL/3ciDrKpjDp4HI+LLiTW5hsturGEI4CPZty; Authentication-Results: sj-dkim-4; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Oct 2007 00:24:09 -0000 Status: RO Content-Length: 862 The reason this is useful in the spec is that we can have interoperability. The situation is common enough that allowing interoperability simplifies implementations. Dinesh Joe Touch wrote: > Eric Gray wrote: > >> Caitlin, >> > ... > >> I get the sense that you're not disagreeing with either Joe or >> myself. >> > > I agree with the nuances Caitlin is raising; the conclusion is that this > need not be in the spec, as far as we three appear to agree. > > Joe > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93JAC0E011376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 12:10:13 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l93JHs7Z007626; Wed, 3 Oct 2007 14:18:00 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 14:10:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 14:10:04 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B374C2@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgATWlnAAAtVxQAAAikIcA== References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 03 Oct 2007 19:10:07.0985 (UTC) FILETIME=[03401E10:01C805F1] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93JAC0E011376 Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 19:10:44 -0000 Status: RO Content-Length: 5683 Donald, Perhaps all of these things are true. So what? The argument that a lot of people would like to do X could be used to do a lot of things. I'd like us to make maple walnut waffle-cones - possibly with caramel on top. Ummm, does that sound good! What does ANY of this have to do with TRILL? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Wednesday, October 03, 2007 2:25 PM > To: Rbridge@postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Hi Eric, > > I believe the generally understood meaning of point-to-point is a link > with exactly two devices on it, in this case RBridges. > > It is true that one could always do this sort of thing outside the > standards. But in Chicago the working group appeared to > believe this was > sufficiently important to say in the standard and, while the consensus > in the room was not that detailed, I got the general impression that > people would be favorable to, in a later management document, having a > MIB variable that would enable one to configure an interface as being > known point-to-point, possibly point-to-point, or prohibited > from using > this point-to-point outer address flexibility, or some such management > configuration feature. There also seemed to have been at least some > interest in an automated way of determining that an interface was > point-to-point, perhaps based on the receive of 802.1AB frames all > containing appropriate indications coupled with the receipt > of no native > frames. > > Point-to-point links are, in fact, very common in modern > 802.3 networks. > > Donald > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Wednesday, October 03, 2007 11:11 AM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > Donald, > > Given that it is not crystal clear what you mean by > "point to point link", I am not sure I agree with this, at > least as you have worded it here. > > If you mean that the link is a full-duplex Ethernet > link and the two end-points have some definitive mechansim > for determining that they are the only entities using the > link between them, there may be issues with doing this. > > For example, if the link is technically an Ethernet > link, then it is not unlikely that one or the other devices > may have multiple roles - i.e. - it may be both an RBridge > for some frames and either a regular bridge or end station > (for example, a router) for others. It's arguable that, in > this case, the multi-role device is two (or more) separate > entities - thus invalidating a "point to point" definition > for this case (though only two distinct physical devices > are connected via this link). > > Without a clear agreement between involved entities, > this sort of "short-cut" addressing is likely to result in > higher-level (slow path) processing of many (if not all) > of the frames transiting the link for some implementations. > Moreover, without an unambiguous determination of exactly > when this would apply, it will not be unambiguously clear > when a receiving implementation would have to switch to a > "promiscuous listening" mode. > > I believe omission of the outer VLAN tag suffers from > the same ambiguity. For instance, it is possible for two > devices to have a "point to point" relationship within a > VLAN context that would nto be the case without the VLAN > context. > > Hence it appears we would have to be explicit in what > we mean by "point to point" link and how we expect that the > entities (RBridges) involved would be able to disambiguate > this p2p status for any given link. > > If we are saying that two devices - using some means > out of scope for our specification - are somehow aware of an > unambiguous point-to-point relationship between them and can > therefore use any MAC DA on transmission, and ignore it on > receipt, we could make the same argument for virtually any > encapsulation choice we might prefer. But, it would be as > valid to observe that we don't need to specify what is - in > essence - an out-of-context (mis)behavior between consenting > implementations... > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, October 02, 2007 11:27 PM > > To: Rbridge@postel.org > > Subject: [rbridge] Consensus Check: Point to Point links > > > > This is a check via the mailing list to confirm or refute > an apparent > > consensus from the minutes of the Chicago meeting for a change from > > protocol draft -05: > > > > If it is known that a link is a point to point link between two > > RBridges, then the outer header, if it is an Ethernet header, can > > have any source and/or destination addresses, those > addresses will > > be ignored on receipt, and the outer VLAN tag can be omitted. > > > > If no particular controversy arises over this in the next two > > weeks, we > > will declare it to be the working group consensus. > > > > Thanks, > > Donald & Erik > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93ISPoa027554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:28:25 -0700 (PDT) Received: from [128.9.176.76] ([128.9.176.76]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l93IRjjU020282; Wed, 3 Oct 2007 11:27:47 -0700 (PDT) Message-ID: <4703DF1E.8020904@isi.edu> Date: Wed, 03 Oct 2007 11:27:42 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Gray <eric.gray@ericsson.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig494762C0C5C8396E6529941F" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org, Caitlin Bestler <Caitlin.Bestler@neterion.com> Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 18:29:14 -0000 Status: RO Content-Length: 960 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig494762C0C5C8396E6529941F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric Gray wrote: > Caitlin, =2E.. >=20 > I get the sense that you're not disagreeing with either Joe or=20 > myself. I agree with the nuances Caitlin is raising; the conclusion is that this need not be in the spec, as far as we three appear to agree. Joe --------------enig494762C0C5C8396E6529941F 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHA98eE5f5cImnZrsRAik4AKDtA3cd76cgsx9QJ0kpAN2W+tRNUACeNgN9 g1XJmIe2HF7gnnCjQat40Ac= =vMa9 -----END PGP SIGNATURE----- --------------enig494762C0C5C8396E6529941F-- Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l93IP7QG026819 for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:25:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1191435903!4535843!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12451 invoked from network); 3 Oct 2007 18:25:03 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 3 Oct 2007 18:25:03 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l93IP3XQ018873 for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:25:03 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l93IP23k003249 for <Rbridge@postel.org>; Wed, 3 Oct 2007 13:25:03 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l93IP2ef003239 for <Rbridge@postel.org>; Wed, 3 Oct 2007 13:25:02 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 3 Oct 2007 14:24:58 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgATWlnAAAtVxQA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93IP7QG026819 Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 18:25:59 -0000 Status: RO Content-Length: 4647 Hi Eric, I believe the generally understood meaning of point-to-point is a link with exactly two devices on it, in this case RBridges. It is true that one could always do this sort of thing outside the standards. But in Chicago the working group appeared to believe this was sufficiently important to say in the standard and, while the consensus in the room was not that detailed, I got the general impression that people would be favorable to, in a later management document, having a MIB variable that would enable one to configure an interface as being known point-to-point, possibly point-to-point, or prohibited from using this point-to-point outer address flexibility, or some such management configuration feature. There also seemed to have been at least some interest in an automated way of determining that an interface was point-to-point, perhaps based on the receive of 802.1AB frames all containing appropriate indications coupled with the receipt of no native frames. Point-to-point links are, in fact, very common in modern 802.3 networks. Donald -----Original Message----- From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Wednesday, October 03, 2007 11:11 AM To: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links Donald, Given that it is not crystal clear what you mean by "point to point link", I am not sure I agree with this, at least as you have worded it here. If you mean that the link is a full-duplex Ethernet link and the two end-points have some definitive mechansim for determining that they are the only entities using the link between them, there may be issues with doing this. For example, if the link is technically an Ethernet link, then it is not unlikely that one or the other devices may have multiple roles - i.e. - it may be both an RBridge for some frames and either a regular bridge or end station (for example, a router) for others. It's arguable that, in this case, the multi-role device is two (or more) separate entities - thus invalidating a "point to point" definition for this case (though only two distinct physical devices are connected via this link). Without a clear agreement between involved entities, this sort of "short-cut" addressing is likely to result in higher-level (slow path) processing of many (if not all) of the frames transiting the link for some implementations. Moreover, without an unambiguous determination of exactly when this would apply, it will not be unambiguously clear when a receiving implementation would have to switch to a "promiscuous listening" mode. I believe omission of the outer VLAN tag suffers from the same ambiguity. For instance, it is possible for two devices to have a "point to point" relationship within a VLAN context that would nto be the case without the VLAN context. Hence it appears we would have to be explicit in what we mean by "point to point" link and how we expect that the entities (RBridges) involved would be able to disambiguate this p2p status for any given link. If we are saying that two devices - using some means out of scope for our specification - are somehow aware of an unambiguous point-to-point relationship between them and can therefore use any MAC DA on transmission, and ignore it on receipt, we could make the same argument for virtually any encapsulation choice we might prefer. But, it would be as valid to observe that we don't need to specify what is - in essence - an out-of-context (mis)behavior between consenting implementations... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 11:27 PM > To: Rbridge@postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l93IOUHi026647 for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:24:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1191435869!25507598!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4692 invoked from network); 3 Oct 2007 18:24:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 3 Oct 2007 18:24:29 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l93IOTLU018734 for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:24:29 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l93IOStT002960 for <Rbridge@postel.org>; Wed, 3 Oct 2007 13:24:28 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l93IOSAu002948 for <Rbridge@postel.org>; Wed, 3 Oct 2007 13:24:28 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 3 Oct 2007 14:24:26 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003184318@de01exm64.ds.mot.com> In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7AFE32@HQ-EXCH-5.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgAbrjiAAACR3EA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E7AFE32@HQ-EXCH-5.corp.brocade.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93IOUHi026647 Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 18:25:03 -0000 Status: RO Content-Length: 1434 That's reasonable. "can be omitted" implies MAY to me. Donald -----Original Message----- From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Wednesday, October 03, 2007 12:41 PM To: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links I'm OK with this as long as the omission of the outer VLAN tag is a MAY rather than a MUST. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 8:27 PM > To: Rbridge@postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an > apparent consensus from the minutes of the Chicago meeting > for a change from protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93IML6W025764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:22:22 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l93ITxjx019592; Wed, 3 Oct 2007 13:30:05 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 13:22:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 13:22:08 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgF4v8+54VyfUqESNWB6FN4AWF+HgABczAQAABOuAA= References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> From: "Eric Gray" <eric.gray@ericsson.com> To: "Caitlin Bestler" <Caitlin.Bestler@neterion.com>, "Joe Touch" <touch@ISI.EDU> X-OriginalArrivalTime: 03 Oct 2007 18:22:09.0935 (UTC) FILETIME=[4FCC89F0:01C805EA] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93IML6W025764 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 18:22:54 -0000 Status: RO Content-Length: 1789 Caitlin, Please see one comment below... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Caitlin Bestler [mailto:Caitlin.Bestler@neterion.com] > Sent: Wednesday, October 03, 2007 2:18 PM > To: Joe Touch; Eric Gray > Cc: Rbridge@postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > Importance: High > > > Joe Touch wrote: > > > I concur with Eric. My concern is why we are defining behavior > specific > > to pt-pt links for rbridges when they are not similarly defined for > > general 802.11 networks. > > > If there is such a definition, we should point to it, but we should > not > > create our own. There's no unique need. > > I can imagine several scenarios where there is a truly safe > point-to-point > link between two RBridges, and it is indeed safe for them to use a > custom > tunneling between them. > > What I don't see is why they need the specification to give them > permission. > > If that link is *truly* and securely point-to-point they could just as > easily > declare themselves to be a single RBridge and said link to be a > "inter-processor > bus". When an RBridge is implemented on multiple processors the IETF > does NOT > specify the bus that connects them. > > So basically, whenever this sort of optimized encapsulation is valid > there is > no need to explicitly state so. If there is a need for the alternate > encapsulation > to be officially blessed then it probably means that it isn't > safe to do > it. > > If *nobody* else can see the optimized frames then who is there to > complain > that they are non-compliant? Hence the reference to "consenting implementations" in my earlier mail. I get the sense that you're not disagreeing with either Joe or myself. > > > > Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93IHoUB023945 for <Rbridge@postel.org>; Wed, 3 Oct 2007 11:17:50 -0700 (PDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 14:17:42 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> In-Reply-To: <4703CE6C.7090306@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgF4v8+54VyfUqESNWB6FN4AWF+HgABczAQ References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> From: "Caitlin Bestler" <Caitlin.Bestler@neterion.com> To: "Joe Touch" <touch@ISI.EDU>, "Eric Gray" <eric.gray@ericsson.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlin.bestler@neterion.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93IHoUB023945 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 18:17:58 -0000 Status: RO Content-Length: 1182 Joe Touch wrote: > I concur with Eric. My concern is why we are defining behavior specific > to pt-pt links for rbridges when they are not similarly defined for > general 802.11 networks. > If there is such a definition, we should point to it, but we should not > create our own. There's no unique need. I can imagine several scenarios where there is a truly safe point-to-point link between two RBridges, and it is indeed safe for them to use a custom tunneling between them. What I don't see is why they need the specification to give them permission. If that link is *truly* and securely point-to-point they could just as easily declare themselves to be a single RBridge and said link to be a "inter-processor bus". When an RBridge is implemented on multiple processors the IETF does NOT specify the bus that connects them. So basically, whenever this sort of optimized encapsulation is valid there is no need to explicitly state so. If there is a need for the alternate encapsulation to be officially blessed then it probably means that it isn't safe to do it. If *nobody* else can see the optimized frames then who is there to complain that they are non-compliant? Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93HGqg0004713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 10:16:52 -0700 (PDT) Received: from [70.213.142.97] (97.sub-70-213-142.myvzw.com [70.213.142.97]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l93HGVcd029884; Wed, 3 Oct 2007 10:16:32 -0700 (PDT) Message-ID: <4703CE6C.7090306@isi.edu> Date: Wed, 03 Oct 2007 10:16:28 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Gray <eric.gray@ericsson.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8BCFD82B1C00DE99977AEB41" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 17:17:22 -0000 Status: RO Content-Length: 1001 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8BCFD82B1C00DE99977AEB41 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Donald, et al., I concur with Eric. My concern is why we are defining behavior specific to pt-pt links for rbridges when they are not similarly defined for general 802.11 networks. If there is such a definition, we should point to it, but we should not create our own. There's no unique need. Joe --------------enig8BCFD82B1C00DE99977AEB41 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHA85sE5f5cImnZrsRAsqfAJ4uxWJDpXcHar38dN23kYa69DBwhQCg5K63 LOKrPxufT7jTkcNyzVXgIXw= =w0LV -----END PGP SIGNATURE----- --------------enig8BCFD82B1C00DE99977AEB41-- Received: from mx20.brocade.com ([66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93H4ZCR000320 for <Rbridge@postel.org>; Wed, 3 Oct 2007 10:04:36 -0700 (PDT) Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 03 Oct 2007 10:04:35 -0700 X-IronPort-AV: i="4.21,225,1188802800"; d="scan'208"; a="13092287:sNHT19028282" Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id D47412382F8; Wed, 3 Oct 2007 10:04:35 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Oct 2007 10:04:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 10:03:43 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7AFE55@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Egress processing of unicast not locallyknown Thread-Index: AcgFbQQ7CB53pCMuQLq7lbwJdGzn5AAcg4VQ References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 03 Oct 2007 17:04:35.0940 (UTC) FILETIME=[79CD4240:01C805DF] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93H4ZCR000320 Subject: Re: [rbridge] Consensus Check: Egress processing of unicast not locallyknown X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 17:05:04 -0000 Status: RO Content-Length: 1598 I'm not sure why the case of "MAC address could not be on that link" needs to be called out at all. That is an access control issue. But I am OK with having it if someone really feels strongly about it. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 8:25 PM > To: Rbridge@postel.org > Subject: [rbridge] Consensus Check: Egress processing of > unicast not locallyknown > > This is a check via the mailing list to confirm or refute an > apparent consensus from the minutes of the Chicago meeting > for a change from protocol draft -05: > > Egress RBridges that receive a known unicast TRILL data frame whose > inner destination address is not known locally should send the > native form of the frame out on every link for which the RBridge > is DRB for the frame's VLAN unless it knows that an end station > with that MAC address could not be on that link. (For example, > there is a layer-2 registration procedure for end stations on that > link and the destination MAC address in question is not > registered.) This is a local decision. No "error" message will be > defined for this condition at this time. > > If no particular controversy arises over this in the next two > weeks, we will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mx20.brocade.com ([66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93Gg6do022755 for <Rbridge@postel.org>; Wed, 3 Oct 2007 09:42:06 -0700 (PDT) Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 03 Oct 2007 09:42:06 -0700 X-IronPort-AV: i="4.21,225,1188802800"; d="scan'208"; a="13091689:sNHT18220286" Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 748882382F8; Wed, 3 Oct 2007 09:42:06 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Oct 2007 09:42:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 09:41:13 -0700 Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7AFE32@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgAbrjiA References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> From: "Anoop Ghanwani" <anoop@brocade.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 03 Oct 2007 16:42:06.0553 (UTC) FILETIME=[55812490:01C805DC] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93Gg6do022755 Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 16:42:42 -0000 Status: RO Content-Length: 1138 I'm OK with this as long as the omission of the outer VLAN tag is a MAY rather than a MUST. Anoop > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 8:27 PM > To: Rbridge@postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an > apparent consensus from the minutes of the Chicago meeting > for a change from protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93FB055016540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 3 Oct 2007 08:11:04 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l93FAqWx010526; Wed, 3 Oct 2007 10:10:53 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 10:10:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Oct 2007 10:10:51 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBgATWlnA References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> From: "Eric Gray" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 03 Oct 2007 15:10:52.0854 (UTC) FILETIME=[96ECF560:01C805CF] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@ericsson.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l93FB055016540 Subject: Re: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 15:11:51 -0000 Status: RO Content-Length: 3349 Donald, Given that it is not crystal clear what you mean by "point to point link", I am not sure I agree with this, at least as you have worded it here. If you mean that the link is a full-duplex Ethernet link and the two end-points have some definitive mechansim for determining that they are the only entities using the link between them, there may be issues with doing this. For example, if the link is technically an Ethernet link, then it is not unlikely that one or the other devices may have multiple roles - i.e. - it may be both an RBridge for some frames and either a regular bridge or end station (for example, a router) for others. It's arguable that, in this case, the multi-role device is two (or more) separate entities - thus invalidating a "point to point" definition for this case (though only two distinct physical devices are connected via this link). Without a clear agreement between involved entities, this sort of "short-cut" addressing is likely to result in higher-level (slow path) processing of many (if not all) of the frames transiting the link for some implementations. Moreover, without an unambiguous determination of exactly when this would apply, it will not be unambiguously clear when a receiving implementation would have to switch to a "promiscuous listening" mode. I believe omission of the outer VLAN tag suffers from the same ambiguity. For instance, it is possible for two devices to have a "point to point" relationship within a VLAN context that would nto be the case without the VLAN context. Hence it appears we would have to be explicit in what we mean by "point to point" link and how we expect that the entities (RBridges) involved would be able to disambiguate this p2p status for any given link. If we are saying that two devices - using some means out of scope for our specification - are somehow aware of an unambiguous point-to-point relationship between them and can therefore use any MAC DA on transmission, and ignore it on receipt, we could make the same argument for virtually any encapsulation choice we might prefer. But, it would be as valid to observe that we don't need to specify what is - in essence - an out-of-context (mis)behavior between consenting implementations... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 11:27 PM > To: Rbridge@postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l933QhcC000283 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:26:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1191382003!8576657!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27558 invoked from network); 3 Oct 2007 03:26:43 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 3 Oct 2007 03:26:43 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l933Qgu0001747 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:26:42 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l933QgnT013286 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:26:42 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l933QfFr013283 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:26:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Oct 2007 23:26:38 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Check: Point to Point links Thread-Index: AcgFbTWE9oP+tClqRJuKgVk2MsooBg== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l933QhcC000283 Subject: [rbridge] Consensus Check: Point to Point links X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 03:26:56 -0000 Status: RO Content-Length: 578 This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: If it is known that a link is a point to point link between two RBridges, then the outer header, if it is an Ethernet header, can have any source and/or destination addresses, those addresses will be ignored on receipt, and the outer VLAN tag can be omitted. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l933PMiw000132 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:25:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1191381921!1487521!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7896 invoked from network); 3 Oct 2007 03:25:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 3 Oct 2007 03:25:21 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l933PKor001571 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:25:20 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l933PK6i012805 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:25:20 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l933PJAd012800 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:25:19 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Oct 2007 23:25:16 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Check: Egress processing of unicast not locally known Thread-Index: AcgFbQQ7CB53pCMuQLq7lbwJdGzn5A== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l933PMiw000132 Subject: [rbridge] Consensus Check: Egress processing of unicast not locally known X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 03:25:56 -0000 Status: RO Content-Length: 887 This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Egress RBridges that receive a known unicast TRILL data frame whose inner destination address is not known locally should send the native form of the frame out on every link for which the RBridge is DRB for the frame's VLAN unless it knows that an end station with that MAC address could not be on that link. (For example, there is a layer-2 registration procedure for end stations on that link and the destination MAC address in question is not registered.) This is a local decision. No "error" message will be defined for this condition at this time. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l933Oj8k000034 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:24:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1191381884!26073156!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29036 invoked from network); 3 Oct 2007 03:24:44 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 3 Oct 2007 03:24:44 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l933OYGX001461 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:24:44 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l933OXmZ015374 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:24:34 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l933OXol015370 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:24:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Oct 2007 23:24:30 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031840B8@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Check: Inner Multicast Address of TRILL IS-IS Frames Thread-Index: AcgFbOlHEI6K3Ud2QiSrPBf/fZ2cTQ== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l933Oj8k000034 Subject: [rbridge] Consensus Check: Inner Multicast Address of TRILL IS-IS Frames X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 03:25:03 -0000 Status: RO Content-Length: 461 This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Utilize a different multicast address ("All-IS-IS-RBridges"), allocated to RBridges, as the inner MAC destination address of TRILL IS-IS Frames. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l933OFjV029978 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:24:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1191381853!24055962!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 9288 invoked from network); 3 Oct 2007 03:24:14 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 3 Oct 2007 03:24:14 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l933O3oc023163 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:24:13 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l933O2Ds023749 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:24:02 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l933O0tp023728 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:24:01 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Oct 2007 23:23:58 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031840B7@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790030B9100@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call: MAC learning timers Thread-Index: AcfxpynKRN3p3yFxSAiq5rqsb7cQJgHGM/wgAxSAx1A= References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <18145.10990.755022.598448@gargle.gargle.HOWL> <46E15D01.50702@isi.edu><18145.37191.943519.790828@gargle.gargle.HOWL><46E1DEFC.9090502@isi.edu> <3870C46029D1F945B1472F170D2D9790030B9100@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l933OFjV029978 Subject: [rbridge] Consensus Call: MAC learning timers X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 03:24:31 -0000 Status: RO Content-Length: 3857 The consensus at the Chicago meeting that the MAC address learning timers in Rbridges should follow the IEEE 802.1-2005 (Section 8.8.3) recommendations is confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, September 17, 2007 1:37 AM To: Joe Touch; James Carlson Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: MAC learning timers It's just a recommendation in the IEEE 802.1Q-2005 Standard as quoted below. Donald >From IEEE 802.1Q-2005, Section 8.8.3, "Dynamic Filtering Entries", page 56: The ageing out of Dynamic Filtering Entries ensures that end stations that have been moved to a different part of the network will not be permanently prevented from receiving frames. It also takes account of changes in the active topology of the network that can cause end stations to appear to move from the point of view of the bridge; i.e., the path to those end stations subsequently lies through a different Bridge Port. The Ageing Time may be set by management (Clause 12). A range of applicable values and a recommended default is specified in Table 8-3; this is suggested to remove the need for explicit configuration in most cases. If the value of Ageing Time can be set by management, the Bridge shall have the capability to use values in the range specified, with a granularity of 1 s. Table 8-3-Ageing time parameter value Parameter Recommended Default Value Range Ageing Time 300.0 s. 10.0 - 1,000,000.0s NOTE 4-The granularity is specified in order to establish a common basis for the granularity expressed in the management operations defined in Clause 12, not to constrain the granularity of the actual timer supported by a conformant implementation. If the implementation supports a granularity other than 1 s, then it is possible that the value read back by management following a Set operation will not match the actual value expressed in the Set. -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Friday, September 07, 2007 7:30 PM To: James Carlson Cc: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: MAC learning timers James Carlson wrote: > Joe Touch writes: >> James Carlson wrote: >>> Instead, our role is to design TRILL, and specify what's _required_ to >>> make that work. Is there an issue here that, if someone had a good >>> reason to use some other set of defaults for these parameters, doing >>> so would break TRILL? >> I'm concerned about breaking the non-TRILL devices by TRILL behavior. If >> our caches have timeouts different from theirs, then the overall system >> won't be as plug-and-play -- or, more specifically, more 'replug-and-play'. >> >> That's why we're recommending IEEE values and defaults; that didn't come >> out of the blue. > > Yes, and that's precisely the reason to "recommend" those defaults -- > as in BCP 14 "SHOULD." I never did suggest that they came out of the > blue or that anyone ought to ignore them. > > However, as a matter of operating TRILL, they don't appear (to me at > least) to be key issues that will cause TRILL failure. That means > they're not a "MUST." That's fine. Let's hear what others think. I just want to make sure we're picking the right one and understanding what we're picking; I really didn't have an a-priori decision. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l933Ib9c028170 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:18:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1191381514!8575998!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 21625 invoked from network); 3 Oct 2007 03:18:34 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-153.messagelabs.com with SMTP; 3 Oct 2007 03:18:34 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l933IWDd016255 for <Rbridge@postel.org>; Tue, 2 Oct 2007 20:18:34 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l933IVpv020587 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:18:31 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l933ITTe020563 for <Rbridge@postel.org>; Tue, 2 Oct 2007 22:18:30 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Oct 2007 23:18:26 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790031840B4@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790030B9103@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call: V-field reversion Thread-Index: AcfwjUYepJIzALPJQ+iN2Xwc+rzZ5QIMbscgAxSg6SA= References: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com><46E00624.3060302@isi.edu> <3870C46029D1F945B1472F170D2D9790030B9103@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l933Ib9c028170 Subject: [rbridge] Consensus Call: V-field reversion X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 03 Oct 2007 03:19:06 -0000 Status: RO Content-Length: 1884 This consensus from the Chicago meeting has been confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, September 17, 2007 1:37 AM To: Joe Touch Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Right. (I'm generally using the somewhat less formal wording from the minutes in these consensus checks.) Thanks, Donald -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Thursday, September 06, 2007 9:53 AM To: Eastlake III Donald-LDE008 Cc: Rbridge@postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Chicago meeting for a change from protocol draft -05: > > Eliminate different V field values and revert to two version bits > and two reserved bits with the previous provisions that this draft > specifies version zero, frames with an unknown version are > discarded, reserved bits MUST be zero and are ignored on receipt. Minor nit to avoid ambiguity: ...MUST be _set to_ zero... > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
- [rbridge] Separating DRB election from encapsulat… Radia Perlman
- [rbridge] Separating DRB election from encapsulat… Eastlake III Donald-LDE008