[rbridge] Shared VLAN learning: What is it and why should we care?
Radia.Perlman at sun.com (Radia Perlman) Sun, 01 April 2007 06:39 UTC
From: "Radia.Perlman at sun.com"
Date: Sat, 31 Mar 2007 23:39:45 -0700
Subject: [rbridge] Shared VLAN learning: What is it and why should we care?
In-Reply-To: <460D54BB.1010504@cisco.com>
References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com>
Message-ID: <460F53B1.6080103@sun.com>
I don't understand a lot of what's being said on this thread, and I suspect everyone is talking about subtly different solutions to a fairly esoteric set of somewhat related problems (sharing an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, ...). As Dale Carder mentioned, and gave us some pointers, there are several somewhat overlapping proposals floating around the industry. I believe there isn't a single cleanly stated problem, or a single cleanly statable solution. So TRILL should do something. Whatever it is, I want to be able to understand what it is that RBridges should do. But to answer Russ's questions (see at bottom of this note) -- the current RBridge protocol spec assumes that *all* RBridges filter based on VLAN tag. So an RBridge in the core, even if it doesn't attach to VLAN A, knows which other RBridges do. This allows efficient distribution of VLAN A traffic, for instance, the IS-IS announcements of VLAN A endnode information. The reason we need to let all the RBridges know what VLANs are in a group, say {Z, A, B, C, D}, where Z is the primary, is so that an RBridge in the core knows that something tagged with VLAN Z needs to be transmitted to all links in any of the 5 VLAN tags {Z, A, B, C, D} and something tagged with one of the secondaries, say A, needs to go to A and Z. An example -- suppose there is an IP router R on VLAN Z (the primary). When R does an ARP for an endnode "d" in the IP subnet, R has no idea about VLANs, and the RBridge RB1 that R attaches to, although RB1 might know that there's a grouping of VLANs, doesn't know which VLAN to transmit the ARP to. Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a copy to each of {Z, A, B, C, D}. So RBridges in the core have to know to send the ARP along the distribution tree to all ports that are in any of the VLANs in the set. In theory we could ignore VLAN tags, except at the final hop, and then, as Russ said, it would be just an optimization for the RBridges in the core to know about the groupings. But I still think things would be weird if the final RBridges had inconsistent configurations of the VLAN groupings, so I think it's a good idea to make sure all the RBridges agree on the groupings. To summarize, it's good for them to agree because of three reasons: a) we can do optimal delivery of multicasts, filtering within the core rather than just at the final hop b) we detect misconfiguration c) we allow more central configuration (we don't need to configure all the RBridges, though that's a bit dangerous if all the RBridges that have been configured go down, since suddenly the groupings might disappear) Radia As for Russ's last questions: >> 3. Does this have a larger impact on multicast, or smaller? I don't understand the question, though given that he put a smiley face in, perhaps it was a joke. I'm hoping that someone, tomorrow, will inform me that all this SVL/FID stuff was a joke... Radia Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > > >>To avoid requiring configuration of all RBridges with these FIDs, and >>still allow multicast filtering, I propose we have RBridges advertise, >>in their IS-IS core instance, FIDs that they are configured with. So at >>least one RBridge will say "Hey guys, >>I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other >>RBridges will, I guess >>believe him. >> >> > >I'm trying to sort through this entire thing, and I wanted to ask: > >1. The reason we'd want to configure this on all rbridges would be to >optimize traffic flow? > >2. If 1 is true, and we didn't do the configuration on all rbridges, how >much less efficient would the rbridge network be? > >3. Does this have a larger impact on multicast, or smaller? > >:-) > >Russ > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.3 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg >DSuMdrc10XgRmx8w4PdN/f4= >=ItDw >-----END PGP SIGNATURE----- > > 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 l316dije029839 for <rbridge@postel.org>; Sat, 31 Mar 2007 23:39:45 -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 <0JFT00JBA3TUZ900@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 31 Mar 2007 23:39:30 -0700 (PDT) Received: from sun.com ([129.150.16.145]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFT0087Y3TSJ700@mail.sunlabs.com> for rbridge@postel.org; Sat, 31 Mar 2007 23:39:29 -0700 (PDT) Date: Sat, 31 Mar 2007 23:39:45 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <460D54BB.1010504@cisco.com> To: Russ White <riw@cisco.com> Message-id: <460F53B1.6080103@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 01 Apr 2007 06:40:09 -0000 Status: RO Content-Length: 4104 I don't understand a lot of what's being said on this thread, and I suspect everyone is talking about subtly different solutions to a fairly esoteric set of somewhat related problems (sharing an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, ...). As Dale Carder mentioned, and gave us some pointers, there are several somewhat overlapping proposals floating around the industry. I believe there isn't a single cleanly stated problem, or a single cleanly statable solution. So TRILL should do something. Whatever it is, I want to be able to understand what it is that RBridges should do. But to answer Russ's questions (see at bottom of this note) -- the current RBridge protocol spec assumes that *all* RBridges filter based on VLAN tag. So an RBridge in the core, even if it doesn't attach to VLAN A, knows which other RBridges do. This allows efficient distribution of VLAN A traffic, for instance, the IS-IS announcements of VLAN A endnode information. The reason we need to let all the RBridges know what VLANs are in a group, say {Z, A, B, C, D}, where Z is the primary, is so that an RBridge in the core knows that something tagged with VLAN Z needs to be transmitted to all links in any of the 5 VLAN tags {Z, A, B, C, D} and something tagged with one of the secondaries, say A, needs to go to A and Z. An example -- suppose there is an IP router R on VLAN Z (the primary). When R does an ARP for an endnode "d" in the IP subnet, R has no idea about VLANs, and the RBridge RB1 that R attaches to, although RB1 might know that there's a grouping of VLANs, doesn't know which VLAN to transmit the ARP to. Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a copy to each of {Z, A, B, C, D}. So RBridges in the core have to know to send the ARP along the distribution tree to all ports that are in any of the VLANs in the set. In theory we could ignore VLAN tags, except at the final hop, and then, as Russ said, it would be just an optimization for the RBridges in the core to know about the groupings. But I still think things would be weird if the final RBridges had inconsistent configurations of the VLAN groupings, so I think it's a good idea to make sure all the RBridges agree on the groupings. To summarize, it's good for them to agree because of three reasons: a) we can do optimal delivery of multicasts, filtering within the core rather than just at the final hop b) we detect misconfiguration c) we allow more central configuration (we don't need to configure all the RBridges, though that's a bit dangerous if all the RBridges that have been configured go down, since suddenly the groupings might disappear) Radia As for Russ's last questions: >> 3. Does this have a larger impact on multicast, or smaller? I don't understand the question, though given that he put a smiley face in, perhaps it was a joke. I'm hoping that someone, tomorrow, will inform me that all this SVL/FID stuff was a joke... Radia Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > > >>To avoid requiring configuration of all RBridges with these FIDs, and >>still allow multicast filtering, I propose we have RBridges advertise, >>in their IS-IS core instance, FIDs that they are configured with. So at >>least one RBridge will say "Hey guys, >>I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other >>RBridges will, I guess >>believe him. >> >> > >I'm trying to sort through this entire thing, and I wanted to ask: > >1. The reason we'd want to configure this on all rbridges would be to >optimize traffic flow? > >2. If 1 is true, and we didn't do the configuration on all rbridges, how >much less efficient would the rbridge network be? > >3. Does this have a larger impact on multicast, or smaller? > >:-) > >Russ > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.3 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg >DSuMdrc10XgRmx8w4PdN/f4= >=ItDw >-----END PGP SIGNATURE----- > > 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 l2UNIG8J024964 for <rbridge@postel.org>; Fri, 30 Mar 2007 16:18: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: Fri, 30 Mar 2007 14:43:01 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014671E0@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BA305@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? thread-index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQAAJwEQAAAMshMAACF4EQ References: <34BDD2A93E5FD84594BB230DD6C18EA20146718B@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BA305@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Russ White" <riw@cisco.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 l2UNIG8J024964 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 23:18:43 -0000 Status: RO Content-Length: 3377 Caitlin, inline > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Friday, March 30, 2007 1:45 PM > To: Silvano Gai; Russ White; Radia Perlman > Cc: rbridge@postel.org > Subject: RE: [rbridge] Shared VLAN learning: What is it and why should we > care? > > > > > -----Original Message----- > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > Sent: Friday, March 30, 2007 1:26 PM > > To: Caitlin Bestler; Russ White; Radia Perlman > > Cc: rbridge@postel.org > > Subject: RE: [rbridge] Shared VLAN learning: What is it and > > why should we care? > > > > Caitlin, > > > > You say: > > > > > > > > The most recent drafts effectively block that, by only distributing > > > endnode discovery information within a VLAN. > > > > Can we agree that: > > - FID is a concept internal to the box; > > - FID is never present in any frame; > > - The VID to FID mapping is internal to each box and > > potentially different on different boxes; > > - The VID to FID mapping is never propagated in today networks. > > > > If we have agreed the previous, let's consider what triggers learning: > > - In bridges the reception of a data frame with a {VID, MAC > > address} pair; > > - In Rbridges the reception of a per VLAN instance ISIS PDU > > that contains a {VID, MAC address} pair. > > I don't see any difference. > > > > Following the lines of the example Radia posted, endnode IP J MAC X > was previously on VLAN A where RBridge S learned of its existence. > > Now endnode IP J/MAC X is migrated to VLAN B where RBRidge T learns > of its existence. This is an extremely plausible scenario where VLANs > A and B represent logical functions within a company. Or it could be as > simple as someone carrying a laptop from a "secure" area to another > area within the same buildig. > > Meanwhile, Router Z receives an incoming packet with destination IP J. > Since that is not in its ARP tables, it sends an ARP request. On which VLAN does the router Z send the request? It must be either A or B. The way this is decided is a longest prefix match on IP J that returns a directly connected sub-interface. The VLAN associated to that sub-interface is the one on which the ARP is sent. If it is A, S replies. If it is B, T replies. What am I missing? Two more points: 1) An endnode cannot move from one VLAN to another keeping its IP address (excluding the Private VLAN case that was not under discussion when this thread about SVL started). 2) IMHO ARP proxy in Rbridges creates more corner cases of the problem that it solves. In Dinesh presentation from 03 to 04 there was a slide about making it optional and separating it to another draft. -- Silvano Both > RBridge S and RBridge T, acting as PRoxy ARPs, will answer. > > What is Router Z supposed to do? If it just accepts both ARP responses > and only keeps the last one, it could easily forward the packet to > VLAN A and thereby cause the connection to ultimately drop. > > The root cause of this problem is that RBridge T did not share its > discovery of IP J/MAC X with RBridge S, even though they are part > of the same FID. > > This can be done with exposing VID/FID mappings on the wire. You > export an "discovery-only VID" list instead. But I do not see how it > can be done if discovery announcements are shared exclusively > within VIDs without exception. > > Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UKk2nN013559 for <rbridge@postel.org>; Fri, 30 Mar 2007 13:46:02 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 30 Mar 2007 13:45:54 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B0E732AE; Fri, 30 Mar 2007 13:45:54 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 9A2932B4; Fri, 30 Mar 2007 13:45:53 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDC09605; Fri, 30 Mar 2007 13:45:48 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9148469CAA; Fri, 30 Mar 2007 13:45:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Mar 2007 13:45:22 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA305@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20146718B@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQAAJwEQAAAMshMA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Russ White" <riw@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A13A88837010620226-04-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2UKk2nN013559 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 20:46:13 -0000 Status: RO Content-Length: 2232 > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Friday, March 30, 2007 1:26 PM > To: Caitlin Bestler; Russ White; Radia Perlman > Cc: rbridge@postel.org > Subject: RE: [rbridge] Shared VLAN learning: What is it and > why should we care? > > Caitlin, > > You say: > > > > > The most recent drafts effectively block that, by only distributing > > endnode discovery information within a VLAN. > > Can we agree that: > - FID is a concept internal to the box; > - FID is never present in any frame; > - The VID to FID mapping is internal to each box and > potentially different on different boxes; > - The VID to FID mapping is never propagated in today networks. > > If we have agreed the previous, let's consider what triggers learning: > - In bridges the reception of a data frame with a {VID, MAC > address} pair; > - In Rbridges the reception of a per VLAN instance ISIS PDU > that contains a {VID, MAC address} pair. > I don't see any difference. > Following the lines of the example Radia posted, endnode IP J MAC X was previously on VLAN A where RBridge S learned of its existence. Now endnode IP J/MAC X is migrated to VLAN B where RBRidge T learns of its existence. This is an extremely plausible scenario where VLANs A and B represent logical functions within a company. Or it could be as simple as someone carrying a laptop from a "secure" area to another area within the same buildig. Meanwhile, Router Z receives an incoming packet with destination IP J. Since that is not in its ARP tables, it sends an ARP request. Both RBridge S and RBridge T, acting as PRoxy ARPs, will answer. What is Router Z supposed to do? If it just accepts both ARP responses and only keeps the last one, it could easily forward the packet to VLAN A and thereby cause the connection to ultimately drop. The root cause of this problem is that RBridge T did not share its discovery of IP J/MAC X with RBridge S, even though they are part of the same FID. This can be done with exposing VID/FID mappings on the wire. You export an "discovery-only VID" list instead. But I do not see how it can be done if discovery announcements are shared exclusively within VIDs without exception. 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 l2UKQRNO007769 for <rbridge@postel.org>; Fri, 30 Mar 2007 13:26: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: Fri, 30 Mar 2007 13:26:20 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20146718B@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BA2CF@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? thread-index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQAAJwEQA= References: <460D54BB.1010504@cisco.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BA2CF@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Russ White" <riw@cisco.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 l2UKQRNO007769 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 20:26:41 -0000 Status: RO Content-Length: 1145 Caitlin, You say: > > The most recent drafts effectively block that, by only distributing > endnode discovery information within a VLAN. Can we agree that: - FID is a concept internal to the box; - FID is never present in any frame; - The VID to FID mapping is internal to each box and potentially different on different boxes; - The VID to FID mapping is never propagated in today networks. If we have agreed the previous, let's consider what triggers learning: - In bridges the reception of a data frame with a {VID, MAC address} pair; - In Rbridges the reception of a per VLAN instance ISIS PDU that contains a {VID, MAC address} pair. I don't see any difference. Both Rbridges and Bridges learn this information as SVL or IVL, depending on their configuration. It is an internal decision of each device. It is not something that is or must be propagated among devices. Again, I don't see any difference. The only caution is that an RBridge must only include in its ISIS announcement the {VID, MAC address} pairs that it has learnt observing traffic, not the ones that derives from its internal mapping of VIDs to FIDs. -- Silvano Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UJFSDd018477 for <rbridge@postel.org>; Fri, 30 Mar 2007 12:15:29 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 30 Mar 2007 12:15:21 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0FFBE2AF; Fri, 30 Mar 2007 12:15:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id EED602AE; Fri, 30 Mar 2007 12:15:20 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDB87311; Fri, 30 Mar 2007 12:15:19 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 215A769CA7; Fri, 30 Mar 2007 12:15:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Mar 2007 12:15:03 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA2CF@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <460D54BB.1010504@cisco.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQ From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Russ White" <riw@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A13BE433A410515852-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2UJFSDd018477 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 19:15:41 -0000 Status: RO Content-Length: 3528 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White > Sent: Friday, March 30, 2007 11:20 AM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should we care? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > To avoid requiring configuration of all RBridges with these > FIDs, and > > still allow multicast filtering, I propose we have RBridges > advertise, > > in their IS-IS core instance, FIDs that they are configured > with. So > > at least one RBridge will say "Hey guys, I think VLANs Z, > A, B, C, and > > D form a FID with primary=Z" and the other RBridges will, I guess > > believe him. > > I'm trying to sort through this entire thing, and I wanted to ask: > > 1. The reason we'd want to configure this on all rbridges > would be to optimize traffic flow? > > 2. If 1 is true, and we didn't do the configuration on all > rbridges, how much less efficient would the rbridge network be? > > 3. Does this have a larger impact on multicast, or smaller? > No, I'd say that the purpose of this is to enable bridge that do Shared Learning to also be RBridges. The most recent drafts effectively block that, by only distributing endnode discovery information within a VLAN. An RBridge that did shared learning would need to know of updates not so that it could forward packets to those addresses, but so that it could delete conflicting uses of the same MAC address from its tables. I believe there is a strong concensus that we do not want to forward all endnode discovery updates to all RBridges on the presumption that any of them could be doing shared learning. Since most bridges, and presumably most RBridges, do Independent Learning this would be an undesirable default. That leaves, in my evaluation, two ways to deal with this issue. One, you could simply state that the shared discovery information assumes Independent Learning and effectively require all RBridges to do independent learning (theoretically they could do shared learning "locally" but then share information as though they were independent, but that would be harder than just doing independent learning). Essentially, go ahead and block it, but be explicit about this restriction in the specification. Two, you could include information in the RBridge advertisements that lets you more accurately determine which RBridges require which endnode discovery updates. For example, knowing VID to FID mapping for each RBridge would definitely accomplish this. I have suggested that a simpler listing of "additional VIDs" would be sufficient. In either case the goal is not to send more unicast or multicast traffic, merely to send more endnode discoveries. Radia's email cites a scenario where migration of IP addresses between VLANs is normal, and it is highly desirable that a given IP and MAC Address be found in at most one of the VLANs. The shared router's Proxy ARP wants to have a single location for the IP address, not a current and a stale one. This is a scenario that should be kept in mind. The other common motivation for shared learning is even simpler to understand; 48-bit keys are cheaper than 60-bit keys. If you have 48-bit keys, changing to 60-bit keys can be more challenging that just adding functionality by firmware/software. So there are motivations for having a global MAC Address actually be global at both the usage and implementation planes. 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 l2UIkspf010667 for <rbridge@postel.org>; Fri, 30 Mar 2007 11:46:54 -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, 30 Mar 2007 11:46:41 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20146711B@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <460B6304.3020507@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? thread-index: Acdx0NmECgz5lw9xR+OCHNz8951f4gBKC8Uw References: <460B6304.3020507@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, <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 l2UIkspf010667 Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 18:47:05 -0000 Status: RO Content-Length: 5130 Radia, Catching up with my emails, inline ... snip ... > > To avoid requiring configuration of all RBridges with these FIDs, and > still allow multicast filtering, I propose we have RBridges advertise, > in their IS-IS core instance, FIDs that they are configured with. So at > least one RBridge will say "Hey guys, > I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other > RBridges will, I guess > believe him. > > What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that > FID Z = {Z,A,D, F} is an interesting question, but at least there is > enough information to log an error. Lot of possibilities for overlapping > FIDs, inconsistent FIDs, etc. > I assume all those will be errors. If there is a FID called "Z", then > everyone better agree about what the > VLAN membership of Z is, and none of the VLANs in Z better be in any > other FIDs. > Today bridges don't announce the association between VID and FID and I am not sure why RBridges should act differently. There are many combinations of FID to VID mapping that are perfectly compatible, for example an RBridge may have more granularity than another RBridge. > Once there is a FID of {Z, A, B, C, D}, there will no longer be > a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. The main purpose of the VLAN instance is learning of end-node MAC addresses. This is always done on the VID, never on the FID. Therefore IMHO it is incorrect to suppress the IS-IS VLAN instances. I am even not sure what that means. In IVL there is a FID for each VID, are we going to suppress all the VID? Also consider that it is always legal to insert an IVL RBridge in a network of RBridges that do SVL. How will the IVL Rbridge learn, if there are no more per VLAN instances? I repeat what I already said in a previous email: "... in bridges what triggers learning is always the reception of a frame that has a {VID, MAC-address} pair. The fact that the VID, on that particular bridge, shares the FID with other VIDs is what causes shared learning. But shared learning NEVER propagates. TRILL MUST NOT propagate shared learning. IT MUST always propagate {VID, MAC-address}. Recipients may decide to do individual or shared learning." > Instead > the Z-instance will announce VLANs A, B, C, and D membership as well as > VLAN Z membership. > > The Z-instance of IS-IS will specify which MAC addresses are in which > VLAN. > So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f}, > {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case > letters are endnode MAC > addresses. The upper case letters are 12-bit VLAN IDs. > > Multicast packets marked as VLAN Z (inner VLAN) will be sent to > all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of > IS-IS will > be delivered to all RBridges in Z, A, B, C, and D. > > That way RBridges with ports in Z, A, B, C, and/or D will learn all the > endnode addresses > in any of those VLANs (all the ports in FID Z). > > If ingress RB1 is attached to Z, and receives a packet with > destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z > 's endnode > membership. As soon as RB1 finds it, let's say, as reported by > RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2, > leaving the tag as Z. When RB2 decapsulates the packet, I assume it will > rewrite the inner VLAN tag from "Z" to "D". > > > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > Conclusions: > > The changes to the spec: > > a) announce in the core instance, FIDs as a set of VLANs, the > first listed being the "primary". I don't see why this is necessary or useful. > > b) multicast forwarding: if the packet is (inner) tagged with > the VLAN ID of a primary VLAN in a FID, The frames MUST always be tagged with the VLAN they belong to, not with the primary VLAN. -- Silvano forward the packet on > all in the links in the selected tree that lead to any of the VLANs > in the FID. If the packet is tagged with the VLAN ID of a non-primary > VLAN in a FID, forward the packet on all the ports that reach > links in either that VLAN or in the primary VLAN for that FID. > > c) when ingressing a packet with destination D, tagged with a > VLAN tag of a primary VLAN in a FID, check the endnode information > for all the VLANs in the FID to determine the egress RBridge. > > d) when ingressing a packet with destination D, tagged with > a VLAN tag of a secondary VLAN in a FID, check the endnode > information for exactly two VLANs; the one the packet is > currently tagged with, and the primary VLAN for that FID, to > determine the egress RBridge. > > e) if two RBridges, in the core instance, report inconsistent FID > membership, what should we do? > > (Note: There was a fortune cookie program in Unix, one of the fortunes > being "Never check for an error > condition that you don't know how to handle". For the record--I think > that's a cute joke but really bad policy.). > > Radia > > > > _______________________________________________ > 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 l2UIJcl2001925 for <rbridge@postel.org>; Fri, 30 Mar 2007 11:19:38 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2007 11:19:38 -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 l2UIJcIc019305; Fri, 30 Mar 2007 11:19:38 -0700 Received: from [128.107.114.151] (dhcp-128-107-114-151.cisco.com [128.107.114.151]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2UIJcEi023150; Fri, 30 Mar 2007 18:19:38 GMT Message-ID: <460D54BB.1010504@cisco.com> Date: Fri, 30 Mar 2007 14:19:39 -0400 From: Russ White <riw@cisco.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <460B6304.3020507@sun.com> In-Reply-To: <460B6304.3020507@sun.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1041; t=1175278778; x=1176142778; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20<riw@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Shared=20VLAN=20learning=3A=20What=20is=2 0it=20and=20why=20should=20we=0A=20care? |Sender:=20; bh=RadJTSRthmPDac94gHuhbS1imkj0P3U7a/kxEL+CSJE=; b=BXbSECO/K/LltftDzMPR+Hok4sNqCiKrhlXV+OzVj7687/hPHx8aEQHfw0WgkEuN3hERIjTx O/86aLshgdffj2QirtsBA5wkN4wyRNt1RiZQDsHUywM3afHbWzg6fGBI; Authentication-Results: sj-dkim-2; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 18:20:05 -0000 Status: RO Content-Length: 1034 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > To avoid requiring configuration of all RBridges with these FIDs, and > still allow multicast filtering, I propose we have RBridges advertise, > in their IS-IS core instance, FIDs that they are configured with. So at > least one RBridge will say "Hey guys, > I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other > RBridges will, I guess > believe him. I'm trying to sort through this entire thing, and I wanted to ask: 1. The reason we'd want to configure this on all rbridges would be to optimize traffic flow? 2. If 1 is true, and we didn't do the configuration on all rbridges, how much less efficient would the rbridge network be? 3. Does this have a larger impact on multicast, or smaller? :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg DSuMdrc10XgRmx8w4PdN/f4= =ItDw -----END PGP SIGNATURE----- Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UHwjRo024919 for <rbridge@postel.org>; Fri, 30 Mar 2007 10:58:45 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 30 Mar 2007 10:58:35 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A3A812B1; Fri, 30 Mar 2007 10:58:35 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id DB4762B3; Fri, 30 Mar 2007 10:58:34 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDB65299; Fri, 30 Mar 2007 10:58:32 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 2E40F69CA3; Fri, 30 Mar 2007 10:58:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Mar 2007 10:58:31 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA286@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <460B6304.3020507@sun.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdx0YXEJDs4bfPnQXu2XCSKkryjcQBIk5/A From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A13904137010567086-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2UHwjRo024919 Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 17:59:04 -0000 Status: RO Content-Length: 2270 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Wednesday, March 28, 2007 11:56 PM > To: rbridge@postel.org > Subject: [rbridge] Shared VLAN learning: What is it and why > should we care? > > > > But how do two endnodes in different VLANs, but in the same > IP address block communicate? S will ARP, like before, > because IP nodes are (blissfully) unaware of VLANs. > The answer people tell me > is "in that case communication between S and D has to go > through the IP router". OK. So how would that work? The > answer I get is "the switch does proxy ARP on behalf of the > IP router". > I don't understand that. How does the > switch know *when* to proxy ARP? The switch doesn't > necessarily know which VLAN node D is in. > As others have already answered, the "switch" does not forward the traffic between the two VLANs sharing the same IP subnet, but rather some router-like ProxyARP functionality. This can be desirable/acceptable precisely because the traffic is going through this L3-aware entity. The two sub-groups may be willing to exchange traffic, but unwilling to grant each other unchecked/unlogged/unfiltered access. If the traffic can only be forwarded at L3 it is subject to L3 firewalling/logging/etc. While the same protocols did not apply, I recall a very similar issue with traffic between cable modems. There was no real reason to flat forbid such traffic, but it was definitely something that you did not want to be handled at the reflex/L2 layer where it could not be throttled/ logged/monitored/etc. > > e) if two RBridges, in the core instance, report inconsistent FID > membership, what should we do? > One way to avoid that would be for each RBridge to simply advertise which VIDs it forwarded to, and which additional VIDs that its FIDs overlapped with. The first set determines what it needs to know for forwarding purposes, the second set determines what it needs to know for purposes of deleting entries. Expressed that way, there is no need for FIDs to be consistent. At least for RBridge protocol purposes, consistency of FID mapping is still highly desirable for the preservation of network administrator sanity. 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 l2UHWufx017546 for <rbridge@postel.org>; Fri, 30 Mar 2007 10:32:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2007 10:32:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2UHWtdb024681 for <rbridge@postel.org>; Fri, 30 Mar 2007 10:32:55 -0700 Received: from [128.107.114.151] (dhcp-128-107-114-151.cisco.com [128.107.114.151]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UHWrMF002727 for <rbridge@postel.org>; Fri, 30 Mar 2007 17:32:55 GMT Message-ID: <460D49C3.8060100@cisco.com> Date: Fri, 30 Mar 2007 13:32:51 -0400 From: Russ White <riw@cisco.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: rbridge@postel.org References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> In-Reply-To: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1414; t=1175275975; x=1176139975; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20<riw@cisco.com> |Subject:=20Re=3A=20[rbridge]=20Last=20Call=3A=20draft-ietf-trill-routing -reqs=20(TRILL=20Routing=0A=20Requirements=20in=20Support=20of=20RBridges) =20to=20Informational=20RFC |Sender:=20; bh=clWrbvl8hFQ7STdhTwhzAxNCBdhR38CsZuvF+zw6oyI=; b=SpXi9NBZ6/lZYY02h+DsBbkKX8dFTUxOvMgas5fS+4xE6H1V8i10xMAPvz2uT8TOioor4yla 5uPfk+f0ia9oPvzKGo60jMWNlyjyUUtchUEBWAjY98TnvVrfzfKr0CXs; Authentication-Results: sj-dkim-3; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC 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, 30 Mar 2007 17:33:04 -0000 Status: RO Content-Length: 1401 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have reviewed this draft, and it looks fine to move forward. :-) Russ The IESG wrote: > The IESG has received a request from the Transparent Interconnection of > Lots of Links WG (trill) to consider the following document: > > - 'TRILL Routing Requirements in Support of RBridges ' > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0 > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDUnDER27sUhU9OQRAlzmAKCoQJYPvvBSpfSGhtZ2MDz4c42Z9QCfa9Gd 9NHP/EKeE6dvru91n4QNSr0= =t7jc -----END PGP SIGNATURE----- Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2U4ItJ3014516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Thu, 29 Mar 2007 21:18:55 -0700 (PDT) Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) id <0JFP003017ZI4D00@smtpauth1.wiscmail.wisc.edu> for rbridge@postel.org; Thu, 29 Mar 2007 23:18:54 -0500 (CDT) Received: from [192.168.1.102] (mdsnwikwbas08-pool6-a4.mdsnwikw.tds.net [69.129.197.4]) by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTPSA id <0JFP001VT7ZHDG00@smtpauth1.wiscmail.wisc.edu>; Thu, 29 Mar 2007 23:18:54 -0500 (CDT) Date: Thu, 29 Mar 2007 23:18:52 -0500 From: "Dale W. Carder" <dwcarder@doit.wisc.edu> In-reply-to: <460B6304.3020507@sun.com> To: Radia Perlman <Radia.Perlman@sun.com> Message-id: <00F25E7D-3CB9-4C68-951D-5C649E81C10A@doit.wisc.edu> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Report: AuthenticatedSender=yes, SenderIP=192.168.1.102 X-Spam-PmxInfo: Server=avs-11, Version=5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.29.210642, SenderIP=192.168.1.102 References: <460B6304.3020507@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dwcarder@doit.wisc.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 30 Mar 2007 04:19:14 -0000 Status: RO Content-Length: 10833 Comments inline: On Mar 29, 2007, at 1:56 AM, Radia Perlman wrote: > Hopefully this explanation will be clear enough for people to at least > figure out whether we > are all talking about the same thing. Of course, feel free to > correct me > if my understanding is wrong. > > First we need to understand what problem it is trying to solve. It may be helpful to read IEEE 802.1Q-2005, Annex B.1.3 Asymmetric VLANs Also, similar problems (with different solutions, of course) are given in RFC 3069 and also draft-sanjib-private-vlan-06.txt TRILL sould allow one of those solutions in addition to allowing Shared Vlan Learning as described in 802.1q. I think the ideas behind this also somewhat remind me of ATM half- bridging. > This is > my understanding of that: > > THE PROBLEM > ------------------ > > Someone has a block of IP addresses to divvy up among > a set of different organizations. Let's say the address block has > 100 addresses, and there are 4 organizations. One strategy might be > to give each organization 1/4 of the IP addresses each, and then > possibly even > wind up having separate IP subnets (if the addresses can be assigned > to be in different prefixes). > > The problem, though, is that you don't know in advance how many > addresses > each organization will need. Perhaps even the IP address block is > oversubscribed, > so that there are more potential switch ports than IP addresses, > and you > just hope that not everyone connects at once (or if they do, they > don't > get an IP address). > > So we're going to allow basically random assignment of IP addresses > within the IP address block to each of the four organizations. > > But you still want to keep the organizations separate, as in, they > don't > see each other's traffic. They > don't get bothered with each other's ARPs and so forth. And you don't > want to change the IP nodes > (endnodes or routers) > to know anything funny is going on. > > So you use VLANs to separate the communities. A particular port > on a switch/bridge in a L2 cloud > is configured as to what community the attached endnode belongs to, by > having it configured with a VLAN ID. > > But you'd like all the IP nodes in the cloud, even though in different > communities, to share the same IP router, also possibly other > services such > as the DHCP server. And we don't want the IP router > to have to know about the different communities. The IP router just > thinks the cloud is one big happy can't-we-all-just-get-along IP > subnet. > > But the bridges inside the L2 cloud have to somehow do two things: > a) enforce some sort of separation between the communities, and > b) allow them all to talk to the IP router. > > So this is how they are doing this. Assign each of the 4 communities a > VLAN ID, say > VLANs A, B, C, and D. Now what VLAN ID should the IP router belong to? > You want it > to be able to talk to nodes in any of the VLANs {A, B, C, or D}. > > The way this is done is to declare a VLAN group known as a FID > (filtering > ID for those that want to see an acronym expanded -- personally, the > expansion of that acronym didn't help me understand what a FID is). > So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one of the > IDs, > say Z, being the "primary". The IP router that serves all the > communities > (in this case, A, B, C, D) will be assigned to the "primary" VLAN, in > this case, Z. Endnodes > will be in one of {A, B, C, D}. IP routers serving these > communities will > be assigned VLAN Z. > > To clarify, if there are n communities, there will be n+1 VLANs, one > for each of the communities, and one for the IP router(s) serving > the communities in that IP subnet. > > Switches are configured to know that {Z, A, B, C, D} is a special > grouping of VLANs, such > that something transmitted from a VLAN Z port goes to all ports in the > group, i.e., all ports in > Z, A, B, C, and D. However, something transmitted from a VLAN A port > goes only to ports in > VLAN A and VLAN Z. Something from VLAN B goes to ports in VLAN B > and VLAN Z. > > ************* > Now a little quiz... > > For those of you that are following-- and in case I actually have > captured the concept, > let me ask a question. > > How do two endnodes in the IP subnet talk to each other? I think in the 802.1Q Shared Vlan Learning case, this is assumed not to occur, or at least not by using bridges. There are some other comments in 802.1Q-2005 Annex B about constraints for using SVL's that might apply. > The first case is two endnodes in VLAN A, say S and D. > S, observing that D is in the same subnet, will ARP. Since D is in the > same VLAN, it will receive > the ARP request, and respond. Everything works fine. > > But how do two endnodes in different VLANs, but in the same IP address > block communicate? S will > ARP, like before, because IP nodes are (blissfully) unaware of VLANs. > The answer people tell me > is "in that case communication between S and D has to go through > the IP > router". OK. So how would > that work? The > answer I get is "the switch does proxy ARP on behalf of the IP > router". > I don't understand that. Cisco calls this feature "local-proxy-arp". This feature makes the router respond to *all* ARP requests on a subnet, and forward traffic between all hosts on the subnet. > How does the > switch know *when* to proxy ARP? The switch doesn't necessarily know > which VLAN node D is in. This is the enhanced proxy-arp capable router's responsibility, not the switch. > ******************* > Well, bravely continuing on... > > > Endnode MAC address learning is done by VLAN as before. If a frame is > received by bridge b on > port p, with source S, from VLAN A, then bridge b remembers that {S, > VLAN A} is on port p. > > Furthermore, a Z-tagged unicast frame is checked against the learning > tables of Z, A, B, C, D, to determine where to forward it. So if > bridge > b receives > a frame with > destination=D, bridge b checks for D in any of the VLANs Z, A, B, > C, D, and > forwards accordingly. > > > > &&&&&&&&&&&&&&&&& > So, that's how bridges work (I hope). So how would we support this > functionality in > RBridges? > > As it turns out, despite the complexity of the concept, > it will not be that difficult to support this with RBridges, and > even in a somewhat more optimal way, since RBridges can do multicast > filtering within the core rather that just at the final port. > > RBridges, like bridges, would have to be configured with FIDs, i.e., > VLAN groupings as described above. > > Let's call a FID by the name of the "primary" VLAN; in our example, Z. > > RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, A, B, > C, D are > all 12-bit VLAN IDs. > > To avoid requiring configuration of all RBridges with these FIDs, > and > still allow multicast filtering, I propose we have RBridges advertise, > in their IS-IS core instance, FIDs that they are configured with. > So at > least one RBridge will say "Hey guys, > I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the > other > RBridges will, I guess > believe him. > > What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that > FID Z = {Z,A,D, F} is an interesting question, but at least there is > enough information to log an error. Lot of possibilities for > overlapping > FIDs, inconsistent FIDs, etc. > I assume all those will be errors. If there is a FID called "Z", then > everyone better agree about what the > VLAN membership of Z is, and none of the VLANs in Z better be in any > other FIDs. > > Once there is a FID of {Z, A, B, C, D}, there will no longer be > a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. > Instead > the Z-instance will announce VLANs A, B, C, and D membership as > well as > VLAN Z membership. > > The Z-instance of IS-IS will specify which MAC addresses are in > which VLAN. > So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f}, > {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case > letters are endnode MAC > addresses. The upper case letters are 12-bit VLAN IDs. > > Multicast packets marked as VLAN Z (inner VLAN) will be sent to > all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of > IS-IS will > be delivered to all RBridges in Z, A, B, C, and D. > > That way RBridges with ports in Z, A, B, C, and/or D will learn all > the > endnode addresses > in any of those VLANs (all the ports in FID Z). > > If ingress RB1 is attached to Z, and receives a packet with > destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z > 's endnode > membership. As soon as RB1 finds it, let's say, as reported by > RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2, > leaving the tag as Z. When RB2 decapsulates the packet, I assume it > will > rewrite the inner VLAN tag from "Z" to "D". > > > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > Conclusions: > > The changes to the spec: > > a) announce in the core instance, FIDs as a set of VLANs, the > first listed being the "primary". > > b) multicast forwarding: if the packet is (inner) tagged with > the VLAN ID of a primary VLAN in a FID, forward the packet on > all in the links in the selected tree that lead to any of the VLANs > in the FID. If the packet is tagged with the VLAN ID of a non-primary > VLAN in a FID, forward the packet on all the ports that reach > links in either that VLAN or in the primary VLAN for that FID. > > c) when ingressing a packet with destination D, tagged with a > VLAN tag of a primary VLAN in a FID, check the endnode information > for all the VLANs in the FID to determine the egress RBridge. > > d) when ingressing a packet with destination D, tagged with > a VLAN tag of a secondary VLAN in a FID, check the endnode > information for exactly two VLANs; the one the packet is > currently tagged with, and the primary VLAN for that FID, to > determine the egress RBridge. > > e) if two RBridges, in the core instance, report inconsistent FID > membership, what should we do? > > (Note: There was a fortune cookie program in Unix, one of the fortunes > being "Never check for an error > condition that you don't know how to handle". For the record--I think > that's a cute joke but really bad policy.). > > Radia Off-list, Radia asked me > a) why not just make them all one broadcast/multicast domain? What > exactly are people trying to > accomplish by making them separate but still all able to talk? Limit the size of the broadcast domain. An example would be for large-scale wireless networks, where irrelevant broadcasts eat up valuable airtime. Another example for large-scale switched networks would be to separate what would have been one gigantic spanning-tree domain into separate domains. Dale Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2TMw1OF026410 for <rbridge@postel.org>; Thu, 29 Mar 2007 15:58:02 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 29 Mar 2007 15:57:39 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5CD8C2AF; Thu, 29 Mar 2007 15:57:39 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 46B6F2AE; Thu, 29 Mar 2007 15:57:39 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCZ62008; Thu, 29 Mar 2007 15:57:38 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id A108A69CA4; Thu, 29 Mar 2007 15:57:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Mar 2007 15:57:37 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA09B@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201466EBA@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPAAAHGhTAABgZIoAAAMLaw From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Sanjay Sane (sanjays)" <sanjays@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A129BE937010263668-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2TMw1OF026410 Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 29 Mar 2007 22:58:33 -0000 Status: RO Content-Length: 2476 Silvano Gai wrote: > Caitlin, > > inline > >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >> On Behalf Of Caitlin Bestler Sent: Thursday, March 29, 2007 1:03 PM >> To: Sanjay Sane (sanjays); Radia Perlman; rbridge@postel.org >> Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should > we >> care? >> >> rbridge-bounces@postel.org wrote: >>> To answer your quiz: the "enhanced" proxy arp feature is to be >>> supported by the router, NOT by the switch. The enhancement is >>> essentially to be able to proxy arp for local hosts, i.e for those >>> hosts which are on the same subnet as the router interface. This is >>> the "ip local proxy arp" supported feature at least in Cisco >>> implementations. >>> >>> This way, the L3 communication between the hosts belonging to >>> different secondary vlans, is achieved *only* via the router. i.e. >>> if host ip-A (vlan-A) wants to talk to ip-D (vlan-D), it would take >>> 2 hops: mac-A --> mac-router mac-router --> mac-D >>> I think we should preserve this behavior with rbridges. >>> Changing the vlans of the packet should NOT be done by rbridges, >>> imo. >>> >>> -Sanjay >>> >>> >>> >> I would agree that 'routing' between VLAN-A and VLAN-D should only be >> done as a result of an explicitly created 'route', and that this is >> part of being a proxy ARP. >> >> I don't see any real problem with an RBridge doing so, as long as it >> only does so based on explicit instructions from the network >> administrators. It definitely must not just assume that it is ok to >> forward packets between two VLANs based upon their both using the >> same subnet. >> >> While this functionality is certainly more natural in a router, is >> there any reason to forbid explicitly delegating this task to >> RBridges? It could save a few hops on the end-to-end path. > > > Are we talking standards or products? Products can do > whatever they want, we don't care. IMHO the RBridge standard > MUST NOT specify IP routing functionality. IETF has already > tons of standards in the IP area. > It would probably be safe to mandate that the RBridge MUST NOT forward from VLAN to VLAN, as part of its RBridge functionality. If a *product* includes some additional non-RBRidge functionality that would be fine. But I would not want language that implied that because you called your box an RBridge that you MUST NOT include this feature in the same box. 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 l2TMs6FZ025264 for <rbridge@postel.org>; Thu, 29 Mar 2007 15:54:07 -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, 29 Mar 2007 15:54:00 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201466EBA@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? thread-index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPAAAHGhTAABgZIoA== References: <7178B7E237F45D45BE404AFF0AF58D87023280B0@xmb-sjc-213.amer.cisco.com> <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Sanjay Sane \(sanjays\)" <sanjays@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <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 l2TMs6FZ025264 Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 29 Mar 2007 22:54:36 -0000 Status: RO Content-Length: 2219 Caitlin, inline > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Caitlin Bestler > Sent: Thursday, March 29, 2007 1:03 PM > To: Sanjay Sane (sanjays); Radia Perlman; rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we > care? > > rbridge-bounces@postel.org wrote: > > To answer your quiz: the "enhanced" proxy arp feature is to > > be supported by the router, NOT by the switch. The > > enhancement is essentially to be able to proxy arp for local > > hosts, i.e for those hosts which are on the same subnet as > > the router interface. This is the "ip local proxy arp" > > supported feature at least in Cisco implementations. > > > > This way, the L3 communication between the hosts belonging to > > different secondary vlans, is achieved *only* via the router. > > i.e. if host ip-A > > (vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops: > > mac-A --> mac-router > > mac-router --> mac-D > > I think we should preserve this behavior with rbridges. > > Changing the vlans of the packet should NOT be done by rbridges, imo. > > > > -Sanjay > > > > > > > I would agree that 'routing' between VLAN-A and VLAN-D > should only be done as a result of an explicitly created > 'route', and that this is part of being a proxy ARP. > > I don't see any real problem with an RBridge doing so, > as long as it only does so based on explicit instructions > from the network administrators. It definitely must not > just assume that it is ok to forward packets between > two VLANs based upon their both using the same subnet. > > While this functionality is certainly more natural > in a router, is there any reason to forbid explicitly > delegating this task to RBridges? It could save a few > hops on the end-to-end path. Are we talking standards or products? Products can do whatever they want, we don't care. IMHO the RBridge standard MUST NOT specify IP routing functionality. IETF has already tons of standards in the IP area. -- Silvano > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2TK35f2006415 for <rbridge@postel.org>; Thu, 29 Mar 2007 13:03:05 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 29 Mar 2007 13:02:57 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 378842AF; Thu, 29 Mar 2007 13:02:57 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 234282AE; Thu, 29 Mar 2007 13:02:57 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCZ26330; Thu, 29 Mar 2007 13:02:52 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id D6E7369CA3; Thu, 29 Mar 2007 13:02:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Mar 2007 13:02:51 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <7178B7E237F45D45BE404AFF0AF58D87023280B0@xmb-sjc-213.amer.cisco.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPAAAHGhTA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Sanjay Sane (sanjays)" <sanjays@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A12C4FB38G10239458-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2TK35f2006415 Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 29 Mar 2007 20:03:32 -0000 Status: RO Content-Length: 1435 rbridge-bounces@postel.org wrote: > To answer your quiz: the "enhanced" proxy arp feature is to > be supported by the router, NOT by the switch. The > enhancement is essentially to be able to proxy arp for local > hosts, i.e for those hosts which are on the same subnet as > the router interface. This is the "ip local proxy arp" > supported feature at least in Cisco implementations. > > This way, the L3 communication between the hosts belonging to > different secondary vlans, is achieved *only* via the router. > i.e. if host ip-A > (vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops: > mac-A --> mac-router > mac-router --> mac-D > I think we should preserve this behavior with rbridges. > Changing the vlans of the packet should NOT be done by rbridges, imo. > > -Sanjay > > > I would agree that 'routing' between VLAN-A and VLAN-D should only be done as a result of an explicitly created 'route', and that this is part of being a proxy ARP. I don't see any real problem with an RBridge doing so, as long as it only does so based on explicit instructions from the network administrators. It definitely must not just assume that it is ok to forward packets between two VLANs based upon their both using the same subnet. While this functionality is certainly more natural in a router, is there any reason to forbid explicitly delegating this task to RBridges? It could save a few hops on the end-to-end path. 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 l2TJa9rG026569 for <rbridge@postel.org>; Thu, 29 Mar 2007 12:36:09 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2007 12:36:10 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2TJa8vJ028756; Thu, 29 Mar 2007 12:36:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2TJa8ZT002865; Thu, 29 Mar 2007 19:36:08 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 12:36:03 -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, 29 Mar 2007 12:36:03 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D87023280B0@xmb-sjc-213.amer.cisco.com> In-Reply-To: <460B6304.3020507@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPA References: <460B6304.3020507@sun.com> From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 29 Mar 2007 19:36:03.0663 (UTC) FILETIME=[7CD8BDF0:01C77239] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10349; t=1175196968; x=1176060968; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=20=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:=20RE=3A=20[rbridge]=20Shared=20VLAN=20learning=3A=20What=20is=2 0it=20and=20why=20should=20we=20care? |Sender:=20; bh=HjTQS0FKB0OBD8niMorXq16o9iVx8kfo8LbW/HpkOxk=; b=FznEt6+nHXG2hnYCrRSL0r1rC5plQGPZpfszUrZYxOfskvY8TwsJaUyeckcAFYRFUfMKaR/M jGJF2awMJumn0GVFNwcHdQ3Ml82FXGpzeNPMB3PcWUVJWR1teSAEBgo2; Authentication-Results: sj-dkim-4; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2TJa9rG026569 Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 29 Mar 2007 19:37:20 -0000 Status: RO Content-Length: 10044 To answer your quiz: the "enhanced" proxy arp feature is to be supported by the router, NOT by the switch. The enhancement is essentially to be able to proxy arp for local hosts, i.e for those hosts which are on the same subnet as the router interface. This is the "ip local proxy arp" supported feature at least in Cisco implementations. This way, the L3 communication between the hosts belonging to different secondary vlans, is achieved *only* via the router. i.e. if host ip-A (vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops: mac-A --> mac-router mac-router --> mac-D I think we should preserve this behavior with rbridges. Changing the vlans of the packet should NOT be done by rbridges, imo. -Sanjay -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Wednesday, March 28, 2007 11:56 PM To: rbridge@postel.org Subject: [rbridge] Shared VLAN learning: What is it and why should we care? Hopefully this explanation will be clear enough for people to at least figure out whether we are all talking about the same thing. Of course, feel free to correct me if my understanding is wrong. First we need to understand what problem it is trying to solve. This is my understanding of that: THE PROBLEM ------------------ Someone has a block of IP addresses to divvy up among a set of different organizations. Let's say the address block has 100 addresses, and there are 4 organizations. One strategy might be to give each organization 1/4 of the IP addresses each, and then possibly even wind up having separate IP subnets (if the addresses can be assigned to be in different prefixes). The problem, though, is that you don't know in advance how many addresses each organization will need. Perhaps even the IP address block is oversubscribed, so that there are more potential switch ports than IP addresses, and you just hope that not everyone connects at once (or if they do, they don't get an IP address). So we're going to allow basically random assignment of IP addresses within the IP address block to each of the four organizations. But you still want to keep the organizations separate, as in, they don't see each other's traffic. They don't get bothered with each other's ARPs and so forth. And you don't want to change the IP nodes (endnodes or routers) to know anything funny is going on. So you use VLANs to separate the communities. A particular port on a switch/bridge in a L2 cloud is configured as to what community the attached endnode belongs to, by having it configured with a VLAN ID. But you'd like all the IP nodes in the cloud, even though in different communities, to share the same IP router, also possibly other services such as the DHCP server. And we don't want the IP router to have to know about the different communities. The IP router just thinks the cloud is one big happy can't-we-all-just-get-along IP subnet. But the bridges inside the L2 cloud have to somehow do two things: a) enforce some sort of separation between the communities, and b) allow them all to talk to the IP router. So this is how they are doing this. Assign each of the 4 communities a VLAN ID, say VLANs A, B, C, and D. Now what VLAN ID should the IP router belong to? You want it to be able to talk to nodes in any of the VLANs {A, B, C, or D}. The way this is done is to declare a VLAN group known as a FID (filtering ID for those that want to see an acronym expanded -- personally, the expansion of that acronym didn't help me understand what a FID is). So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one of the IDs, say Z, being the "primary". The IP router that serves all the communities (in this case, A, B, C, D) will be assigned to the "primary" VLAN, in this case, Z. Endnodes will be in one of {A, B, C, D}. IP routers serving these communities will be assigned VLAN Z. To clarify, if there are n communities, there will be n+1 VLANs, one for each of the communities, and one for the IP router(s) serving the communities in that IP subnet. Switches are configured to know that {Z, A, B, C, D} is a special grouping of VLANs, such that something transmitted from a VLAN Z port goes to all ports in the group, i.e., all ports in Z, A, B, C, and D. However, something transmitted from a VLAN A port goes only to ports in VLAN A and VLAN Z. Something from VLAN B goes to ports in VLAN B and VLAN Z. ************* Now a little quiz... For those of you that are following-- and in case I actually have captured the concept, let me ask a question. How do two endnodes in the IP subnet talk to each other? The first case is two endnodes in VLAN A, say S and D. S, observing that D is in the same subnet, will ARP. Since D is in the same VLAN, it will receive the ARP request, and respond. Everything works fine. But how do two endnodes in different VLANs, but in the same IP address block communicate? S will ARP, like before, because IP nodes are (blissfully) unaware of VLANs. The answer people tell me is "in that case communication between S and D has to go through the IP router". OK. So how would that work? The answer I get is "the switch does proxy ARP on behalf of the IP router". I don't understand that. How does the switch know *when* to proxy ARP? The switch doesn't necessarily know which VLAN node D is in. ******************* Well, bravely continuing on... Endnode MAC address learning is done by VLAN as before. If a frame is received by bridge b on port p, with source S, from VLAN A, then bridge b remembers that {S, VLAN A} is on port p. Furthermore, a Z-tagged unicast frame is checked against the learning tables of Z, A, B, C, D, to determine where to forward it. So if bridge b receives a frame with destination=D, bridge b checks for D in any of the VLANs Z, A, B, C, D, and forwards accordingly. &&&&&&&&&&&&&&&&& So, that's how bridges work (I hope). So how would we support this functionality in RBridges? As it turns out, despite the complexity of the concept, it will not be that difficult to support this with RBridges, and even in a somewhat more optimal way, since RBridges can do multicast filtering within the core rather that just at the final port. RBridges, like bridges, would have to be configured with FIDs, i.e., VLAN groupings as described above. Let's call a FID by the name of the "primary" VLAN; in our example, Z. RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, A, B, C, D are all 12-bit VLAN IDs. To avoid requiring configuration of all RBridges with these FIDs, and still allow multicast filtering, I propose we have RBridges advertise, in their IS-IS core instance, FIDs that they are configured with. So at least one RBridge will say "Hey guys, I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other RBridges will, I guess believe him. What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that FID Z = {Z,A,D, F} is an interesting question, but at least there is enough information to log an error. Lot of possibilities for overlapping FIDs, inconsistent FIDs, etc. I assume all those will be errors. If there is a FID called "Z", then everyone better agree about what the VLAN membership of Z is, and none of the VLANs in Z better be in any other FIDs. Once there is a FID of {Z, A, B, C, D}, there will no longer be a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. Instead the Z-instance will announce VLANs A, B, C, and D membership as well as VLAN Z membership. The Z-instance of IS-IS will specify which MAC addresses are in which VLAN. So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f}, {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case letters are endnode MAC addresses. The upper case letters are 12-bit VLAN IDs. Multicast packets marked as VLAN Z (inner VLAN) will be sent to all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of IS-IS will be delivered to all RBridges in Z, A, B, C, and D. That way RBridges with ports in Z, A, B, C, and/or D will learn all the endnode addresses in any of those VLANs (all the ports in FID Z). If ingress RB1 is attached to Z, and receives a packet with destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z 's endnode membership. As soon as RB1 finds it, let's say, as reported by RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2, leaving the tag as Z. When RB2 decapsulates the packet, I assume it will rewrite the inner VLAN tag from "Z" to "D". &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Conclusions: The changes to the spec: a) announce in the core instance, FIDs as a set of VLANs, the first listed being the "primary". b) multicast forwarding: if the packet is (inner) tagged with the VLAN ID of a primary VLAN in a FID, forward the packet on all in the links in the selected tree that lead to any of the VLANs in the FID. If the packet is tagged with the VLAN ID of a non-primary VLAN in a FID, forward the packet on all the ports that reach links in either that VLAN or in the primary VLAN for that FID. c) when ingressing a packet with destination D, tagged with a VLAN tag of a primary VLAN in a FID, check the endnode information for all the VLANs in the FID to determine the egress RBridge. d) when ingressing a packet with destination D, tagged with a VLAN tag of a secondary VLAN in a FID, check the endnode information for exactly two VLANs; the one the packet is currently tagged with, and the primary VLAN for that FID, to determine the egress RBridge. e) if two RBridges, in the core instance, report inconsistent FID membership, what should we do? (Note: There was a fortune cookie program in Unix, one of the fortunes being "Never check for an error condition that you don't know how to handle". For the record--I think that's a cute joke but really bad policy.). 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 l2T6towL006168 for <rbridge@postel.org>; Wed, 28 Mar 2007 23:55:50 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JFN00CH2KL2UV00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 28 Mar 2007 23:55:50 -0700 (PDT) Received: from sun.com ([129.150.16.120]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFN0017KKL0EC10@mail.sunlabs.com> for rbridge@postel.org; Wed, 28 Mar 2007 23:55:48 -0700 (PDT) Date: Wed, 28 Mar 2007 23:56:04 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <460B6304.3020507@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Shared VLAN learning: What is it and why should we care? 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, 29 Mar 2007 06:56:55 -0000 Status: RO Content-Length: 8929 Hopefully this explanation will be clear enough for people to at least figure out whether we are all talking about the same thing. Of course, feel free to correct me if my understanding is wrong. First we need to understand what problem it is trying to solve. This is my understanding of that: THE PROBLEM ------------------ Someone has a block of IP addresses to divvy up among a set of different organizations. Let's say the address block has 100 addresses, and there are 4 organizations. One strategy might be to give each organization 1/4 of the IP addresses each, and then possibly even wind up having separate IP subnets (if the addresses can be assigned to be in different prefixes). The problem, though, is that you don't know in advance how many addresses each organization will need. Perhaps even the IP address block is oversubscribed, so that there are more potential switch ports than IP addresses, and you just hope that not everyone connects at once (or if they do, they don't get an IP address). So we're going to allow basically random assignment of IP addresses within the IP address block to each of the four organizations. But you still want to keep the organizations separate, as in, they don't see each other's traffic. They don't get bothered with each other's ARPs and so forth. And you don't want to change the IP nodes (endnodes or routers) to know anything funny is going on. So you use VLANs to separate the communities. A particular port on a switch/bridge in a L2 cloud is configured as to what community the attached endnode belongs to, by having it configured with a VLAN ID. But you'd like all the IP nodes in the cloud, even though in different communities, to share the same IP router, also possibly other services such as the DHCP server. And we don't want the IP router to have to know about the different communities. The IP router just thinks the cloud is one big happy can't-we-all-just-get-along IP subnet. But the bridges inside the L2 cloud have to somehow do two things: a) enforce some sort of separation between the communities, and b) allow them all to talk to the IP router. So this is how they are doing this. Assign each of the 4 communities a VLAN ID, say VLANs A, B, C, and D. Now what VLAN ID should the IP router belong to? You want it to be able to talk to nodes in any of the VLANs {A, B, C, or D}. The way this is done is to declare a VLAN group known as a FID (filtering ID for those that want to see an acronym expanded -- personally, the expansion of that acronym didn't help me understand what a FID is). So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one of the IDs, say Z, being the "primary". The IP router that serves all the communities (in this case, A, B, C, D) will be assigned to the "primary" VLAN, in this case, Z. Endnodes will be in one of {A, B, C, D}. IP routers serving these communities will be assigned VLAN Z. To clarify, if there are n communities, there will be n+1 VLANs, one for each of the communities, and one for the IP router(s) serving the communities in that IP subnet. Switches are configured to know that {Z, A, B, C, D} is a special grouping of VLANs, such that something transmitted from a VLAN Z port goes to all ports in the group, i.e., all ports in Z, A, B, C, and D. However, something transmitted from a VLAN A port goes only to ports in VLAN A and VLAN Z. Something from VLAN B goes to ports in VLAN B and VLAN Z. ************* Now a little quiz... For those of you that are following-- and in case I actually have captured the concept, let me ask a question. How do two endnodes in the IP subnet talk to each other? The first case is two endnodes in VLAN A, say S and D. S, observing that D is in the same subnet, will ARP. Since D is in the same VLAN, it will receive the ARP request, and respond. Everything works fine. But how do two endnodes in different VLANs, but in the same IP address block communicate? S will ARP, like before, because IP nodes are (blissfully) unaware of VLANs. The answer people tell me is "in that case communication between S and D has to go through the IP router". OK. So how would that work? The answer I get is "the switch does proxy ARP on behalf of the IP router". I don't understand that. How does the switch know *when* to proxy ARP? The switch doesn't necessarily know which VLAN node D is in. ******************* Well, bravely continuing on... Endnode MAC address learning is done by VLAN as before. If a frame is received by bridge b on port p, with source S, from VLAN A, then bridge b remembers that {S, VLAN A} is on port p. Furthermore, a Z-tagged unicast frame is checked against the learning tables of Z, A, B, C, D, to determine where to forward it. So if bridge b receives a frame with destination=D, bridge b checks for D in any of the VLANs Z, A, B, C, D, and forwards accordingly. &&&&&&&&&&&&&&&&& So, that's how bridges work (I hope). So how would we support this functionality in RBridges? As it turns out, despite the complexity of the concept, it will not be that difficult to support this with RBridges, and even in a somewhat more optimal way, since RBridges can do multicast filtering within the core rather that just at the final port. RBridges, like bridges, would have to be configured with FIDs, i.e., VLAN groupings as described above. Let's call a FID by the name of the "primary" VLAN; in our example, Z. RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, A, B, C, D are all 12-bit VLAN IDs. To avoid requiring configuration of all RBridges with these FIDs, and still allow multicast filtering, I propose we have RBridges advertise, in their IS-IS core instance, FIDs that they are configured with. So at least one RBridge will say "Hey guys, I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other RBridges will, I guess believe him. What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that FID Z = {Z,A,D, F} is an interesting question, but at least there is enough information to log an error. Lot of possibilities for overlapping FIDs, inconsistent FIDs, etc. I assume all those will be errors. If there is a FID called "Z", then everyone better agree about what the VLAN membership of Z is, and none of the VLANs in Z better be in any other FIDs. Once there is a FID of {Z, A, B, C, D}, there will no longer be a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. Instead the Z-instance will announce VLANs A, B, C, and D membership as well as VLAN Z membership. The Z-instance of IS-IS will specify which MAC addresses are in which VLAN. So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f}, {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case letters are endnode MAC addresses. The upper case letters are 12-bit VLAN IDs. Multicast packets marked as VLAN Z (inner VLAN) will be sent to all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of IS-IS will be delivered to all RBridges in Z, A, B, C, and D. That way RBridges with ports in Z, A, B, C, and/or D will learn all the endnode addresses in any of those VLANs (all the ports in FID Z). If ingress RB1 is attached to Z, and receives a packet with destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z 's endnode membership. As soon as RB1 finds it, let's say, as reported by RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2, leaving the tag as Z. When RB2 decapsulates the packet, I assume it will rewrite the inner VLAN tag from "Z" to "D". &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Conclusions: The changes to the spec: a) announce in the core instance, FIDs as a set of VLANs, the first listed being the "primary". b) multicast forwarding: if the packet is (inner) tagged with the VLAN ID of a primary VLAN in a FID, forward the packet on all in the links in the selected tree that lead to any of the VLANs in the FID. If the packet is tagged with the VLAN ID of a non-primary VLAN in a FID, forward the packet on all the ports that reach links in either that VLAN or in the primary VLAN for that FID. c) when ingressing a packet with destination D, tagged with a VLAN tag of a primary VLAN in a FID, check the endnode information for all the VLANs in the FID to determine the egress RBridge. d) when ingressing a packet with destination D, tagged with a VLAN tag of a secondary VLAN in a FID, check the endnode information for exactly two VLANs; the one the packet is currently tagged with, and the primary VLAN for that FID, to determine the egress RBridge. e) if two RBridges, in the core instance, report inconsistent FID membership, what should we do? (Note: There was a fortune cookie program in Unix, one of the fortunes being "Never check for an error condition that you don't know how to handle". For the record--I think that's a cute joke but really bad policy.). 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 l2T62SYm021618 for <rbridge@postel.org>; Wed, 28 Mar 2007 23:02:28 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JFN00CGMI3TUV00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 28 Mar 2007 23:02:18 -0700 (PDT) Received: from sun.com ([129.150.16.120]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFN00174I3SEC10@mail.sunlabs.com> for rbridge@postel.org; Wed, 28 Mar 2007 23:02:16 -0700 (PDT) Date: Wed, 28 Mar 2007 23:02:33 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <460B5679.4010209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] I completely misunderstood what "shared VLAN learning" was 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, 29 Mar 2007 06:03:04 -0000 Status: RO Content-Length: 1715 I took the words "shared VLAN learning" and came up with a concept that could be described by those words. But that's not what IEEE 802 means by those words. Anyway, in my next email to the list, I will describe my current understanding of what it is, and how we can support it with TRILL. If indeed people are deploying this feature in layer 2, I think TRILL should support it. Anyway, it took a really long time for Dinesh to explain to me what shared 802-style VLAN learning actually is, and I'm still not totally sure I understand it. Especially since when I found other 802 types in the hallways during IETF to ask detailed questions, I got inconsistent answers. And especially because I still don't understand how a few things actually would work. And now a plea -- I'm not the only one that has been confused. I suspect a lot of people just gave up on trying to understand the issue. If you don't understand an issue, it's OK to ask someone to explain it. And please -- the more IEEE 802 literate people on the mailing list should try to make fewer assumptions about what people on this mailing understand about 802 arcana. So for instance, most people (including me) didn't know what a "FID" was. It's common for email threads to be incomprehensible because people really are making different assumptions, and not understanding each other. It's always a good idea to explain everything carefully, with limited jargon, to ensure that everyone is talking about the same thing. Which we weren't, in the case of the "shared VLAN learning" thread. Anyway, I'm sure you're all looking forward to my next message where the exciting concept of "shared VLAN learning" will be revealed. Radia 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 l2MG8dsF001285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 22 Mar 2007 09:08:39 -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 l2MG8UMh015120; Thu, 22 Mar 2007 10:08:30 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 11:08:30 -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, 22 Mar 2007 11:08:21 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFA24A06@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4601843B.7020407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC Thread-Index: Acdr7SvIBqQIIId6QPKNd2lipnaOwwArmFXQ References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <46009976.5030007@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF9EAE91@eusrcmw721.eamcs.ericsson.se> <4601843B.7020407@cisco.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Dinesh G Dutt" <ddutt@cisco.com> X-OriginalArrivalTime: 22 Mar 2007 16:08:30.0737 (UTC) FILETIME=[556EC810:01C76C9C] 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 l2MG8dsF001285 Cc: rbridge@postel.org, ietf@ietf.org, IETF-Announce <ietf-announce@ietf.org> Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC 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, 22 Mar 2007 16:08:47 -0000 Status: RO Content-Length: 2384 Dinesh, Please see one more question below... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > Sent: Wednesday, March 21, 2007 3:15 PM > To: Eric Gray (LO/EUS) > Cc: ietf@ietf.org; rbridge@postel.org; IETF-Announce > Subject: Re: [rbridge] Last Call: > draft-ietf-trill-routing-reqs (TRILL Routing Requirements in > Support of RBridges) to Informational RFC > > Hi Eric, > > Eric Gray (LO/EUS) wrote: > >> - "Inefficient inter-bridge connection usage". What do you > >> mean by this phrase? > >> > > > > > I guess my issue is the choice of words "inter-bridge > connection usage". > "connection" is undefined and not sure if it is the right word. > > If traffic is demonstrably required to traverse more links > > than some theoretical minimum, than link utilization is - > > by definition - less efficient than it theoretically can > > be. > > > If this what you want to say, something along the lines of "Non-optimal > pair-wise forwarding of unicast frames using spanning tree also results > in inefficient usage of links" will be sufficient. However, I think that > merely stating the lack of non-optimal pair-wise forwarding is sufficient > to imply this and many other issues around this style. I'm not sure how much clearer it is to say what you're suggesting than what it already says. However this is not critical text, so what would you like it to say and where would you like it to go? What I'm asking for is "replace text saying <$*%&(%)> with new text saying <*$&*@(_&$&>"... > >> What is proposed in the current solution is to run a spanning tree > >> protocol instance per port which maybe not scalable. > >> > >> I think something like "It's strongly desirable to minimize the > >> interaction between the bridges and Rbridges and constrain a > >> spanning tree" is more appropriate. > >> > > > > Yet it is difficult to imagine how this would translate to a > > requirement that would make sense to someone evaluating the > > acceptability of a routing protocol for the TRILL problem-space. > > Perhaps it would be simpler to omit the offending text? > > > OK with me. > > Dinesh > > -- > We make our world significant by the courage of our questions and by > the depth of our answers. - Carl Sagan > 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 l2MD2QwM004569 for <Rbridge@postel.org>; Thu, 22 Mar 2007 06:02:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1174568545!10969164!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 32712 invoked from network); 22 Mar 2007 13:02:25 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 22 Mar 2007 13:02:25 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l2MD2PXO021980 for <Rbridge@postel.org>; Thu, 22 Mar 2007 06:02:25 -0700 (MST) 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 l2MD2Ol9028854 for <Rbridge@postel.org>; Thu, 22 Mar 2007 08:02:24 -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, 22 Mar 2007 09:02:23 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979002469BAB@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Meeting Presentations Updated thread-index: AcdsfrCTtHr45zLVQyCHOkQxQ3R7Cg== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> 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 l2MD2QwM004569 Subject: [rbridge] WG Meeting Presentations Updated 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, 22 Mar 2007 13:02:37 -0000 Status: RO Content-Length: 412 Several of the presentations given at the TRILL WG meeting yesterday were updated in minor ways during the meeting while they were being shown. These tweaked presentations have now been uploaded to the meeting materials page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 (In particular, the Agenda, -02 to -03, Multicast Input Link Filtering, and Extensions presentations.) Donald 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 l2M5Q8Ki012122 for <rbridge@postel.org>; Wed, 21 Mar 2007 22:26:08 -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 <0JFA00KVAHRGTA00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 21 Mar 2007 22:26:04 -0700 (PDT) Received: from sun.com ([129.150.20.59]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFA0091WHRD5R10@mail.sunlabs.com> for rbridge@postel.org; Wed, 21 Mar 2007 22:26:04 -0700 (PDT) Date: Wed, 21 Mar 2007 22:26:16 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org, riw@cisco.com, dward@cisco.com Message-id: <46021378.8080400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Making fields in TRILL's IS-IS bigger? 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, 22 Mar 2007 05:26:23 -0000 Status: RO Content-Length: 822 There were some fields in IS-IS that, 40 years ago or whatever, we made too small. We actually can change the size of fields for TRILL, right? How badly would that make it to adapt an implementation of IS-IS to TRILL if we changed the size of: a) fragment number (to 2 bytes presumable) b) pseudonode extra byte (to 2 bytes?) Actually, I don't think b) needs to be done, because all that matters is that the pseudonode have a unique ID, not that the first 6 bytes have to be the same as the system ID of the DR. So the DR could assign the pseudonode address to be its MAC address *on that link*, with a final byte of 1. And so a single byte, as it is currently, shouldn't be a problem. So the only example I can think of in this (insomniacal) moment is the fragment number. Are there any other examples? Radia Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LJE68q009562 for <rbridge@postel.org>; Wed, 21 Mar 2007 12:14:07 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 20:14:07 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LJE6xn032347; Wed, 21 Mar 2007 20:14:06 +0100 Received: from [10.61.80.189] (ams3-vpn-dhcp4286.cisco.com [10.61.80.189]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LJE5lZ012507; Wed, 21 Mar 2007 19:14:05 GMT Message-ID: <4601843B.7020407@cisco.com> Date: Wed, 21 Mar 2007 12:15:07 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0pre (X11/20070224) MIME-Version: 1.0 To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com> References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <46009976.5030007@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF9EAE91@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF9EAE91@eusrcmw721.eamcs.ericsson.se> 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=1596; t=1174504446; x=1175368446; c=relaxed/simple; s=amsdkim1002; 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]=20Last=20Call=3A=20draft-ietf-trill-routing -reqs=20(TRILL=20Routing=0A=20Requirements=20in=20Support=20of=20RBridges) =20to=20Informational=20RFC |Sender:=20; bh=3B892n672ZPtgICZLegK45yWqBEOZzKHzokyAYiHNX0=; b=k9+nA2eDrBpnIbt+aK1znmS0X8fSd13HWbMuw7iiSniYtSbVcj9V+k2NhoH71mAjLcztsqQ4 wG0wUiBViQK5lwqiRle8qyIdPNDzNgEm33oyroqwtHPFbgrnXyuX6VJq; Authentication-Results: ams-dkim-1; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org, ietf@ietf.org, IETF-Announce <ietf-announce@ietf.org> Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC 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, 21 Mar 2007 19:14:42 -0000 Status: RO Content-Length: 1556 Hi Eric, Eric Gray (LO/EUS) wrote: >> - "Inefficient inter-bridge connection usage". What do you >> mean by this phrase? >> > > I guess my issue is the choice of words "inter-bridge connection usage". "connection" is undefined and not sure if it is the right word. > If traffic is demonstrably required to traverse more links > than some theoretical minimum, than link utilization is - > by definition - less efficient than it theoretically can > be. > If this what you want to say, something along the lines of "Non-optimal pair-wise forwarding of unicast frames using spanning tree also results in inefficient usage of links" will be sufficient. However, I think that merely stating the lack of non-optimal pair-wise forwarding is sufficient to imply this and many other issues around this style. >> What is proposed in the current solution is to run a spanning tree >> protocol instance per port which maybe not scalable. >> >> I think something like "It's strongly desirable to minimize the >> interaction between the bridges and Rbridges and constrain a >> spanning tree" is more appropriate. >> > > Yet it is difficult to imagine how this would translate to a > requirement that would make sense to someone evaluating the > acceptability of a routing protocol for the TRILL problem-space. > Perhaps it would be simpler to omit the offending text? > OK with me. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LBVj2Q008337 for <rbridge@postel.org>; Wed, 21 Mar 2007 04:31:46 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JF900C7L3OCG1@szxga03-in.huawei.com> for rbridge@postel.org; Wed, 21 Mar 2007 19:24:12 +0800 (CST) Received: from jys6053946 (dhcp-4009.ietf68.org [130.129.64.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JF900L4H3NHBG@szxga03-in.huawei.com> for rbridge@postel.org; Wed, 21 Mar 2007 19:24:12 +0800 (CST) Date: Wed, 21 Mar 2007 19:23:31 +0800 From: caowayne <caowayne@huawei.com> To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, Dinesh G Dutt <ddutt@cisco.com>, ietf@ietf.org Message-id: <009101c76bab$63717cb0$fa01000a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <46009976.5030007@cisco.com> <941D5DCD8C42014FAF70FB7424686DCF9EAE91@eusrcmw721.eamcs.ericsson.se> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caowayne@huawei.com Cc: rbridge@postel.org, IETF-Announce <ietf-announce@ietf.org> Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC 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, 21 Mar 2007 11:32:16 -0000 Status: RO Content-Length: 7447 ----- Original Message ----- From: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com> To: "Dinesh G Dutt" <ddutt@cisco.com>; <ietf@ietf.org> Cc: <rbridge@postel.org>; "IETF-Announce" <ietf-announce@ietf.org> Sent: Wednesday, March 21, 2007 6:48 PM Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC > Dinesh, > > Thank you for your comments. Please see below... > > Thanks! > > -- > Eric Gray > Principal Engineer > Ericsson > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Dinesh G Dutt >> Sent: Tuesday, March 20, 2007 10:33 PM >> To: ietf@ietf.org >> Cc: rbridge@postel.org; IETF-Announce >> Subject: Re: [rbridge] Last Call: >> draft-ietf-trill-routing-reqs (TRILL Routing Requirements in >> Support of RBridges) to Informational RFC >> >> I have a few comments on the document. >> >> - Section 1, Bridging Limitations: The first two paragraphs are >> structured around the logic: because ethernet header doesn't have >> a TTL or a hop count, the only choice was to use spanning tree. >> IEEE 802.1 has defined several headers such as 802.1Q header that >> carries the VLAN. If they wanted to add a TTL, they could have. >> They picked spanning tree and said that therefore they didn't need >> a TTL. To the extent this represents history, I think it is >> inaccurate. To the extent it attempts to explain the rationale for >> RBridges, it seems unnecessary. A sufficient replacement maybe >> along the lines of: >> >> "Spanning Tree Protocol and its variants are the control protocol >> deployed in current 802.1D Ethernet bridges. This protocol >> constructs a single tree out of a mesh of network connections. >> This tree eliminates usage of equal cost multipaths and results in >> non-optimal pair-wise forwarding." >> > > This is a reasonable proposal for replacement text. If there > are no objections from the working group, or the IESG, I would > be happy to make this change. > > Thanks! > >> - Section 1, Bridging Limitations: More specific comments: >> - "Because of the potential for severe impact from looping traffic, >> many (if not most) current bridge implementations stop forwarding >> of traffic frames following a topology change event and restart >> only after STP/RSTP is complete" is incorrect. All 802.1D bridges >> allow (R/M)STP to complete before moving a port to forwarding >> state. I'd remove the phrase in parentheses. > > Good suggestion. Assuming the same acceptance, I can make this > change as well. > >> - "Inefficient inter-bridge connection usage". What do you >> mean by this phrase? > > I assume this is a reasonably well understood aspect of using > a spanning tree as opposed to using shortest path routing. > > It is not difficult to come up with a reasonable scenario in > which shortest path forwarding results in 80% of the total > link-by-link forwarding load that is generated by the same > amount of traffic in a corresponding spanning tree scenario. > > The reason why this happens is that a spanning tree may be > constructed in which the path for some destinations will > traverse at least one additional link, when arriving from > some sources. Practically speaking, unless a spanning tree > is constructed per-source bridge, it's easy to show that > this will be true for at least some source and destination > pairs. > > Assuming the simplistic (VLAN-free) scenario that is basic > to the "configuration-free" capability that is part of the > chartered goals of TRILL, there would only be one spanning > tree in a bridged network. Hence, in this scenario, there > would be many cases in which traffic traverses at least one > additional link. > > If traffic is demonstrably required to traverse more links > than some theoretical minimum, than link utilization is - > by definition - less efficient than it theoretically can > be. > >> >> - Section 1.2, Backward Compatibility and section 4.1: "...they >> terminate a bridged spanning tree, (i.e. - they do not forward >> BPDUs)". >> >> I thought that we have not concluded the discussion on preventing >> loops for interconnected Bridges and RBridges based on the email >> thread that started a while back. Putting a decision in this >> section on the solution seems a little unnecessary. > > I am not sure that this text - or something like it - is unnecessary > from a compatibility perspective, and it may be the case that this > change would require a new working group last call. However, if it > is acceptable to the IESG either that the change does not require a > new last call, or a second working group last call is needed, then I > would be happy to make this change as well. > >> What is proposed in the current solution is to run a spanning tree >> protocol instance per port which maybe not scalable. >> >> I think something like "It's strongly desirable to minimize the >> interaction between the bridges and Rbridges and constrain a >> spanning tree" is more appropriate. > > Yet it is difficult to imagine how this would translate to a > requirement that would make sense to someone evaluating the > acceptability of a routing protocol for the TRILL problem-space. > Perhaps it would be simpler to omit the offending text? > >> >> - Ethernet and 802 is used interchangeably. Isn't Ethernet >> 802.3 only ? >> Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or >> http://www.ieee802.org/3/. >> >> I don't see anything on what I consider to be another >> important goal: to >> have a single protocol to compute unicast, multicast and broadcast >> routes. This reduces operational overhead by having to understand and >> debug a single protocol. >> >> The IESG wrote: >> > The IESG has received a request from the Transparent >> Interconnection of >> > Lots of Links WG (trill) to consider the following document: >> > >> > - 'TRILL Routing Requirements in Support of RBridges ' >> > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC >> > >> > The IESG plans to make a decision in the next few weeks, >> and solicits >> > final comments on this action. Please send substantive >> comments to the >> > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, >> > comments may be sent to iesg@ietf.org instead. In either >> case, please >> > retain the beginning of the Subject line to allow automated sorting. >> > >> > The file can be obtained via >> > >> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r >> eqs-02.txt >> > >> > >> > IESG discussion can be tracked via >> > >> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie >> w_id&dTag=15187&rfc_flag=0 >> > >> > _______________________________________________ >> > 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 imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LAmXeP026550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 21 Mar 2007 03:48:33 -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 l2LAmKCd025070; Wed, 21 Mar 2007 04:48:20 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 05:48:19 -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, 21 Mar 2007 05:48:15 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF9EAE91@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <46009976.5030007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC Thread-Index: AcdrY1j8UPGPT/e8Tq+2mKPLSfHtQQAOLN3A References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <46009976.5030007@cisco.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Dinesh G Dutt" <ddutt@cisco.com>, <ietf@ietf.org> X-OriginalArrivalTime: 21 Mar 2007 10:48:19.0954 (UTC) FILETIME=[70802D20:01C76BA6] 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 l2LAmXeP026550 Cc: rbridge@postel.org, IETF-Announce <ietf-announce@ietf.org> Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC 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, 21 Mar 2007 10:49:18 -0000 Status: RO Content-Length: 6675 Dinesh, Thank you for your comments. Please see below... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Dinesh G Dutt > Sent: Tuesday, March 20, 2007 10:33 PM > To: ietf@ietf.org > Cc: rbridge@postel.org; IETF-Announce > Subject: Re: [rbridge] Last Call: > draft-ietf-trill-routing-reqs (TRILL Routing Requirements in > Support of RBridges) to Informational RFC > > I have a few comments on the document. > > - Section 1, Bridging Limitations: The first two paragraphs are > structured around the logic: because ethernet header doesn't have > a TTL or a hop count, the only choice was to use spanning tree. > IEEE 802.1 has defined several headers such as 802.1Q header that > carries the VLAN. If they wanted to add a TTL, they could have. > They picked spanning tree and said that therefore they didn't need > a TTL. To the extent this represents history, I think it is > inaccurate. To the extent it attempts to explain the rationale for > RBridges, it seems unnecessary. A sufficient replacement maybe > along the lines of: > > "Spanning Tree Protocol and its variants are the control protocol > deployed in current 802.1D Ethernet bridges. This protocol > constructs a single tree out of a mesh of network connections. > This tree eliminates usage of equal cost multipaths and results in > non-optimal pair-wise forwarding." > This is a reasonable proposal for replacement text. If there are no objections from the working group, or the IESG, I would be happy to make this change. Thanks! > - Section 1, Bridging Limitations: More specific comments: > - "Because of the potential for severe impact from looping traffic, > many (if not most) current bridge implementations stop forwarding > of traffic frames following a topology change event and restart > only after STP/RSTP is complete" is incorrect. All 802.1D bridges > allow (R/M)STP to complete before moving a port to forwarding > state. I'd remove the phrase in parentheses. Good suggestion. Assuming the same acceptance, I can make this change as well. > - "Inefficient inter-bridge connection usage". What do you > mean by this phrase? I assume this is a reasonably well understood aspect of using a spanning tree as opposed to using shortest path routing. It is not difficult to come up with a reasonable scenario in which shortest path forwarding results in 80% of the total link-by-link forwarding load that is generated by the same amount of traffic in a corresponding spanning tree scenario. The reason why this happens is that a spanning tree may be constructed in which the path for some destinations will traverse at least one additional link, when arriving from some sources. Practically speaking, unless a spanning tree is constructed per-source bridge, it's easy to show that this will be true for at least some source and destination pairs. Assuming the simplistic (VLAN-free) scenario that is basic to the "configuration-free" capability that is part of the chartered goals of TRILL, there would only be one spanning tree in a bridged network. Hence, in this scenario, there would be many cases in which traffic traverses at least one additional link. If traffic is demonstrably required to traverse more links than some theoretical minimum, than link utilization is - by definition - less efficient than it theoretically can be. > > - Section 1.2, Backward Compatibility and section 4.1: "...they > terminate a bridged spanning tree, (i.e. - they do not forward > BPDUs)". > > I thought that we have not concluded the discussion on preventing > loops for interconnected Bridges and RBridges based on the email > thread that started a while back. Putting a decision in this > section on the solution seems a little unnecessary. I am not sure that this text - or something like it - is unnecessary from a compatibility perspective, and it may be the case that this change would require a new working group last call. However, if it is acceptable to the IESG either that the change does not require a new last call, or a second working group last call is needed, then I would be happy to make this change as well. > What is proposed in the current solution is to run a spanning tree > protocol instance per port which maybe not scalable. > > I think something like "It's strongly desirable to minimize the > interaction between the bridges and Rbridges and constrain a > spanning tree" is more appropriate. Yet it is difficult to imagine how this would translate to a requirement that would make sense to someone evaluating the acceptability of a routing protocol for the TRILL problem-space. Perhaps it would be simpler to omit the offending text? > > - Ethernet and 802 is used interchangeably. Isn't Ethernet > 802.3 only ? > Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or > http://www.ieee802.org/3/. > > I don't see anything on what I consider to be another > important goal: to > have a single protocol to compute unicast, multicast and broadcast > routes. This reduces operational overhead by having to understand and > debug a single protocol. > > The IESG wrote: > > The IESG has received a request from the Transparent > Interconnection of > > Lots of Links WG (trill) to consider the following document: > > > > - 'TRILL Routing Requirements in Support of RBridges ' > > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive > comments to the > > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either > case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r > eqs-02.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=15187&rfc_flag=0 > > > > _______________________________________________ > > 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 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 l2L9qrXr009848 for <rbridge@postel.org>; Wed, 21 Mar 2007 02:52:53 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2L9qpeG012907; Wed, 21 Mar 2007 09:52:51 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2L9qceQ308210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 02:52:40 -0700 (PDT) Message-ID: <46010061.2020305@sun.com> Date: Wed, 21 Mar 2007 02:52:33 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: "J. R. Rivers" <jrrivers@nuovasystems.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDFDC@NT-IRVA-0750.brcm.ad.broadcom.com> <46003BA7.7070805@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2013B4B69@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013B4B69@nuova-ex1.hq.nuovaimpresa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 21 Mar 2007 09:53:13 -0000 Status: RO Content-Length: 313 J. R. Rivers wrote: > That seems more like a set of issues associated with access control > management that is beyond the scope of TRILL. The question we need to answer is whether RBridges need to support SVL, or whether we can say that we only do IVL. That is something that the WG needs to decide. Erik 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 l2L9XFkb004678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 21 Mar 2007 02:33:15 -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 l2L9w68G032638; Wed, 21 Mar 2007 03:58:07 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 04:33:02 -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, 21 Mar 2007 04:32:55 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF9EAE87@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <F98B60942429F3C001DF51B0@[10.0.0.174]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC Thread-Index: AcdrkMnZHwLXJBpAS9ixOUgLC+15IQAAe9VA References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org><34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> <F98B60942429F3C001DF51B0@[10.0.0.174]> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Harald Tveit Alvestrand" <harald@alvestrand.no>, "Silvano Gai" <sgai@nuovasystems.com>, <ietf@ietf.org> X-OriginalArrivalTime: 21 Mar 2007 09:33:02.0092 (UTC) FILETIME=[EBA524C0:01C76B9B] 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 l2L9XFkb004678 Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC 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, 21 Mar 2007 09:33:42 -0000 Status: RO Content-Length: 2023 Harald, As it was originally chartered, the TRILL working group allowed scope for definition of TRILL bridges that could be cheaply produced, modulo the inclusion of a ink-state routing protocol as a complicating factor. It is not clear at this point that this has changed. Consequently, at least some of the people working on this are thinking that a <well-known but not named here> work group switch may very well be replaced by a TRILL capable bridge - possibly made by the same vendor, at the same manufacturing facility. -- Eric > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Harald Tveit > Alvestrand > Sent: Wednesday, March 21, 2007 3:59 AM > To: Silvano Gai; ietf@ietf.org > Cc: rbridge@postel.org > Subject: Re: [rbridge] Last Call: > draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in > Support of RBridges) to Informational RFC > > > > --On 20. mars 2007 09:35 -0700 Silvano Gai > <sgai@nuovasystems.com> wrote: > > > 5) Introduction - Bridging limitation. The first paragraph refers to > > Ethernet networks used without Spanning Tree. This is > irrelevant, since > > Spanning Tree is always deployed in conjunction with Ethernet. The > > correct contrast must be between Ethernet with Spanning Tree and > > Ethernet with TRILL. The claim of a single > broadcast/flooding domain is > > incorrect since VLANs have solved this issue many years ago. > > "always" is too strong, since most unmanaged bridges (intended for > consumers' home networks, but often dangled off the edge of corporate > networks as port expanders, without asking for permission) > don't seem to be > supporting Spanning Tree. However, these are not going to > support TRILL > either, so for the environments considered here, "always" is > probably true. > > Harald > > _______________________________________________ > 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 l2L9LaHa001505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 21 Mar 2007 02:21:36 -0700 (PDT) Received: from [127.0.0.1] (c1-vpn2.isi.edu [128.9.176.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2L9LF9J020679; Wed, 21 Mar 2007 02:21:17 -0700 (PDT) Message-ID: <4600F900.9080907@isi.edu> Date: Wed, 21 Mar 2007 02:21:04 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-Enigmail-Version: 0.94.1.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE232F68094B1F8386A6E47FD" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Subject: [rbridge] protocol spec - change from "nonvolatile memory" 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, 21 Mar 2007 09:21:45 -0000 Status: RO Content-Length: 1080 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE232F68094B1F8386A6E47FD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Silvano (et al.), I'd like to suggest a change from: Once an RBridge has successfully acquired an address it SHOULD store it in non-volatile memory and reuse it in the case of a reboot. to: Once an RBridge has successfully acquired an address it SHOULD reuse it in the case of a restart. I.e., I think it's sufficient to describe the behavior desired. Joe --------------enigE232F68094B1F8386A6E47FD 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAPkAE5f5cImnZrsRAgKQAKD6ygUIQjR50qU9syWPodeOkqrsbwCcDGuF J3TJ2dZjpVdGX/dVEDR2o5A= =HwHx -----END PGP SIGNATURE----- --------------enigE232F68094B1F8386A6E47FD-- Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L7wxn6009671 for <rbridge@postel.org>; Wed, 21 Mar 2007 00:58:59 -0700 (PDT) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D6C925973B; Wed, 21 Mar 2007 08:58:58 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04941-04; Wed, 21 Mar 2007 08:58:53 +0100 (CET) Received: from [192.168.1.108] (dhcp-4009.ietf68.org [130.129.64.9]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28B88259739; Wed, 21 Mar 2007 08:58:53 +0100 (CET) Date: Wed, 21 Mar 2007 08:58:42 +0100 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: Silvano Gai <sgai@nuovasystems.com>, ietf@ietf.org Message-ID: <F98B60942429F3C001DF51B0@[10.0.0.174]> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC 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, 21 Mar 2007 07:59:10 -0000 Status: RO Content-Length: 885 --On 20. mars 2007 09:35 -0700 Silvano Gai <sgai@nuovasystems.com> wrote: > 5) Introduction - Bridging limitation. The first paragraph refers to > Ethernet networks used without Spanning Tree. This is irrelevant, since > Spanning Tree is always deployed in conjunction with Ethernet. The > correct contrast must be between Ethernet with Spanning Tree and > Ethernet with TRILL. The claim of a single broadcast/flooding domain is > incorrect since VLANs have solved this issue many years ago. "always" is too strong, since most unmanaged bridges (intended for consumers' home networks, but often dangled off the edge of corporate networks as port expanders, without asking for permission) don't seem to be supporting Spanning Tree. However, these are not going to support TRILL either, so for the environments considered here, "always" is probably true. Harald Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L2WaOC026704 for <rbridge@postel.org>; Tue, 20 Mar 2007 19:32:37 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 03:32:37 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2L2WaMw028963; Wed, 21 Mar 2007 03:32:36 +0100 Received: from [10.61.64.82] (ams3-vpn-dhcp82.cisco.com [10.61.64.82]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L2WQlZ028451; Wed, 21 Mar 2007 02:32:30 GMT Message-ID: <46009976.5030007@cisco.com> Date: Tue, 20 Mar 2007 19:33:26 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0pre (X11/20070224) MIME-Version: 1.0 To: ietf@ietf.org References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> In-Reply-To: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> 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=3794; t=1174444356; x=1175308356; c=relaxed/simple; s=amsdkim2001; 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]=20Last=20Call=3A=20draft-ietf-trill-routing -reqs=20(TRILL=20Routing=0A=20Requirements=20in=20Support=20of=20RBridges) =20to=20Informational=20RFC |Sender:=20; bh=AjsGKDhOhMecKvZK9zqnRhTFCeCkXmLXizvBO65OSYY=; b=Kr7S9DnWTU9skuLB41DL8ajwEZCJmJxdU1Mc7Fo3Mc651LdJ9N7sFahbeFae7bqHKy6UYvF9 ZPVelcqJkOXIoh1KV7tsL0nZHTycrkx1ps31xNEIIaDtDQhYENX/Pf0S; Authentication-Results: ams-dkim-2; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org, IETF-Announce <ietf-announce@ietf.org> Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC 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, 21 Mar 2007 02:33:45 -0000 Status: RO Content-Length: 3717 I have a few comments on the document. - Section 1, Bridging Limitations: The first two paragraphs are structured around the logic: because ethernet header doesn't have a TTL or a hop count, the only choice was to use spanning tree. IEEE 802.1 has defined several headers such as 802.1Q header that carries the VLAN. If they wanted to add a TTL, they could have. They picked spanning tree and said that therefore they didn't need a TTL. To the extent this represents history, I think it is inaccurate. To the extent it attempts to explain the rationale for RBridges, it seems unnecessary. A sufficient replacement maybe along the lines of: "Spanning Tree Protocol and its variants are the control protocol deployed in current 802.1D Ethernet bridges. This protocol constructs a single tree out of a mesh of network connections. This tree eliminates usage of equal cost multipaths and results in non-optimal pair-wise forwarding." - Section 1, Bridging Limitations: More specific comments: - "Because of the potential for severe impact from looping traffic, many (if not most) current bridge implementations stop forwarding of traffic frames following a topology change event and restart only after STP/RSTP is complete" is incorrect. All 802.1D bridges allow (R/M)STP to complete before moving a port to forwarding state. I'd remove the phrase in parentheses. - "Inefficient inter-bridge connection usage". What do you mean by this phrase ? - Section 1.2, Backward Compatibility and section 4.1: "...they terminate a bridged spanning tree, (i.e. - they do not forward BPDUs)". I thought that we have not concluded the discussion on preventing loops for interconnected Bridges and RBridges based on the email thread that started a while back. Putting a decision in this section on the solution seems a little unnecessary. What is proposed in the current solution is to run a spanning tree protocol instance per port which maybe not scalable. I think something like "It's strongly desirable to minimize the interaction between the bridges and Rbridges and constrain a spanning tree" is more appropriate. - Ethernet and 802 is used interchangeably. Isn't Ethernet 802.3 only ? Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or http://www.ieee802.org/3/. I don't see anything on what I consider to be another important goal: to have a single protocol to compute unicast, multicast and broadcast routes. This reduces operational overhead by having to understand and debug a single protocol. The IESG wrote: > The IESG has received a request from the Transparent Interconnection of > Lots of Links WG (trill) to consider the following document: > > - 'TRILL Routing Requirements in Support of RBridges ' > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0 > > _______________________________________________ > 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 l2KLYdZk008754 for <rbridge@postel.org>; Tue, 20 Mar 2007 14:34:39 -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, 20 Mar 2007 14:34:36 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B4BCF@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF9EAC18@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC thread-index: AcdoFdpWI6S5xbwWQBS+xJJb9a4hygC26h0gAAi5KnAAB/bbUA== References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCF9EAC18@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, <ietf@ietf.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 l2KLYdZk008754 Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC 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, 20 Mar 2007 21:35:03 -0000 Status: RO Content-Length: 11721 Eric, Inline > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Tuesday, March 20, 2007 11:31 AM > To: Silvano Gai; ietf@ietf.org > Cc: rbridge@postel.org > Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs > (TRILLRoutingRequirements in Support of RBridges) to Informational RFC > > Silvano, > > Thanks for posting these comments. Please see below. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > > Sent: Tuesday, March 20, 2007 12:35 PM > > To: ietf@ietf.org > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Last Call: > > draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in > > Support of RBridges) to Informational RFC > > > > > > This document has some issues that need to be corrected before it can > > pass an IESG last call. > > I think as a strict matter of process, we don't get to say what MUST be > corrected before a document can pass IESG last call (if there is such a > thing). > > Luckily, I believe this is an IETF Last Call, where the idea is that the > IESG is asking for our input before making _their_ decision as to what - > if anything - MUST be changed. > > > > > In order of importance: > > 1) The document equates Ethernet with IEEE 802 and this is clearly > > incorrect, since IEEE 802 includes also technologies like Token Ring, > > DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet > > must be equated with IEEE 802.3 > > Which is historically at least as incorrect. > > This comment was made during the working group last call. Specific > changes were made that I hoped would address this comment. I made many comments to this document during working group last call, some were considered, some were ignored. There was not a second WG last call, the IESG last call was posted and I repeated the comments that were not addressed and that I think need to be addressed. I may have used slightly different words in the two postings. > > Why did you not earlier state specifically what part of the changes > made were not satisfactory to you at that time? > I stated very clear that IEEE 802 is a larger project that includes not only Ethernet, but Token Ring, Token Bus, DQDB, Wireless, etc. Ethernet is specified in IEEE 802.3. Since you and I continue to disagree and you don't accept to replace IEEE 802 with IEEE 802.3 I think this should be judged by an IEEE expert in the IESG. > > > > 2) The document discusses Spanning Tree compatibility in section 1.2 > > where it claims that BPDUs must be terminated and in Section 4.1 where > > the term "block" is used. This is clearly in contrast with what > > discussed in the WG and in the base protocol spec, where BPDUs are at > > least processed (in one proposal) or even sourced by RBridges (in an > > alternate proposal). > > This was the terminology decided on by the working group at the time. > > This comment was also made during the working group last call, and > explanations were provided and - I believe - some small explanatory > changes were made to the text. > > Again, why did you not earlier state specifically what part of the > changes made were not satisfactory to you at that time? > I stated at that time that this text was inappropriate and the base protocol draft contains text agreed in the WG that contradict your view. > > > > 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not > an > > approved document. It is also substantially incorrect since many terms > > listed are not used in this document and some are not agreed in the > WG. > > I propose to eliminate this section. > > As a matter of process, again, this issue is addressed by listing the > Architecture as a Normative reference. > > Because the document is intended to be an informational RFC, the WG > chairs informed me that IESG members are comfortable with pushing this > to IETF last call ahead of its (one) normative reference. > > That, again, is their prerogative. > > > > > 4) The document uses the term "will" that is not compliant with > RFC2119. > > In general a better definition of what is mandatory and what is > optional > > is important in a requirement document. > > This is an informational document, proposed as an informational RFC. > > This is also a requirements document, stating what is needed from any > candidate routing protocol. It is not an options list, or a wish list. > People may decide to ignore requirements in this document, and that is > okay - because it is strictly informational. The requirements listed > in this document represent the things that the TRILL working group had > agreed were needed and should be documented at the time the document > was/is/will be published. > > The choice to avoid 2119 language was - for this reason - a deliberate > one, discussed on several occasions in the working group. There is no > inclusion of the "usage" of RFC 2119 terminology, nor any reference to > RFC 2119. Hence the word "will" can be, and is, used as it would be > interpreted in the English language. > > If you would care to provide a reasonably authoritative reference for > English usage of the word "will" that is in conflict with any specific > usage of the word in this document, I'd be happy to consider including > it as a reference in this document and changing the specific instances > you point out. > > > > > 5) Introduction - Bridging limitation. The first paragraph refers to > > Ethernet networks used without Spanning Tree. This is irrelevant, > > since Spanning Tree is always deployed in conjunction with Ethernet. > > This follows only because: > > o you disagree with the inclusive way this document uses the term > Ethernet. Let's not conflate issues here. > > The way the document uses the term Ethernet was explained to you > > - and to the working group - as a result of your earlier working > > group last call comments. > > o you exclude Ethernet deployments in small networks where small > Ethernet switches _clearly_ do not use spanning tree. > > o you exclude Ethernet, and Ethernet-like, encapsulation in new, > in progress, and yet to be developed technologies in making > this statement. > > In short, your statement that spanning tree is always used in Ethernet > networks is correct only if you define Ethernet networks as including > spanning tree. Interestingly enough, I do not recall that spanning > tree is actually defined by 802.3. > That is because the work that TRILL does is really an IEEE 802.1 replacement, but still DOES NOT cover IEEE 802 as a whole. > There was not at the time of the working group last call, nor have > I seen any indication that there is now, a consensus to change the > wording of this document with respect to this issue. > > My earlier justification that using a less inclusive interpretation > of "Ethernet" would mean replacing the term Ethernet with a more > explicitly inclusive (and complex) phrase in each place where it > occurs, still applies. > > > The correct contrast must be between Ethernet with Spanning Tree and > > Ethernet with TRILL. > > This only follows if you assume that the way that Ethernet is used > in this document is wrong. > > A point has been made - more than once - that there is no absolutely > cannonical definition of Ethernet. Not True. Ethernet is commonly defined as: Digital Equipment Corporation, Intel, Xerox, The Ethernet, Version 2.0, November 1982. This document and the term "Ethernet" are widely referenced in IEEE 802.3 (just do a search on the PDF file). In particular TRILL uses the Ethernet V2 encapsulation (the same used by IEEE 802.1Q) in which Length is replaced by Type. Please see IEEE 802.3 standard. You might choose to decide that > Ethernet is defined by 802.3 - in spite of the fact that Ethernet and > 802.3 have been considered by many to be distinct for many years. If > you do, then you would be limiting the definition to exclude how the > technology works with bridges, I never said that bridges are IEEE 802.3, Bridges are a combination of IEEE 802.1D and IEEE 802.1Q. -- Silvano and you would be forcing arbitrarily > complicated verbiage in what is essentially a relatively high-level > document that doesn't need that degree of technical precision. And > you would still be wrong by some (other) definitions of Ethernet. > > > The claim of a single broadcast/flooding domain is incorrect since > > VLANs have solved this issue many years ago. > > For the purposes of this document, it is not explicitly necessary - > nor necessarily even a good idea - to dwell in too great detail on > the ways that a domain that would be "a single broadcast/flooding > domain" in the absence of VLANs, becomes multiply sub-setted by the > inclusions of VLANs. > > I do not recall seeing this comment during the working group last > call. If I had, one of the things I would have pointed out is that > this is not explicitly an "issue" in forming requirements in this > document, and that your taking exception to the wording - in a more > representative context - is based on your interpretation of the > statement (possibly in a less representative context). Here is the > context: > > "... bridged networks consist of single broadcast/flooding domains." > > One - fairly simplistic - way to look at VLANs is that the use of a > VLAN ID allows VLAN bridges to treat the non-VLAN broadcast domain > as having been divided into multiple logical broadcast domains, with > each such logical broadcast domain being effectively - logically - > a bridged network consisting of a single broadcast/flooding domain. > > In this view, the statement is not incorrect - however you might not > like it. > > If you would like me to phrase this point some other way, propose an > alternative wording, don't just say "it's wrong." > > > > > -- Silvano Gai > > > > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > > On > > > Behalf Of The IESG > > > Sent: Friday, March 16, 2007 2:53 PM > > > To: IETF-Announce > > > Cc: rbridge@postel.org > > > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL > > > RoutingRequirements in Support of RBridges) to Informational RFC > > > > > > The IESG has received a request from the Transparent Interconnection > > of > > > Lots of Links WG (trill) to consider the following document: > > > > > > - 'TRILL Routing Requirements in Support of RBridges ' > > > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive comments to > > the > > > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, > > > comments may be sent to iesg@ietf.org instead. In either > > case, please > > > retain the beginning of the Subject line to allow automated sorting. > > > > > > The file can be obtained via > > > > > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r > > eqs-02.txt > > > > > > > > > IESG discussion can be tracked via > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > > w_id&dTag= > > 15 > > > 187&rfc_flag=0 > > > > > > _______________________________________________ > > > 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 l2KKTcNb018599 for <rbridge@postel.org>; Tue, 20 Mar 2007 13:29:39 -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, 20 Mar 2007 13:29:21 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B4B69@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <46003BA7.7070805@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness thread-index: AcdrK10TFuxFniX1QcKAoJnSnsOimAAAvQBQ References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDFDC@NT-IRVA-0750.brcm.ad.broadcom.com> <46003BA7.7070805@sun.com> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jrrivers@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2KKTcNb018599 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 20:29:47 -0000 Status: RO Content-Length: 2204 That seems more like a set of issues associated with access control management that is beyond the scope of TRILL. JR > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark > Sent: Tuesday, March 20, 2007 12:53 PM > To: Caitlin Bestler > Cc: rbridge@postel.org; Radia Perlman > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > Caitlin Bestler wrote: > > > It's a perfectly reasonable behavior, as long as the VID is at > > least checked (i.e., it is an attribute, not a key field). A set > > of RBridges that *all* used this approach would work perfectly fine. > > Are you taking into account hosts that maliciously change their MAC > address in order to affect the bridging of packets for a host > that is on > a different VLAN? > > Are you taking int account hosts that are part of multiple > VLANs using a > single NIC and single MAC address (servers often are > configured in such > ways by having the server add the 802.1Q headers and the bridge just > enforce that the VID is in the allowed set for that port). > > Erik > > > > > The real issue is whether RBridges that will realistically tend to > > use Independent Learning can easily accommodate some of their peers > > doing Shared Learning, and if so, how. > > > > For example, the rule could be that you can use Shared Learning as > > long as no other RBridge can detect that you aren't using > Independent > > Learning. Or Shared/Independent Learning could be a flag that each > > RBridge advertises. Or each RBridge could advertise it's > VID->FID map. > > > > All of these work, the question is which are justified. As much as I > > dislike increasing the key size I can certainly see the > advantages to > > maintaining a distributed database of requiring all RBridges to use > > Independent Learning. So I'd lean toward simply standardizing on > > Independent Learning. But any new requirement is best explicitly > > stated, not inferred from the data descriptions. > > > > _______________________________________________ > 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 l2KJrROa007931 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Tue, 20 Mar 2007 12:53:27 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2KJrKLY020866; Tue, 20 Mar 2007 19:53:22 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2KJrGtQ233171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 12:53:18 -0700 (PDT) Message-ID: <46003BA7.7070805@sun.com> Date: Tue, 20 Mar 2007 12:53:11 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDFDC@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DDFDC@NT-IRVA-0750.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 19:53:46 -0000 Status: RO Content-Length: 1550 Caitlin Bestler wrote: > It's a perfectly reasonable behavior, as long as the VID is at > least checked (i.e., it is an attribute, not a key field). A set > of RBridges that *all* used this approach would work perfectly fine. Are you taking into account hosts that maliciously change their MAC address in order to affect the bridging of packets for a host that is on a different VLAN? Are you taking int account hosts that are part of multiple VLANs using a single NIC and single MAC address (servers often are configured in such ways by having the server add the 802.1Q headers and the bridge just enforce that the VID is in the allowed set for that port). Erik > The real issue is whether RBridges that will realistically tend to > use Independent Learning can easily accommodate some of their peers > doing Shared Learning, and if so, how. > > For example, the rule could be that you can use Shared Learning as > long as no other RBridge can detect that you aren't using Independent > Learning. Or Shared/Independent Learning could be a flag that each > RBridge advertises. Or each RBridge could advertise it's VID->FID map. > > All of these work, the question is which are justified. As much as I > dislike increasing the key size I can certainly see the advantages to > maintaining a distributed database of requiring all RBridges to use > Independent Learning. So I'd lean toward simply standardizing on > Independent Learning. But any new requirement is best explicitly > stated, not inferred from the data descriptions. > 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 l2KIUs0D011896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 20 Mar 2007 11:30:54 -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 l2KItic8010981; Tue, 20 Mar 2007 12:55:44 -0600 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 13:30:41 -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, 20 Mar 2007 13:30:32 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF9EAC18@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC Thread-Index: AcdoFdpWI6S5xbwWQBS+xJJb9a4hygC26h0gAAi5KnA= References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, <ietf@ietf.org> X-OriginalArrivalTime: 20 Mar 2007 18:30:41.0387 (UTC) FILETIME=[DD452BB0:01C76B1D] 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 l2KIUs0D011896 Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC 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, 20 Mar 2007 18:31:23 -0000 Status: RO Content-Length: 9481 Silvano, Thanks for posting these comments. Please see below. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > Sent: Tuesday, March 20, 2007 12:35 PM > To: ietf@ietf.org > Cc: rbridge@postel.org > Subject: Re: [rbridge] Last Call: > draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in > Support of RBridges) to Informational RFC > > > This document has some issues that need to be corrected before it can > pass an IESG last call. I think as a strict matter of process, we don't get to say what MUST be corrected before a document can pass IESG last call (if there is such a thing). Luckily, I believe this is an IETF Last Call, where the idea is that the IESG is asking for our input before making _their_ decision as to what - if anything - MUST be changed. > > In order of importance: > 1) The document equates Ethernet with IEEE 802 and this is clearly > incorrect, since IEEE 802 includes also technologies like Token Ring, > DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet > must be equated with IEEE 802.3 Which is historically at least as incorrect. This comment was made during the working group last call. Specific changes were made that I hoped would address this comment. Why did you not earlier state specifically what part of the changes made were not satisfactory to you at that time? > > 2) The document discusses Spanning Tree compatibility in section 1.2 > where it claims that BPDUs must be terminated and in Section 4.1 where > the term "block" is used. This is clearly in contrast with what > discussed in the WG and in the base protocol spec, where BPDUs are at > least processed (in one proposal) or even sourced by RBridges (in an > alternate proposal). This was the terminology decided on by the working group at the time. This comment was also made during the working group last call, and explanations were provided and - I believe - some small explanatory changes were made to the text. Again, why did you not earlier state specifically what part of the changes made were not satisfactory to you at that time? > > 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not an > approved document. It is also substantially incorrect since many terms > listed are not used in this document and some are not agreed in the WG. > I propose to eliminate this section. As a matter of process, again, this issue is addressed by listing the Architecture as a Normative reference. Because the document is intended to be an informational RFC, the WG chairs informed me that IESG members are comfortable with pushing this to IETF last call ahead of its (one) normative reference. That, again, is their prerogative. > > 4) The document uses the term "will" that is not compliant with RFC2119. > In general a better definition of what is mandatory and what is optional > is important in a requirement document. This is an informational document, proposed as an informational RFC. This is also a requirements document, stating what is needed from any candidate routing protocol. It is not an options list, or a wish list. People may decide to ignore requirements in this document, and that is okay - because it is strictly informational. The requirements listed in this document represent the things that the TRILL working group had agreed were needed and should be documented at the time the document was/is/will be published. The choice to avoid 2119 language was - for this reason - a deliberate one, discussed on several occasions in the working group. There is no inclusion of the "usage" of RFC 2119 terminology, nor any reference to RFC 2119. Hence the word "will" can be, and is, used as it would be interpreted in the English language. If you would care to provide a reasonably authoritative reference for English usage of the word "will" that is in conflict with any specific usage of the word in this document, I'd be happy to consider including it as a reference in this document and changing the specific instances you point out. > > 5) Introduction - Bridging limitation. The first paragraph refers to > Ethernet networks used without Spanning Tree. This is irrelevant, > since Spanning Tree is always deployed in conjunction with Ethernet. This follows only because: o you disagree with the inclusive way this document uses the term Ethernet. Let's not conflate issues here. The way the document uses the term Ethernet was explained to you - and to the working group - as a result of your earlier working group last call comments. o you exclude Ethernet deployments in small networks where small Ethernet switches _clearly_ do not use spanning tree. o you exclude Ethernet, and Ethernet-like, encapsulation in new, in progress, and yet to be developed technologies in making this statement. In short, your statement that spanning tree is always used in Ethernet networks is correct only if you define Ethernet networks as including spanning tree. Interestingly enough, I do not recall that spanning tree is actually defined by 802.3. There was not at the time of the working group last call, nor have I seen any indication that there is now, a consensus to change the wording of this document with respect to this issue. My earlier justification that using a less inclusive interpretation of "Ethernet" would mean replacing the term Ethernet with a more explicitly inclusive (and complex) phrase in each place where it occurs, still applies. > The correct contrast must be between Ethernet with Spanning Tree and > Ethernet with TRILL. This only follows if you assume that the way that Ethernet is used in this document is wrong. A point has been made - more than once - that there is no absolutely cannonical definition of Ethernet. You might choose to decide that Ethernet is defined by 802.3 - in spite of the fact that Ethernet and 802.3 have been considered by many to be distinct for many years. If you do, then you would be limiting the definition to exclude how the technology works with bridges, and you would be forcing arbitrarily complicated verbiage in what is essentially a relatively high-level document that doesn't need that degree of technical precision. And you would still be wrong by some (other) definitions of Ethernet. > The claim of a single broadcast/flooding domain is incorrect since > VLANs have solved this issue many years ago. For the purposes of this document, it is not explicitly necessary - nor necessarily even a good idea - to dwell in too great detail on the ways that a domain that would be "a single broadcast/flooding domain" in the absence of VLANs, becomes multiply sub-setted by the inclusions of VLANs. I do not recall seeing this comment during the working group last call. If I had, one of the things I would have pointed out is that this is not explicitly an "issue" in forming requirements in this document, and that your taking exception to the wording - in a more representative context - is based on your interpretation of the statement (possibly in a less representative context). Here is the context: "... bridged networks consist of single broadcast/flooding domains." One - fairly simplistic - way to look at VLANs is that the use of a VLAN ID allows VLAN bridges to treat the non-VLAN broadcast domain as having been divided into multiple logical broadcast domains, with each such logical broadcast domain being effectively - logically - a bridged network consisting of a single broadcast/flooding domain. In this view, the statement is not incorrect - however you might not like it. If you would like me to phrase this point some other way, propose an alternative wording, don't just say "it's wrong." > > -- Silvano Gai > > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of The IESG > > Sent: Friday, March 16, 2007 2:53 PM > > To: IETF-Announce > > Cc: rbridge@postel.org > > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL > > RoutingRequirements in Support of RBridges) to Informational RFC > > > > The IESG has received a request from the Transparent Interconnection > of > > Lots of Links WG (trill) to consider the following document: > > > > - 'TRILL Routing Requirements in Support of RBridges ' > > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either > case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r > eqs-02.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag= > 15 > > 187&rfc_flag=0 > > > > _______________________________________________ > > 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 mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KHHXeB019693 for <rbridge@postel.org>; Tue, 20 Mar 2007 10:17:33 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 20 Mar 2007 10:17:18 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 6EE942AF; Tue, 20 Mar 2007 10:17:18 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 59E7B2AE; Tue, 20 Mar 2007 10:17:18 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBY75200; Tue, 20 Mar 2007 10:17:17 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 3BD3069CA3; Tue, 20 Mar 2007 10:17:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Mar 2007 10:16:51 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DE086@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013B4A32@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAMXCd8AAKFPHYAAAaEEQ From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A1EC8943706110898-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2KHHXeB019693 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 17:17:51 -0000 Status: RO Content-Length: 2129 Silvano Gai wrote: > Caitlin, > > inline > >> -----Original Message----- >> From: Caitlin Bestler [mailto:caitlinb@broadcom.com] >> Sent: Monday, March 19, 2007 2:50 PM >> To: Silvano Gai; Radia Perlman >> Cc: rbridge@postel.org; Erik Nordmark >> Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness >> >> Silvano Gai wrote: >>> I think TRILL needs to do exactly what IEEE 802.1Q does. >>> AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >>> =N. >>> >>> N is never advertised outside the bridge, and the mapping of M to N >>> is never advertised outside the bridge. TRILL must do the same. >>> >>> Learning is done on {VID, MAC-address} pairs. TRILL must do the >>> same. >>> >> My reading of Appendix B is that Shared Learning is allowed, where >> VID is not a key field (i.e, there is only one FID supported). >> Appendix B details some of the problems this creates. I believe the >> problems for RBridges are even greater than for simple Bridges. This >> probably justifies restricting RBridges to the Independent Learning >> model, but any such additional restriction should be explicitly >> stated. > > I am not saying I want to restrict, I am saying that in > bridges what triggers learning is always the reception of a > frame that has a {VID, MAC-address} pair. The fact that the > VID, on that particular bridge, shares the FID with other > VIDs is what causes shared learning. But shared learning > NEVER propagates. TRILL MUST NOT propagate shared learning. > IT MUST always propagate {VID, MAC-address}. Recipients may > decide to do individual or shared learning. > > -- Silvano >From a standards point of view I could see stating that all TRILL-related protocols MUST be based on Independent Learning, but that an RBridge MAY use Shared Learning for its local ports when acting as a Bridge. And I suppose if you literally grafted an RBridge as an add-on module to an existing Bridge with shared learning it might even make sense. Effectively, however, it is requiring RBridges to use Independent Learning. I see that requirement as inevitable, and therefore best stated explicitly. 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 l2KH6kbQ016259 for <rbridge@postel.org>; Tue, 20 Mar 2007 10:06: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: Tue, 20 Mar 2007 10:06:43 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B4A32@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness thread-index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAMXCd8AAKFPHYA== References: <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.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 l2KH6kbQ016259 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 17:07:10 -0000 Status: RO Content-Length: 1545 Caitlin, inline > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Monday, March 19, 2007 2:50 PM > To: Silvano Gai; Radia Perlman > Cc: rbridge@postel.org; Erik Nordmark > Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness > > Silvano Gai wrote: > > I think TRILL needs to do exactly what IEEE 802.1Q does. > > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. > > > > N is never advertised outside the bridge, and the mapping of > > M to N is never advertised outside the bridge. TRILL must do the same. > > > > Learning is done on {VID, MAC-address} pairs. TRILL must do the same. > > > My reading of Appendix B is that Shared Learning is allowed, where VID > is not a key field (i.e, there is only one FID supported). Appendix B > details some of the problems this creates. I believe the problems for > RBridges are even greater than for simple Bridges. This probably > justifies > restricting RBridges to the Independent Learning model, but any such > additional restriction should be explicitly stated. I am not saying I want to restrict, I am saying that in bridges what triggers learning is always the reception of a frame that has a {VID, MAC-address} pair. The fact that the VID, on that particular bridge, shares the FID with other VIDs is what causes shared learning. But shared learning NEVER propagates. TRILL MUST NOT propagate shared learning. IT MUST always propagate {VID, MAC-address}. Recipients may decide to do individual or shared learning. -- 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 l2KGZ8Rv004982 for <rbridge@postel.org>; Tue, 20 Mar 2007 09:35: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: Tue, 20 Mar 2007 09:35:03 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B49F4@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC thread-index: AcdoFdpWI6S5xbwWQBS+xJJb9a4hygC26h0g References: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> From: "Silvano Gai" <sgai@nuovasystems.com> To: <ietf@ietf.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 l2KGZ8Rv004982 Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC 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, 20 Mar 2007 16:35:57 -0000 Status: RO Content-Length: 2952 This document has some issues that need to be corrected before it can pass an IESG last call. In order of importance: 1) The document equates Ethernet with IEEE 802 and this is clearly incorrect, since IEEE 802 includes also technologies like Token Ring, DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet must be equated with IEEE 802.3 2) The document discusses Spanning Tree compatibility in section 1.2 where it claims that BPDUs must be terminated and in Section 4.1 where the term "block" is used. This is clearly in contrast with what discussed in the WG and in the base protocol spec, where BPDUs are at least processed (in one proposal) or even sourced by RBridges (in an alternate proposal). 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not an approved document. It is also substantially incorrect since many terms listed are not used in this document and some are not agreed in the WG. I propose to eliminate this section. 4) The document uses the term "will" that is not compliant with RFC2119. In general a better definition of what is mandatory and what is optional is important in a requirement document. 5) Introduction - Bridging limitation. The first paragraph refers to Ethernet networks used without Spanning Tree. This is irrelevant, since Spanning Tree is always deployed in conjunction with Ethernet. The correct contrast must be between Ethernet with Spanning Tree and Ethernet with TRILL. The claim of a single broadcast/flooding domain is incorrect since VLANs have solved this issue many years ago. -- Silvano Gai > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of The IESG > Sent: Friday, March 16, 2007 2:53 PM > To: IETF-Announce > Cc: rbridge@postel.org > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL > RoutingRequirements in Support of RBridges) to Informational RFC > > The IESG has received a request from the Transparent Interconnection of > Lots of Links WG (trill) to consider the following document: > > - 'TRILL Routing Requirements in Support of RBridges ' > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 15 > 187&rfc_flag=0 > > _______________________________________________ > 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 l2KG6TXX025902 for <rbridge@postel.org>; Tue, 20 Mar 2007 09:06:29 -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 <0JF700F8IM2EPD10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 20 Mar 2007 09:06:15 -0700 (PDT) Received: from sun.com ([129.150.17.10]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JF7003I6M2CZA10@mail.sunlabs.com> for rbridge@postel.org; Tue, 20 Mar 2007 09:06:14 -0700 (PDT) Date: Tue, 20 Mar 2007 09:06:26 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <45FFFA41.4070106@sun.com> To: Erik Nordmark <erik.nordmark@sun.com> Message-id: <46000682.7040908@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> <45FFFA41.4070106@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 16:06:44 -0000 Status: RO Content-Length: 1136 Re Erik's: >>I don't see it being a reasonable default for RBridges. Not just not reasonable as default, but *ever*. I'm sure we don't want to have a parameter allowing RBridges to do shared learning. Radia Erik Nordmark wrote: > Caitlin Bestler wrote: > >> My reading of Appendix B is that Shared Learning is allowed, where VID >> is not a key field (i.e, there is only one FID supported). Appendix B >> details some of the problems this creates. I believe the problems for >> RBridges are even greater than for simple Bridges. This probably >> justifies >> restricting RBridges to the Independent Learning model, but any such >> additional restriction should be explicitly stated. > > > My understanding is is that shared learning is useless when VLANs are > used for isolation/security. With shared learning a host on VLAN A can > trivially cause a DoS attack VLAN B by just sending packets with the > source MAC address being the MAC address of another host on another VLAN. > > Thus I'd be surprised if it is used much in practice with bridges. > > I don't see it being a reasonable default for RBridges. > > 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 l2KFipb1018540 for <rbridge@postel.org>; Tue, 20 Mar 2007 08:44:51 -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, 20 Mar 2007 08:44:35 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B49B9@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <45FFFA41.4070106@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness thread-index: AcdrA2TDkMxQS/IcSE2K+shaF8GFHgAAyGsQ References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> <45FFFA41.4070106@sun.com> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jrrivers@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2KFipb1018540 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 15:45:10 -0000 Status: RO Content-Length: 1513 If I'm remembering my history correctly, 3Com wanted to use this "mode" to enable a short-cut routing mechanism (whose name escapes me now). JR > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark > Sent: Tuesday, March 20, 2007 8:14 AM > To: Caitlin Bestler > Cc: rbridge@postel.org; Radia Perlman > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > Caitlin Bestler wrote: > > > My reading of Appendix B is that Shared Learning is > allowed, where VID > > is not a key field (i.e, there is only one FID supported). > Appendix B > > details some of the problems this creates. I believe the > problems for > > RBridges are even greater than for simple Bridges. This probably > > justifies > > restricting RBridges to the Independent Learning model, but any such > > additional restriction should be explicitly stated. > > My understanding is is that shared learning is useless when VLANs are > used for isolation/security. With shared learning a host on > VLAN A can > trivially cause a DoS attack VLAN B by just sending packets with the > source MAC address being the MAC address of another host on > another VLAN. > > Thus I'd be surprised if it is used much in practice with bridges. > > I don't see it being a reasonable default for RBridges. > > Erik > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KFUsqE014392 for <rbridge@postel.org>; Tue, 20 Mar 2007 08:30:54 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 20 Mar 2007 08:30:48 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CED202AE; Tue, 20 Mar 2007 08:30:48 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B3D392AF; Tue, 20 Mar 2007 08:30:48 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBY40126; Tue, 20 Mar 2007 08:29:57 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 8605569CA8; Tue, 20 Mar 2007 08:29:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Mar 2007 08:29:24 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DDFDC@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <45FFFA41.4070106@sun.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: AcdrAoIbrmi6bAfaRS27KB7+iwNJVwAAJ60w From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Erik Nordmark" <erik.nordmark@sun.com> X-WSS-ID: 69E121A23706056426-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2KFUsqE014392 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 15:31:11 -0000 Status: RO Content-Length: 1961 Erik Nordmark wrote: > Caitlin Bestler wrote: > >> My reading of Appendix B is that Shared Learning is allowed, where >> VID is not a key field (i.e, there is only one FID supported). >> Appendix B details some of the problems this creates. I believe the >> problems for RBridges are even greater than for simple Bridges. This >> probably justifies restricting RBridges to the Independent Learning >> model, but any such additional restriction should be explicitly >> stated. > > My understanding is is that shared learning is useless when > VLANs are used for isolation/security. With shared learning a > host on VLAN A can trivially cause a DoS attack VLAN B by > just sending packets with the source MAC address being the > MAC address of another host on another VLAN. > > Thus I'd be surprised if it is used much in practice with bridges. > > I don't see it being a reasonable default for RBridges. > > Erik It's a perfectly reasonable behavior, as long as the VID is at least checked (i.e., it is an attribute, not a key field). A set of RBridges that *all* used this approach would work perfectly fine. The real issue is whether RBridges that will realistically tend to use Independent Learning can easily accommodate some of their peers doing Shared Learning, and if so, how. For example, the rule could be that you can use Shared Learning as long as no other RBridge can detect that you aren't using Independent Learning. Or Shared/Independent Learning could be a flag that each RBridge advertises. Or each RBridge could advertise it's VID->FID map. All of these work, the question is which are justified. As much as I dislike increasing the key size I can certainly see the advantages to maintaining a distributed database of requiring all RBridges to use Independent Learning. So I'd lean toward simply standardizing on Independent Learning. But any new requirement is best explicitly stated, not inferred from the data descriptions. 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 l2KFEQJW009108 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Tue, 20 Mar 2007 08:14:26 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.108.31]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2KFELBX005413; Tue, 20 Mar 2007 15:14:21 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2KFEEeK188206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 08:14:16 -0700 (PDT) Message-ID: <45FFFA41.4070106@sun.com> Date: Tue, 20 Mar 2007 08:14:09 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 20 Mar 2007 15:14:36 -0000 Status: RO Content-Length: 868 Caitlin Bestler wrote: > My reading of Appendix B is that Shared Learning is allowed, where VID > is not a key field (i.e, there is only one FID supported). Appendix B > details some of the problems this creates. I believe the problems for > RBridges are even greater than for simple Bridges. This probably > justifies > restricting RBridges to the Independent Learning model, but any such > additional restriction should be explicitly stated. My understanding is is that shared learning is useless when VLANs are used for isolation/security. With shared learning a host on VLAN A can trivially cause a DoS attack VLAN B by just sending packets with the source MAC address being the MAC address of another host on another VLAN. Thus I'd be surprised if it is used much in practice with bridges. I don't see it being a reasonable default for RBridges. Erik Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JMSVZ5018063 for <rbridge@postel.org>; Mon, 19 Mar 2007 15:28:31 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 23:28:32 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2JMSVhs004628; Mon, 19 Mar 2007 23:28:31 +0100 Received: from [10.61.64.140] (ams3-vpn-dhcp140.cisco.com [10.61.64.140]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2JMSTlZ022340; Mon, 19 Mar 2007 22:28:29 GMT Message-ID: <45FF0EC9.3080203@cisco.com> Date: Mon, 19 Mar 2007 15:29:29 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0pre (X11/20070224) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6E21C.2060802@sun.com> In-Reply-To: <45F6E21C.2060802@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=3016; t=1174343311; x=1175207311; c=relaxed/simple; s=amsdkim1002; 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]=20VLAN=20Scoping=20/=20MAC=20Uniqueness |Sender:=20; bh=1ME1pliqS+73vJ447+n06OrlEAcZ1FsfYiT+/FR00yM=; b=pFSGDrlTVzyVcOdo96hmnEe5N6Y5x/9LDTdjH35xnTQDmbTeLligZSQ+a+pyMXOHJrfsc9M/ XBuy/pHu/RAJ6BmxXeock13XIOKUeLXVQksyjiaF/PKu/oLGRFz1zbMG; Authentication-Results: ams-dkim-1; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 19 Mar 2007 22:29:05 -0000 Status: RO Content-Length: 2937 Radia, I prefer option b as well. Just as in regular 802.1d bridges, we need to age out MAC addresses periodically if we don't see them. One important point is that we should set the default age timer to be greater than the default ARP cache timer to avoid flooding due to aging out a MAC entry but with the hosts still retaining the ARP entry. Dinesh Radia Perlman wrote: > Ah. Now I understand the issue, I think. You are saying that if MAC > addresses are globally unique, > an RBridge attached only to VLAN A should still monitor the endnode > membership of the other VLANs, > in case one of its endnodes moves and appears elsewhere. > > So I think we are talking about two alternatives: > a) have all RBridges see all endnode memberships on all VLANs > b) have RBridges only see endnode memberships for VLANs they are > directly attached to. > > I see the disadvantages of each as: > a) extra bandwidth and storage for having endnode membership go everywhere > b) less timely noticing an endnode has moved to another VLAN > > If I understand things correctly, I much prefer b), for the following > reasons: > 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by > pretending to be MAC addresses > belonging to VLAN B (so option b is safer and provides more separation > between VLANs) > 2) option b) greatly lowers the burden on RBridges because they only > have to keep information for > their own VLANs > 3) option b) is likely to save bandwidth on distributing endnode information > 4) there might be cases where an endnode might attach to multiple VLANs, > and the RBridges will > panic unnecessarily > > Radia > > Caitlin Bestler wrote: > > >> The issue is not how the information is relayed, or how it is stored, >> but who determines what information is relevant. >> >> If all RBridges track MAC Addresses scoped within a VLAN scope >> then everything you suggest works perfectly fine. The only correction >> needed would be to emphasize that this is indeed a requirement. >> >> But any RBridge that uses a global scope for MAC Addresses should >> be told of new MAC detections on different VLANs because such >> an RBridge would want to delete the old location. >> >> Unless the RBridge that detected the MAC address knows that all >> other RBridges are using VLAN scoped MAC addresses they should >> distribute the new information to *all* RBRidges, not just those on >> the VLAN where the address was discovered. >> >> >> _______________________________________________ >> 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-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 l2JMNv0v016912 for <rbridge@postel.org>; Mon, 19 Mar 2007 15:23:57 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2007 15:23:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2JMNv5C006878; Mon, 19 Mar 2007 15:23:57 -0700 Received: from [10.61.64.140] (ams3-vpn-dhcp140.cisco.com [10.61.64.140]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2JMNtZT024730; Mon, 19 Mar 2007 22:23:56 GMT Message-ID: <45FF0DB8.5010801@cisco.com> Date: Mon, 19 Mar 2007 15:24:56 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0pre (X11/20070224) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.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=2060; t=1174343037; x=1175207037; 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]=20VLAN=20Scoping=20/=20MAC=20Uniqueness |Sender:=20; bh=JAlWADRfCEyWf82+D/AhGu+c5zNb/F26oF2K8SE66mY=; b=zh7m51tmhkvbnEudPxue5kKqjdXarVvbTScdgvMW4YCITqY1IJR+pKnmjAaKFOux9Yxm93H9 jg7oshSW4oCNgxhMqQTtC4amOhh4wufey3ZBgoQzjeQJV1oUN10nRKhN; 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: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 19 Mar 2007 22:24:10 -0000 Status: RO Content-Length: 2015 Hi Caitlin, Caitlin Bestler wrote: > My understanding of 802.1 specifications is that the following sequence > is acceptable behavior for a bridge: > > 1) VLAN 7 MAC X is seen on port 1. > 2) Bridge learns that MAC X is on port 1 with VLAN 7. > 3) VLAN 8 MAC X is seen on port 1. > 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X). > I don't think it happens this way. 802.1d bridges map the Vlan ID into a separate filtering database ID called FID and learn the MAC addresses along with the FID, not the VID. In independent VLAN learning, FID == VID whereas in shared VLAN learning, multiple VIDs map into a single FID. Therefore in your example above, Bridge learns MAC X on port 1, FID z where z is the same for VLANs 7 & 8 or it learns MAC x, FID z1 and MAC x, FID z2 where Vlan 7 = FID z1 and Vlan 8 = FID z2. ARP/ND based learning is specific to TRILL and needs to decide its behavior. Silvano and I discuss this a bit in our presentation on Wed. Dinesh > This is of course undesirable, but a livable quirk. It is best avoided by either > ensuring that global MAC Addresses are truly unique, or ensuring that all bridges > deployed in one subnet agree on exactly how unique a "globally unique" address is. > > RBridges do more than merely forward ethernet frames amongst themselves, they collaborate > to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes > of the shared discovery data that MAC Addresses are assumed to be unique only as scoped > within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing > the scope of legal behaviors that would have been available to a bridge. > > > > _______________________________________________ > 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 MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JLoTXq007999 for <rbridge@postel.org>; Mon, 19 Mar 2007 14:50:29 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 19 Mar 2007 14:50:21 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C34362AF; Mon, 19 Mar 2007 14:50:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id AE4412AE; Mon, 19 Mar 2007 14:50:21 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBW42097; Mon, 19 Mar 2007 14:50:17 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 82CD569CA6; Mon, 19 Mar 2007 14:50:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Mar 2007 14:50:11 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DDDE9@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAMXCd8A= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 69E1DA1738G5738608-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2JLoTXq007999 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 19 Mar 2007 21:51:03 -0000 Status: RO Content-Length: 777 Silvano Gai wrote: > I think TRILL needs to do exactly what IEEE 802.1Q does. > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. > > N is never advertised outside the bridge, and the mapping of > M to N is never advertised outside the bridge. TRILL must do the same. > > Learning is done on {VID, MAC-address} pairs. TRILL must do the same. > My reading of Appendix B is that Shared Learning is allowed, where VID is not a key field (i.e, there is only one FID supported). Appendix B details some of the problems this creates. I believe the problems for RBridges are even greater than for simple Bridges. This probably justifies restricting RBridges to the Independent Learning model, but any such additional restriction should be explicitly stated. 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 l2JKB3h5009003 for <rbridge@postel.org>; Mon, 19 Mar 2007 13:11:04 -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, 19 Mar 2007 12:35:51 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013B4711@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <45FEDF30.6000608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness thread-index: AcdqXEcPIT0gM89hSN+SBmu0vD/NZgAAQbSQ References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com><45F6E21C.2060802@sun.com> <45FEDF30.6000608@cisco.com> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Russ White" <riw@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jrrivers@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2JKB3h5009003 Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 19 Mar 2007 20:11:43 -0000 Status: RO Content-Length: 4301 Seems like Radia's option B is a reasonable option. Just because an RBridge has directly connected hosts on VLAN A doesn't qualify it to understand what should (or shouldn't) be connected on VLAN B. There are many examples of locally assigned Ethernet addresses being used within a subnet. It doesn't seem like there is any fundamental requirement for TRILL to change this. Clearly... there needs to be a policy for handling the same address connected to different RBridges in the SAME VLAN. My $0.02, JR > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White > Sent: Monday, March 19, 2007 12:06 PM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > - From an IS-IS perspective, if we do a, we only have, I > think, a single > process, while if we do b, it makes more sense to do multiple > processes, > right? In reality, the way the TLVs are laid out today, we > can advertise > each l2 address with a vid, or not, or a group of l2 addresses with a > single vid to indicate they are all within this vid, or some other > various combinations. > > :-) > > Russ > > Radia Perlman wrote: > > Ah. Now I understand the issue, I think. You are saying that if MAC > > addresses are globally unique, > > an RBridge attached only to VLAN A should still monitor the endnode > > membership of the other VLANs, > > in case one of its endnodes moves and appears elsewhere. > > > > So I think we are talking about two alternatives: > > a) have all RBridges see all endnode memberships on all VLANs > > b) have RBridges only see endnode memberships for VLANs they are > > directly attached to. > > > > I see the disadvantages of each as: > > a) extra bandwidth and storage for having endnode > membership go everywhere > > b) less timely noticing an endnode has moved to another VLAN > > > > If I understand things correctly, I much prefer b), for the > following > > reasons: > > 1) option a offers an endnode in VLAN A the ability to > annoy VLAN B by > > pretending to be MAC addresses > > belonging to VLAN B (so option b is safer and provides > more separation > > between VLANs) > > 2) option b) greatly lowers the burden on RBridges because > they only > > have to keep information for > > their own VLANs > > 3) option b) is likely to save bandwidth on distributing > endnode information > > 4) there might be cases where an endnode might attach to > multiple VLANs, > > and the RBridges will > > panic unnecessarily > > > > Radia > > > > Caitlin Bestler wrote: > > > >> The issue is not how the information is relayed, or how it > is stored, > >> but who determines what information is relevant. > >> > >> If all RBridges track MAC Addresses scoped within a VLAN scope > >> then everything you suggest works perfectly fine. The only > correction > >> needed would be to emphasize that this is indeed a requirement. > >> > >> But any RBridge that uses a global scope for MAC Addresses should > >> be told of new MAC detections on different VLANs because such > >> an RBridge would want to delete the old location. > >> > >> Unless the RBridge that detected the MAC address knows that all > >> other RBridges are using VLAN scoped MAC addresses they should > >> distribute the new information to *all* RBRidges, not just those on > >> the VLAN where the address was discovered. > >> > >> > >> _______________________________________________ > >> 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 > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY > 6bS0r3gfLceCcCIUYXFR5HI= > =F2tF > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from xmail03.myhosting.com (xmail03.myhosting.com [168.144.250.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JJ7RRu020615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 19 Mar 2007 12:07:28 -0700 (PDT) Received: (qmail 21643 invoked from network); 19 Mar 2007 19:07:16 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender <riw@cisco.com>) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for <Radia.Perlman@sun.com>; 19 Mar 2007 19:07:16 -0000 Message-ID: <45FEDF30.6000608@cisco.com> Date: Mon, 19 Mar 2007 15:06:24 -0400 From: Russ White <riw@cisco.com> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6E21C.2060802@sun.com> In-Reply-To: <45F6E21C.2060802@sun.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 19 Mar 2007 19:08:01 -0000 Status: RO Content-Length: 3152 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From an IS-IS perspective, if we do a, we only have, I think, a single process, while if we do b, it makes more sense to do multiple processes, right? In reality, the way the TLVs are laid out today, we can advertise each l2 address with a vid, or not, or a group of l2 addresses with a single vid to indicate they are all within this vid, or some other various combinations. :-) Russ Radia Perlman wrote: > Ah. Now I understand the issue, I think. You are saying that if MAC > addresses are globally unique, > an RBridge attached only to VLAN A should still monitor the endnode > membership of the other VLANs, > in case one of its endnodes moves and appears elsewhere. > > So I think we are talking about two alternatives: > a) have all RBridges see all endnode memberships on all VLANs > b) have RBridges only see endnode memberships for VLANs they are > directly attached to. > > I see the disadvantages of each as: > a) extra bandwidth and storage for having endnode membership go everywhere > b) less timely noticing an endnode has moved to another VLAN > > If I understand things correctly, I much prefer b), for the following > reasons: > 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by > pretending to be MAC addresses > belonging to VLAN B (so option b is safer and provides more separation > between VLANs) > 2) option b) greatly lowers the burden on RBridges because they only > have to keep information for > their own VLANs > 3) option b) is likely to save bandwidth on distributing endnode information > 4) there might be cases where an endnode might attach to multiple VLANs, > and the RBridges will > panic unnecessarily > > Radia > > Caitlin Bestler wrote: > >> The issue is not how the information is relayed, or how it is stored, >> but who determines what information is relevant. >> >> If all RBridges track MAC Addresses scoped within a VLAN scope >> then everything you suggest works perfectly fine. The only correction >> needed would be to emphasize that this is indeed a requirement. >> >> But any RBridge that uses a global scope for MAC Addresses should >> be told of new MAC detections on different VLANs because such >> an RBridge would want to delete the old location. >> >> Unless the RBridge that detected the MAC address knows that all >> other RBridges are using VLAN scoped MAC addresses they should >> distribute the new information to *all* RBRidges, not just those on >> the VLAN where the address was discovered. >> >> >> _______________________________________________ >> 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 - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY 6bS0r3gfLceCcCIUYXFR5HI= =F2tF -----END PGP SIGNATURE----- Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2HJRajM003656 for <rbridge@postel.org>; Sat, 17 Mar 2007 12:27:36 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Sat, 17 Mar 2007 12:27:26 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E03E82AF; Sat, 17 Mar 2007 12:27:25 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CB5332AE; Sat, 17 Mar 2007 12:27:25 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBR37306; Sat, 17 Mar 2007 12:27:25 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 5D69F69CA3; Sat, 17 Mar 2007 12:27:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Mar 2007 12:27:23 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D031ECE13@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA20135A144@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAEC8S3wAEbNJYAAJxr3g From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 69E29E943A44830727-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2HJRajM003656 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 17 Mar 2007 19:28:00 -0000 Status: RO Content-Length: 400 Silvano Gai wrote: > Caitlin, > > Is you problem with: > 1) "Learning" or > 2) "ARP/ND discovery"? > > In my email I was only addressing 1), but I agree with you > that we also need to address 2). > Maybe I'm not playing spec lawyer well enough. But thinking of how I would implement these features in a smart NIC I simply don't see the distinction. It's all information keyed by the L2 Index. 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 l2HErbni008008 for <rbridge@postel.org>; Sat, 17 Mar 2007 07:53:37 -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: Sat, 17 Mar 2007 07:50:25 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20135A144@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness thread-index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAEC8S3wAEbNJYA== References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.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 l2HErbni008008 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 17 Mar 2007 14:53:50 -0000 Status: RO Content-Length: 2940 Caitlin, Is you problem with: 1) "Learning" or 2) "ARP/ND discovery"? In my email I was only addressing 1), but I agree with you that we also need to address 2). -- Silvano > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Friday, March 16, 2007 11:27 PM > To: Silvano Gai; Radia Perlman > Cc: rbridge@postel.org; Erik Nordmark > Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness > > > > > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Fri 3/16/2007 2:16 AM > To: Radia Perlman; Caitlin Bestler > Cc: rbridge@postel.org; Erik Nordmark > Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness > > > I think TRILL needs to do exactly what IEEE 802.1Q does. > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. > > N is never advertised outside the bridge, and the mapping of M to N is > never advertised outside the bridge. TRILL must do the same. > > Learning is done on {VID, MAC-address} pairs. TRILL must do the same. > > We agreed that bridges learn from data frames and data frames are always > associated to a VID and RBridges learn from the per VLAN instance of > ISIS. > > Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are > mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically > becomes available on VLAN=9. > > Now the tricky question: should the RBridge announce MAC-A on both VLAN > 7 and VLAN 9 or only on VLAN 7? > > IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e. > it must only announce what it has learnt from data frames, not the > internal associations it has made. If the information was learnt on data > packets, it would only be learnt on VLAN 7! > > If we do this we are perfectly equivalent to an IEEE 802.1Q bridge. > > -- Silvano > > -----End Original Message----- > > > My understanding of 802.1 specifications is that the following sequence > is acceptable behavior for a bridge: > > 1) VLAN 7 MAC X is seen on port 1. > 2) Bridge learns that MAC X is on port 1 with VLAN 7. > 3) VLAN 8 MAC X is seen on port 1. > 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior > information about X). > > This is of course undesirable, but a livable quirk. It is best avoided by > either > ensuring that global MAC Addresses are truly unique, or ensuring that all > bridges > deployed in one subnet agree on exactly how unique a "globally unique" > address is. > > RBridges do more than merely forward ethernet frames amongst themselves, > they collaborate > to implement a distributed ARP/ND proxy. That probably justifies stating > that for purposes > of the shared discovery data that MAC Addresses are assumed to be unique > only as scoped > within a VLAN, but I think we should acknowledge (and highlight) that we > are narrowing > the scope of legal behaviors that would have been available to a bridge. > Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2H6R16t025252 for <rbridge@postel.org>; Fri, 16 Mar 2007 23:27:02 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 16 Mar 2007 23:26:48 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2B8302B0; Fri, 16 Mar 2007 23:26:48 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 157222AF; Fri, 16 Mar 2007 23:26:48 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBQ33117; Fri, 16 Mar 2007 23:26:44 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9B60769CA4; Fri, 16 Mar 2007 23:26:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Mar 2007 23:26:44 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED46@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAEC8S3w= References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 69E555A23A44643839-01-01 Content-Type: text/plain; charset=iso-8859-1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2H6R16t025252 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 17 Mar 2007 06:28:47 -0000 Status: RO Content-Length: 2372 -----Original Message----- From: Silvano Gai [mailto:sgai@nuovasystems.com] Sent: Fri 3/16/2007 2:16 AM To: Radia Perlman; Caitlin Bestler Cc: rbridge@postel.org; Erik Nordmark Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness I think TRILL needs to do exactly what IEEE 802.1Q does. AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. N is never advertised outside the bridge, and the mapping of M to N is never advertised outside the bridge. TRILL must do the same. Learning is done on {VID, MAC-address} pairs. TRILL must do the same. We agreed that bridges learn from data frames and data frames are always associated to a VID and RBridges learn from the per VLAN instance of ISIS. Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically becomes available on VLAN=9. Now the tricky question: should the RBridge announce MAC-A on both VLAN 7 and VLAN 9 or only on VLAN 7? IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e. it must only announce what it has learnt from data frames, not the internal associations it has made. If the information was learnt on data packets, it would only be learnt on VLAN 7! If we do this we are perfectly equivalent to an IEEE 802.1Q bridge. -- Silvano -----End Original Message----- My understanding of 802.1 specifications is that the following sequence is acceptable behavior for a bridge: 1) VLAN 7 MAC X is seen on port 1. 2) Bridge learns that MAC X is on port 1 with VLAN 7. 3) VLAN 8 MAC X is seen on port 1. 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X). This is of course undesirable, but a livable quirk. It is best avoided by either ensuring that global MAC Addresses are truly unique, or ensuring that all bridges deployed in one subnet agree on exactly how unique a "globally unique" address is. RBridges do more than merely forward ethernet frames amongst themselves, they collaborate to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes of the shared discovery data that MAC Addresses are assumed to be unique only as scoped within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing the scope of legal behaviors that would have been available to a bridge. Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2GLr19q015062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Fri, 16 Mar 2007 14:53:01 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5A97C17697; Fri, 16 Mar 2007 21:52:56 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HSKM4-0001KO-4Q; Fri, 16 Mar 2007 17:52:56 -0400 X-test-idtracker: no To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Message-Id: <E1HSKM4-0001KO-4Q@stiedprstage1.ietf.org> Date: Fri, 16 Mar 2007 17:52:56 -0400 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ietf@ietf.org Cc: rbridge@postel.org Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ietf@ietf.org 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, 16 Mar 2007 21:53:19 -0000 Status: RO Content-Length: 828 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Routing Requirements in Support of RBridges ' <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0 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 l2G9GBEX002554 for <rbridge@postel.org>; Fri, 16 Mar 2007 02:16: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: Fri, 16 Mar 2007 02:16:11 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201359E14@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <45F6ECC3.5070509@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness thread-index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0g References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> <45F6ECC3.5070509@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.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 l2G9GBEX002554 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 16 Mar 2007 09:16:58 -0000 Status: RO Content-Length: 5007 I think TRILL needs to do exactly what IEEE 802.1Q does. AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N. N is never advertised outside the bridge, and the mapping of M to N is never advertised outside the bridge. TRILL must do the same. Learning is done on {VID, MAC-address} pairs. TRILL must do the same. We agreed that bridges learn from data frames and data frames are always associated to a VID and RBridges learn from the per VLAN instance of ISIS. Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically becomes available on VLAN=9. Now the tricky question: should the RBridge announce MAC-A on both VLAN 7 and VLAN 9 or only on VLAN 7? IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e. it must only announce what it has learnt from data frames, not the internal associations it has made. If the information was learnt on data packets, it would only be learnt on VLAN 7! If we do this we are perfectly equivalent to an IEEE 802.1Q bridge. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Tuesday, March 13, 2007 11:26 AM > To: Caitlin Bestler > Cc: rbridge@postel.org; Erik Nordmark > Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > > The current spec (and my understanding) is that membership of VLAN A > would be distributed > as link state information in IS-IS. If we include this in the link state > information in the core instance, > then every RBridge has to store it all, since IS-IS flooding requires > every RBridge to store all (the most > recently generated from each RBridge) link state information. R1 doesn't > just look at the link state > information and decide what it's interested in and delete the rest. R1 > has to keep it in order for > the reliable flooding to work. > > With the way the current spec is written, endnode information is *NOT* > distributed in the core instance. > Instead, VLAN A information > is distributed like a VLAN A multicast data packet, which means the core > RBridges distribute > it along a tree, filtered so as not to unnecessarily go on branches that > don't lead to VLAN A links. > > With that design, the only RBridges that would see information about > VLAN A endnode membership are > RBridges attached to VLAN A. > The topology that the IS-IS instance for distributing VLAN A sees is as > a single hop, with all RBridges > attached to VLAN A being neighbors. > > There is a variant of this design that would have the property you are > imagining; that all endnode information > goes everywhere, gets seen by all RBridges, and that only RBridges in > VLAN A have to actually store the > information. That is to have a multicast distribution tree that sends > things to *all* RBridges that attach to > endnodes. This is a subtly different distribution mechanism than the > core instance. If there are core RBridges, > not attached to any endnodes, they would just pass the link state > information along. And a "border" RBridge R2 > (one that does attach to endnodes) would be allowed, if it chose, to > simply scan VLAN A information and > then delete it, since R2 would never need to forward this link state > ifnormation to a neighbor. > > I still prefer the way the spec is now, since I think the advantage of > noticing endnodes moving to a > different VLAN is outweighed by the downsides (more cost to distribute > endnode information, and > the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN B > maliciously, and confusion > when nonmaliciously an endnode resides on multiple VLANs with the same > MAC address. > > Radia > > > > Caitlin Bestler wrote: > > >Radia Perlman wrote: > > > > > >>With IS-IS flooding, an RBridge can't simply scan the > >>information for VLAN A and then delete it. > >>It has to store it, since LSPs have to be flooded reliably, > >>so each RBridge would have to keep all endnode information for all > >>VLANs. > >> > >> > >> > > > >I'm not following. If an RBridge is using globally scoped MAC > >addresses, and it receives endnode information for a VLAN that > >it does not support, the only thing I can see that it would have > >to do is to delete any information it had on the same MAC address > >on a different VLAN. > > > >It would never send to VLAN A, so why would it retain any information > >once the contradictory data was eliminated? A deleted record can be > >considered to be reliably delected, can't it? > > > >If it's knowledge of MAC Addresses is VLAN scoped then nothing > >about VLAN A is ever relevant. That is why it is a very simple > >solution, but one that creates an RBridge requirement for scoped > >learning that does not apply to simple Bridges. > > > > > > > > _______________________________________________ > 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 l2G9GF3g002555 for <rbridge@postel.org>; Fri, 16 Mar 2007 02:16:15 -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, 16 Mar 2007 02:16:15 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201359E15@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <45F1F4B2.5040500@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees thread-index: Acdipub/syq9ju5TR6CBdJCJFyW4/QE8Le8g References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> <45F1E1C6.7060905@sun.com> <EE4ECD02-103F-4352-8D9E-03DBC55D4D91@cisco.com> <45F1F4B2.5040500@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Dino Farinacci" <dino@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 l2G9GF3g002555 Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 16 Mar 2007 09:16:54 -0000 Status: RO Content-Length: 2714 EriK, inline > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Friday, March 09, 2007 3:59 PM > To: Dino Farinacci > Cc: Silvano Gai; rbridge@postel.org; Radia.Perlman@sun.com > Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge > trees > > Dino Farinacci wrote: > > > The simplest example is when using multi-access links. The fact that > > some switches use the multi-access link as an oif and others use the > > link as an expected-incoming interface. > > > > So if the ones that are using the multi-access link as an oif happen to > > join the root through one of the other switches (which can be many hops > > away), then the multicast forwarding (and replication) loop occurs. > > With TRILL be clearly have to be careful at the edge (the ingress and > egress rbridges) when it comes to the relationship between 802.1D and > designated RBridge in order to handle topology changes. In particular > since the frames without the TRILL header header doesn't have a TTL. > > But leaving that aside for a moment, the way Radia described the > forwarding check (the "expected incoming adjacency" check), the transit > paths between the RBridges would act as point-to-point due to checking > both the incoming port and the previous hop RBridge. IMHO you can build the most sophisticated RPF check, but it will always be based on local information. Since it is well known that the local information of two RBridges may be temporary out of sync, due to the way IS-IS works, the possibility of a temporary loop is concrete. Temporary loop == Broadcast Storm -- Silvano > > It was in such a pt-pt topology that I tried to find a simple example of > a temporary loop. > > >> Have you observed temporary IP Multicast loops? (apart from the PIM SM > >> ones before ASSERTS where added). What was the topology and change > >> necessary to trigger those? > > > > Oh definitely, when two routers think the RP for a (*,G) are different. > > And this can happen when the topology is in steady state. > > > > And this happens due to misconfiguration or in the early days of PIM > > when you detect one RP down, you move to another one, but others in the > > topology stayed with the original one. Again, in a steady-state > > topology. The reason some thought the RP went down is because the > > network was congested and the RP keepalives were all lost. Those were > > interesting times. ;-) > > > > So this can happen in IS-IS as well if the not everyone is using the > > same roots. > > But AFAICT that type of loop can't happen in TRILL since we have an > explicit designator for the tree to use in every multi-destination data > frame. > > Erik Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DJ7Nqb012138 for <rbridge@postel.org>; Tue, 13 Mar 2007 12:07:23 -0700 (PDT) Received: by nz-out-0506.google.com with SMTP id i1so1246528nzh for <rbridge@postel.org>; Tue, 13 Mar 2007 12:07:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Jsa262CYA23cTU6XtiMzE/xQZ63l7iTLfQYAtyXDNzpetAsMnaQu7/iqYHU+Y9DcoGEEyBisgCS5NGhcegGSaB1FdwwitlOkbqSc8xtiKS4eM6Cw6xYE2gB2OR/NkS6bUp9BhYEBdN0nl5XPkCE/ZSFsYWMsvU1mOEk1d8yjNlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fDkvBuVkdp3j8sCqzNyYXAifjFrX1HPwkMeu6qW7QuAblRjVMCuMlfraUoRujVtNZtZ4MyJNxPy9jC7O7AWJkJUHH4a7IqdumAwwT2nmlnY2PJIBkMBe+qAc7l0cfRRCaKhZ4pDqYqEQisa/QYHj6gehSz+s0izTn/qtTXvS2NE= Received: by 10.35.103.12 with SMTP id f12mr2436900pym.1173812840435; Tue, 13 Mar 2007 12:07:20 -0700 (PDT) Received: by 10.35.51.15 with HTTP; Tue, 13 Mar 2007 12:07:20 -0700 (PDT) Message-ID: <94dba4110703131207j5ea3c94aiebaa564ce970df13@mail.gmail.com> Date: Tue, 13 Mar 2007 20:07:20 +0100 From: "Jose Morales Barroso" <uets.jmb@gmail.com> To: rbridge@postel.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: uets.jmb@gmail.com Subject: Re: [rbridge] Global MAC Addresses X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: jmb@ieee.org 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, 13 Mar 2007 19:07:35 -0000 Status: RO Content-Length: 1924 Dear colleagues: UETS/EFR architecture uses locally administered (U/L bit = 1) MAC addresses, "taking advantage of interface identifiers with universal scope", as described at: http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf This technology permits to switch Ethernet frames at the physical layer, making it unnecessary to use routing, bridging, or signaling techniques. The Destination Address has the path information, and does not need tables of switching, look-up or forwarding: http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf Using MAC-in-MAC or SNAP, each connection support another Ethernet domain. In this case, the addressing will be huge, even bigger than IPv6, making possible to build a "Global Ethernet". You have more information in the UETS/EFR page: http://www.lmdata.es/uets.htm Jose Morales jmb@ieee.org Eric Gray (LO/EUS) wrote: >> Interstingly enough, I am really sure that the IPv6 folks >> have looked at this before. And I am also sure that at least one >> suggested solution has been considered. I do not know if any (of >> possibly many) proposals were actually adopted but, if none were, >> it would be because the IPv6 people did not see this as a problem. > >AFAIK the IPv6 folks have not considered this. >But as you pointed out, the global IPv6 addresses would still be >globally unique since they would have different subnet prefixes. > > The only issue for IPv6 is that this (and host-side virtualization in > general) means that the the semantics of the universal bit in the > modified EUI-64 format is even weaker than before. > But there is no protocol to date which assumes anything about the > semantics of this bit. As RFC 4291 says: > The use of the universal/local bit in the Modified EUI-64 format > identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope. > Erik Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DIaw5Z002449 for <rbridge@postel.org>; Tue, 13 Mar 2007 11:36:59 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 11:36:49 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 201A32AF; Tue, 13 Mar 2007 11:36:49 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0BA942AE; Tue, 13 Mar 2007 11:36:49 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBG66630; Tue, 13 Mar 2007 11:36:48 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id A590869CA3; Tue, 13 Mar 2007 11:36:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Mar 2007 11:36:47 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D031EC0E5@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <45F6ECC3.5070509@sun.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: AcdlnRUS2fyq52ipR+ezpClQrmB6BAAADcSw From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 69E830CB38G3408583-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2DIaw5Z002449 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 18:37:18 -0000 Status: RO Content-Length: 2860 Radia Perlman wrote: > The current spec (and my understanding) is that membership of > VLAN A would be distributed as link state information in > IS-IS. If we include this in the link state information in > the core instance, then every RBridge has to store it all, > since IS-IS flooding requires every RBridge to store all (the > most recently generated from each RBridge) link state > information. R1 doesn't just look at the link state > information and decide what it's interested in and delete the > rest. R1 has to keep it in order for the reliable flooding to work. > > With the way the current spec is written, endnode information > is *NOT* distributed in the core instance. > Instead, VLAN A information > is distributed like a VLAN A multicast data packet, which > means the core RBridges distribute it along a tree, filtered > so as not to unnecessarily go on branches that don't lead to > VLAN A links. > > With that design, the only RBridges that would see > information about VLAN A endnode membership are RBridges > attached to VLAN A. > The topology that the IS-IS instance for distributing VLAN A > sees is as a single hop, with all RBridges attached to VLAN A being > neighbors. > > There is a variant of this design that would have the > property you are imagining; that all endnode information goes > everywhere, gets seen by all RBridges, and that only RBridges > in VLAN A have to actually store the information. That is to > have a multicast distribution tree that sends things to *all* > RBridges that attach to endnodes. This is a subtly different > distribution mechanism than the core instance. If there are > core RBridges, not attached to any endnodes, they would just > pass the link state information along. And a "border" RBridge > R2 (one that does attach to endnodes) would be allowed, if it > chose, to simply scan VLAN A information and then delete it, > since R2 would never need to forward this link state > ifnormation to a neighbor. > > I still prefer the way the spec is now, since I think the > advantage of noticing endnodes moving to a different VLAN is > outweighed by the downsides (more cost to distribute endnode > information, and the ability for nasty behavior of an endnode > in VLAN A to disrupt VLAN B maliciously, and confusion when > nonmaliciously an endnode resides on multiple VLANs with the > same MAC address. > > Radia > It might be sufficient to merely note that any RBridge attempting to maintain global scoping of MAC Addresses needs to be aware that the distribution of endnode information is optimized for per-VLAN scoping. Because of this it MUST NOT rely on prompt notification of migration of a MAC Address to a new VLAN on a different RBridge. I also agree that it makes sense to optimize the wire protocol on the assumption that typical RBridges will do per-VLAN learning. 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 l2DIQ1H2029228 for <rbridge@postel.org>; Tue, 13 Mar 2007 11:26:01 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEU000N5TVDHJ10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 13 Mar 2007 11:26:01 -0700 (PDT) Received: from sun.com ([129.150.17.61]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEU000M9TVCQV20@mail.sunlabs.com> for rbridge@postel.org; Tue, 13 Mar 2007 11:26:01 -0700 (PDT) Date: Tue, 13 Mar 2007 11:26:11 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <45F6ECC3.5070509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 18:26:41 -0000 Status: RO Content-Length: 3328 The current spec (and my understanding) is that membership of VLAN A would be distributed as link state information in IS-IS. If we include this in the link state information in the core instance, then every RBridge has to store it all, since IS-IS flooding requires every RBridge to store all (the most recently generated from each RBridge) link state information. R1 doesn't just look at the link state information and decide what it's interested in and delete the rest. R1 has to keep it in order for the reliable flooding to work. With the way the current spec is written, endnode information is *NOT* distributed in the core instance. Instead, VLAN A information is distributed like a VLAN A multicast data packet, which means the core RBridges distribute it along a tree, filtered so as not to unnecessarily go on branches that don't lead to VLAN A links. With that design, the only RBridges that would see information about VLAN A endnode membership are RBridges attached to VLAN A. The topology that the IS-IS instance for distributing VLAN A sees is as a single hop, with all RBridges attached to VLAN A being neighbors. There is a variant of this design that would have the property you are imagining; that all endnode information goes everywhere, gets seen by all RBridges, and that only RBridges in VLAN A have to actually store the information. That is to have a multicast distribution tree that sends things to *all* RBridges that attach to endnodes. This is a subtly different distribution mechanism than the core instance. If there are core RBridges, not attached to any endnodes, they would just pass the link state information along. And a "border" RBridge R2 (one that does attach to endnodes) would be allowed, if it chose, to simply scan VLAN A information and then delete it, since R2 would never need to forward this link state ifnormation to a neighbor. I still prefer the way the spec is now, since I think the advantage of noticing endnodes moving to a different VLAN is outweighed by the downsides (more cost to distribute endnode information, and the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN B maliciously, and confusion when nonmaliciously an endnode resides on multiple VLANs with the same MAC address. Radia Caitlin Bestler wrote: >Radia Perlman wrote: > > >>With IS-IS flooding, an RBridge can't simply scan the >>information for VLAN A and then delete it. >>It has to store it, since LSPs have to be flooded reliably, >>so each RBridge would have to keep all endnode information for all >>VLANs. >> >> >> > >I'm not following. If an RBridge is using globally scoped MAC >addresses, and it receives endnode information for a VLAN that >it does not support, the only thing I can see that it would have >to do is to delete any information it had on the same MAC address >on a different VLAN. > >It would never send to VLAN A, so why would it retain any information >once the contradictory data was eliminated? A deleted record can be >considered to be reliably delected, can't it? > >If it's knowledge of MAC Addresses is VLAN scoped then nothing >about VLAN A is ever relevant. That is why it is a very simple >solution, but one that creates an RBridge requirement for scoped >learning that does not apply to simple Bridges. > > > Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DHxqWI020724 for <rbridge@postel.org>; Tue, 13 Mar 2007 10:59:53 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 10:59:41 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 20ED52B0; Tue, 13 Mar 2007 10:59:41 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0CB2A2AF; Tue, 13 Mar 2007 10:59:41 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBG55493; Tue, 13 Mar 2007 10:59:40 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 445D469CA3; Tue, 13 Mar 2007 10:59:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Mar 2007 10:59:38 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D031EC08E@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <45F6E567.10006@sun.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: AcdlmLV46rixuFdCT4OMcSimkHFYIgAAB64g From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 69E839073703311508-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2DHxqWI020724 Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 18:00:06 -0000 Status: RO Content-Length: 971 Radia Perlman wrote: > With IS-IS flooding, an RBridge can't simply scan the > information for VLAN A and then delete it. > It has to store it, since LSPs have to be flooded reliably, > so each RBridge would have to keep all endnode information for all > VLANs. > I'm not following. If an RBridge is using globally scoped MAC addresses, and it receives endnode information for a VLAN that it does not support, the only thing I can see that it would have to do is to delete any information it had on the same MAC address on a different VLAN. It would never send to VLAN A, so why would it retain any information once the contradictory data was eliminated? A deleted record can be considered to be reliably delected, can't it? If it's knowledge of MAC Addresses is VLAN scoped then nothing about VLAN A is ever relevant. That is why it is a very simple solution, but one that creates an RBridge requirement for scoped learning that does not apply to simple Bridges. 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 l2DHsbIR019230 for <rbridge@postel.org>; Tue, 13 Mar 2007 10:54:37 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEU000LJSF1HJ10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 13 Mar 2007 10:54:37 -0700 (PDT) Received: from sun.com ([129.150.17.61]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEU000I5SF0QV20@mail.sunlabs.com> for rbridge@postel.org; Tue, 13 Mar 2007 10:54:36 -0700 (PDT) Date: Tue, 13 Mar 2007 10:54:47 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D030EAABD@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <45F6E567.10006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1EF1E44200D82B47BD5BA61171E8CE9D030EAABD@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org, Erik Nordmark <erik.nordmark@Sun.COM> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 17:55:33 -0000 Status: RO Content-Length: 1064 With IS-IS flooding, an RBridge can't simply scan the information for VLAN A and then delete it. It has to store it, since LSPs have to be flooded reliably, so each RBridge would have to keep all endnode information for all VLANs. Radia Caitlin Bestler wrote: >Radia Perlman wrote: > > > >>The advantage of this is that flooding of endnode information >>for VLAN A need not be stored by any RBridges except those >>that attach to VLAN A. >> >> > >That line leapt out at me on re-read. > >*If* we are going to allow RBridges to have the traditional >bridge option of using scoped or global MAC address learning, >then we do indeed have to flood endnode information about >VLAN A. This is not so that RBridges that are not part of >VLAN A can *store* the new endnode information, it is so >they can *delete* contradictory information. > >Alternatively, if we explicitly require scoped learning, >then any RBridge that is not part of VLAN A cannot have >contradictory information. Then there would be no need >to flood endnode advertisements. > > > > 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 l2DHem5c015049 for <rbridge@postel.org>; Tue, 13 Mar 2007 10:40:48 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEU000KURRLHJ10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 13 Mar 2007 10:40:33 -0700 (PDT) Received: from sun.com ([129.150.17.61]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEU000GMRRLQV20@mail.sunlabs.com> for rbridge@postel.org; Tue, 13 Mar 2007 10:40:33 -0700 (PDT) Date: Tue, 13 Mar 2007 10:40:44 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <45F6E21C.2060802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 17:41:35 -0000 Status: RO Content-Length: 2147 Ah. Now I understand the issue, I think. You are saying that if MAC addresses are globally unique, an RBridge attached only to VLAN A should still monitor the endnode membership of the other VLANs, in case one of its endnodes moves and appears elsewhere. So I think we are talking about two alternatives: a) have all RBridges see all endnode memberships on all VLANs b) have RBridges only see endnode memberships for VLANs they are directly attached to. I see the disadvantages of each as: a) extra bandwidth and storage for having endnode membership go everywhere b) less timely noticing an endnode has moved to another VLAN If I understand things correctly, I much prefer b), for the following reasons: 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by pretending to be MAC addresses belonging to VLAN B (so option b is safer and provides more separation between VLANs) 2) option b) greatly lowers the burden on RBridges because they only have to keep information for their own VLANs 3) option b) is likely to save bandwidth on distributing endnode information 4) there might be cases where an endnode might attach to multiple VLANs, and the RBridges will panic unnecessarily Radia Caitlin Bestler wrote: >The issue is not how the information is relayed, or how it is stored, >but who determines what information is relevant. > >If all RBridges track MAC Addresses scoped within a VLAN scope >then everything you suggest works perfectly fine. The only correction >needed would be to emphasize that this is indeed a requirement. > >But any RBridge that uses a global scope for MAC Addresses should >be told of new MAC detections on different VLANs because such >an RBridge would want to delete the old location. > >Unless the RBridge that detected the MAC address knows that all >other RBridges are using VLAN scoped MAC addresses they should >distribute the new information to *all* RBRidges, not just those on >the VLAN where the address was discovered. > > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DHbLX1014368 for <rbridge@postel.org>; Tue, 13 Mar 2007 10:37:21 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 10:37:12 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0320C2AF; Tue, 13 Mar 2007 10:37:12 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id E343E2AE; Tue, 13 Mar 2007 10:37:11 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBG48751; Tue, 13 Mar 2007 10:37:11 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 7B1FC69CA4; Tue, 13 Mar 2007 10:37:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Mar 2007 10:37:09 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EAABD@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <45F5D900.9070909@sun.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: Acdk+LVrBIIH880YR26Db9fsV9Es6AAnO53Q From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Erik Nordmark" <erik.nordmark@sun.com> X-WSS-ID: 69E83EC238G3384691-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2DHbLX1014368 Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 17:37:42 -0000 Status: RO Content-Length: 759 Radia Perlman wrote: > The advantage of this is that flooding of endnode information > for VLAN A need not be stored by any RBridges except those > that attach to VLAN A. That line leapt out at me on re-read. *If* we are going to allow RBridges to have the traditional bridge option of using scoped or global MAC address learning, then we do indeed have to flood endnode information about VLAN A. This is not so that RBridges that are not part of VLAN A can *store* the new endnode information, it is so they can *delete* contradictory information. Alternatively, if we explicitly require scoped learning, then any RBridge that is not part of VLAN A cannot have contradictory information. Then there would be no need to flood endnode advertisements. Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DEOGu8019801 for <rbridge@postel.org>; Tue, 13 Mar 2007 07:24:16 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 07:23:55 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BCFA72AF; Tue, 13 Mar 2007 07:23:55 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id AA0DC2AE for <rbridge@postel.org>; Tue, 13 Mar 2007 07:23:55 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBF87896; Tue, 13 Mar 2007 07:23:55 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 5354069CA3 for <rbridge@postel.org>; Tue, 13 Mar 2007 07:23:55 -0700 ( PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Mar 2007 07:23:55 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0306ED45@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: AcdlezsOxEEaK+OlRIOYX1kZQWtosA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: rbridge@postel.org X-WSS-ID: 69E86C713703221989-01-01 Content-Type: text/plain; charset=iso-8859-1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2DEOGu8019801 Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 14:24:25 -0000 Status: RO Content-Length: 737 The issue is not how the information is relayed, or how it is stored, but who determines what information is relevant. If all RBridges track MAC Addresses scoped within a VLAN scope then everything you suggest works perfectly fine. The only correction needed would be to emphasize that this is indeed a requirement. But any RBridge that uses a global scope for MAC Addresses should be told of new MAC detections on different VLANs because such an RBridge would want to delete the old location. Unless the RBridge that detected the MAC address knows that all other RBridges are using VLAN scoped MAC addresses they should distribute the new information to *all* RBRidges, not just those on the VLAN where the address was discovered. Received: from correo12.acens.net (correo12.acens.net [217.116.0.112]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2D9NhLw001534 for <rbridge@postel.org>; Tue, 13 Mar 2007 02:23:44 -0700 (PDT) Received: (qmail 10799 invoked from network); 13 Mar 2007 09:23:36 -0000 Received: from unknown (HELO [10.0.0.41]) (jmb.lmdata.es@[213.98.12.218]) (envelope-sender <jmb@lmdata.es>) by correo12.acens.net (qmail-ldap-1.03) with SMTP for <erik.nordmark@sun.com>; 13 Mar 2007 09:23:36 -0000 Message-ID: <45F66D97.1020808@lmdata.es> Date: Tue, 13 Mar 2007 10:23:35 +0100 From: Jose Morales Barroso <jmb@lmdata.es> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: erik.nordmark@sun.com, eric.gray@ericsson.com Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jmb@lmdata.es Cc: rbridge@postel.org Subject: Re: [rbridge] Global MAC Addresses 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, 13 Mar 2007 09:24:27 -0000 Status: RO Content-Length: 3107 <!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"> Dear colleagues:<br> <br> UETS/EFR architecture uses locally administered MAC addresses (U/L bit = 1), <br> as you can see at:<br> <br> <a class="moz-txt-link-freetext" href="http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf">http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf</a><br> <br> This technology permits to switch Ethernet frames directly at the physical layer, <br> making it unnecessary to use routing, bridging, or signaling techniques. <br> The Destination Address has the routing information, and does not need tables<br> of switching, look-up or forwarding, as described in:<br> <br> <a class="moz-txt-link-freetext" href="http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf">http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf</a><br> <br> <br> Using MAC-in-MAC or SNAP, each connection will support another Ethernet domain.<br> In this case, the addressing will be huge, even bigger than IPv6, making possible<br> to build a "Global Ethernet".<br> <br> Jose Morales<br> <br> <br> <blockquote type="cite"> <div class="moz-text-plain" wrap="true" graphical-quote="true" style="font-size: 12px;" lang="x-western"> <pre wrap="">Eric Gray (LO/EUS) wrote: </pre> <blockquote type="cite"> <pre wrap=""><span class="moz-txt-citetags">> </span> Interstingly enough, I am really sure that the IPv6 folks <span class="moz-txt-citetags">> </span>have looked at this before. And I am also sure that at least one <span class="moz-txt-citetags">> </span>suggested solution has been considered. I do not know if any (of <span class="moz-txt-citetags">> </span>possibly many) proposals were actually adopted but, if none were, <span class="moz-txt-citetags">> </span>it would be because the IPv6 people did not see this as a problem. </pre> </blockquote> <pre wrap=""><!----> AFAIK the IPv6 folks have not considered this. But as you pointed out, the global IPv6 addresses would still be globally unique since they would have different subnet prefixes. The only issue for IPv6 is that this (and host-side virtualization in general) means that the the semantics of the universal bit in the modified EUI-64 format is even weaker than before. But there is no protocol to date which assumes anything about the semantics of this bit. As RFC 4291 says: The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope. Erik _______________________________________________ rbridge mailing list <a class="moz-txt-link-abbreviated" href="mailto:rbridge@postel.org">rbridge@postel.org</a> <a class="moz-txt-link-freetext" href="http://mailman.postel.org/mailman/listinfo/rbridge">http://mailman.postel.org/mailman/listinfo/rbridge</a> </pre> </div> </blockquote> </body> </html> 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 l2D1ZLjn011251 for <rbridge@postel.org>; Mon, 12 Mar 2007 18:35:21 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JET000OHJ2XHJ00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 12 Mar 2007 18:35:21 -0700 (PDT) Received: from sun.com ([129.150.17.226]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JET0008NJ2WQV10@mail.sunlabs.com> for rbridge@postel.org; Mon, 12 Mar 2007 18:35:21 -0700 (PDT) Date: Mon, 12 Mar 2007 18:35:32 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D030EA836@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <45F5FFE4.7080600@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1EF1E44200D82B47BD5BA61171E8CE9D030EA836@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 13 Mar 2007 01:35:34 -0000 Status: RO Content-Length: 2563 I'm not sure I understand what you're saying. But I think the issue is how link state information is distributed. The core instance link state information is flooded to all RBridges, but transmitted hop by hop. That means every RBridge, including core RBridges that do not attach to any VLANs, have to store this information, in addition to forwarding it, in case it needs to be retransmitted to a neighbor, or transmitted to a new neighbor that might come up later. As the spec currently is, the endnode information is multicast. So R1, attached to VLAN A, just multicasts a single copy of its VLAN A information, and it gets distributed by the core like any VLAN A multicast data packet. It magically gets received just by RBridges attached to VLAN A. Only RBridges actually attached to VLAN A need to store this information. It is not sent reliably neighbor-to-neighbor. Only R1 has to ensure that all the relevant RBridges have received the link state information about VLAN A. THe intervening RBridges just forward it and forget it. So as I said, you could get rid of running the per-instance IS-IS hellos, by just listing, in the core instance LSP, which VLANs you attach to. There really isn't anything that the per-VLAN instance of the hello protocol needs to know that isn't already in the core instance link state information, so we could eliminate running 4000 Hello and Designated RBridge elections. However, the per-VLAN link state information (listing the endnodes) is potentially large enough that I believe it is useful to avoid having non-VLAN-A RBridges keep track of the VLAN A endnodes (and VLAN A IP groups and multicast routers). And if we are using multicast to distribute, I don't see how R1 can choose which RBridges to send the information to, or to format it differently depending on the recipient. For as many as possible of these sorts of things that are OK to do either this way or that way, I think we should choose, rather than making it a parameter. Radia Caitlin Bestler wrote: >One suggestion that I think is adequate: > >RBridge Hello messages would be from the core instance >and sent to core instance. It would list the VLAN IDs >and whether it maintained a single destination database >or a per VLAN database. > >In the latter case, other RBridges would only forward >relevant advertisements to RBridges that advertised the >relevant VLAN. An RBridge using an unscoped database >would be send all address advertisements. > >Alternately, we could explicitly require per VLAN scoping. > > > > > Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2CN0rN7003701 for <rbridge@postel.org>; Mon, 12 Mar 2007 16:00:53 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 12 Mar 2007 16:00:39 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9C3D02AF; Mon, 12 Mar 2007 16:00:39 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 886102AE; Mon, 12 Mar 2007 16:00:39 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBE00120; Mon, 12 Mar 2007 16:00:39 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id DC12A69CE6; Mon, 12 Mar 2007 16:00:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Mar 2007 16:00:25 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EA836@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <45F5D900.9070909@sun.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: Acdk+LVrBIIH880YR26Db9fsV9Es6AAAOS4A From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Erik Nordmark" <erik.nordmark@sun.com> X-WSS-ID: 69EB041D3A42807922-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2CN0rN7003701 Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 12 Mar 2007 23:01:26 -0000 Status: RO Content-Length: 501 One suggestion that I think is adequate: RBridge Hello messages would be from the core instance and sent to core instance. It would list the VLAN IDs and whether it maintained a single destination database or a per VLAN database. In the latter case, other RBridges would only forward relevant advertisements to RBridges that advertised the relevant VLAN. An RBridge using an unscoped database would be send all address advertisements. Alternately, we could explicitly require per VLAN scoping. 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 l2CMnQ7w000814 for <rbridge@postel.org>; Mon, 12 Mar 2007 15:49:26 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JET000FVBEEHJ00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 12 Mar 2007 15:49:26 -0700 (PDT) Received: from sun.com ([129.150.17.226]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JET000TOBEDQV00@mail.sunlabs.com> for rbridge@postel.org; Mon, 12 Mar 2007 15:49:26 -0700 (PDT) Date: Mon, 12 Mar 2007 15:49:36 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <45F5C9B3.4010602@sun.com> To: Erik Nordmark <erik.nordmark@sun.com> Message-id: <45F5D900.9070909@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <2f2a7526340.45f33e5a@sunlabs.com> <45F5C9B3.4010602@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 12 Mar 2007 22:50:06 -0000 Status: RO Content-Length: 3087 Yes. There are three ways of sending per-VLAN endnode information: a) a single instance of IS-IS for both "core" information and "endnode" information. Endnode information would be marked as (VLAN ID, {set of endnodes}). RBridges that are not in VLAN A would need to store the VLAN A endnode information, and all endnode information would go to all parts of the campus b) two instances of IS-IS: one for core information (which RBridges are connected to which other RBridges, and which VLANs are attached to which RBridges), and one for endnode information. Not sure what advantage/disadvantage this has over a), since all link state information would go to all RBridges. c) n+1 instance of IS-IS, where n is the number of VLANs that are in use. Each RBridge R1 would run k+1 instances of IS-IS; the core instance, and one for each of the k VLANs that R1 is attached to. The advantage of this is that flooding of endnode information for VLAN A need not be stored by any RBridges except those that attach to VLAN A. Also, because the core instance enables flooding of VLAN multicast just to links that are interested (RBridges that are attached to VLAN A), there is further optimization because this information does not need to traverse all the links in the campus; just those needed to get the packet from the RBridge that originates the LSP for VLAN A endnode information to the RBridges that attach to VLAN A. I prefer c). I don't think there is that much overhead to running n instances. It's really like separating the endnode information into distinct LSPs. Except for...the Hello Protocol. If all RBridges are connected to 4000 VLANs, then they'd all be sending 4000 Hellos, one for each instance. The core instance Hellos are a bit different -- they only go to direct neighbors. But the VLAN instances get flooded by the core to all links throughout the campus attached to that VLAN. We could eliminate the hello protocol for the per-VLAN instance of IS-IS, since there's enough information in the core instance for all VLAN A RBridges to know about each other and decide which should be Designated (for sending out CSNPs). Radia Erik Nordmark wrote: > Radia.Perlman@sun.com wrote: > >> I don't agree that we have to explicitly advertise which VLAN a MAC >> address belongs to, because >> each VLAN runs its own instance of IS-IS in which endnodes are >> announced. This could be looked >> at as implicitly advertising the VLAN. In other words, the endnode >> information is announced in >> an instance of IS-IS distinguished by having an inner VLAN tag (I >> think that's how we differentiate it). >> Core RBridges forward it like a multicast packet for that VLAN. Only >> border RBridges of that VLAN actually >> store the information. > > > That is true if you are required to have N IS-IS VLAN instances when > there are N VLANs in use. > > I don't know if that is overkill when all the RBridges are all part of > all N VLANs - basically when it is just different subsets of > stations/hosts that make up the different VLANs. > > Erik 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 l2CLiVfl015053 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Mon, 12 Mar 2007 14:44:31 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.56.144]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2CLiQje017513; Mon, 12 Mar 2007 21:44:30 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2CLiJSX616878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2007 14:44:20 -0700 (PDT) Message-ID: <45F5C9B3.4010602@sun.com> Date: Mon, 12 Mar 2007 14:44:19 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Radia.Perlman@sun.com References: <2f2a7526340.45f33e5a@sunlabs.com> In-Reply-To: <2f2a7526340.45f33e5a@sunlabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 12 Mar 2007 21:45:00 -0000 Status: RO Content-Length: 853 Radia.Perlman@sun.com wrote: > I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because > each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked > at as implicitly advertising the VLAN. In other words, the endnode information is announced in > an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it). > Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually > store the information. That is true if you are required to have N IS-IS VLAN instances when there are N VLANs in use. I don't know if that is overkill when all the RBridges are all part of all N VLANs - basically when it is just different subsets of stations/hosts that make up the different VLANs. Erik Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2C1PiFw011801 for <rbridge@postel.org>; Sun, 11 Mar 2007 18:25:45 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Sun, 11 Mar 2007 18:25:35 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CB2202B0; Sun, 11 Mar 2007 18:25:35 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B3E3D2AF; Sun, 11 Mar 2007 18:25:35 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FAV79499; Sun, 11 Mar 2007 17:25:35 -0800 (PST) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id E456F69CA3; Sun, 11 Mar 2007 18:25:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 Mar 2007 18:25:32 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EA534@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <2f2a7526340.45f33e5a@sunlabs.com> Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness Thread-Index: AcdjrnJMrZRHmmgsQWqSEGjRcof4hgAk/ztg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: Radia.Perlman@sun.com, "Erik Nordmark" <erik.nordmark@sun.com> X-WSS-ID: 69EA738538G2547193-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l2C1PiFw011801 Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 12 Mar 2007 01:27:02 -0000 Status: RO Content-Length: 2413 Radia.Perlman@sun.com wrote: > I don't agree that we have to explicitly advertise which VLAN > a MAC address belongs to, because each VLAN runs its own > instance of IS-IS in which endnodes are announced. This could > be looked at as implicitly advertising the VLAN. In other > words, the endnode information is announced in an instance of > IS-IS distinguished by having an inner VLAN tag (I think > that's how we differentiate it). > Core RBridges forward it like a multicast packet for that > VLAN. Only border RBridges of that VLAN actually store the > information. > > Radia > VLAN tagging the endnode announcement assumes that the announcement is only relevant within the VLAN. That still leaves the following scenario: RBridge I participates in VLANs R and S. It uses a single (VLAN independent) MAC learning database. It believes the MAC X is on a local port for VLAN R. RBridge J participates in VLANs S and T. It uses a single (VLAN independent) MAC learning database. RBridge K participates in VLAN T It detects MAC X on a local port for VLAN T. It would share that information with RBridge J, but not RBridge I. RBRidge J can now receive contradictory information from I and K. This is avoided if RBridge K does not presume which RBridges need this informaton, or if RBridge I advertises itself as wanting information for all VLANs (that is, it is a member of VLAN T, but only for purposes of getting endnode announcements). As for the more general problem, obviously any CRED which has varying concepts on the scope over which a MAC address is unique is going to have potential problems. But most of that problem is well outside of TRILL's scope. The issue that is within TRILL's scope is ensuring that endnode announcements are distributed everywhere that the information is needed. The prior drafts explicitly assumed that information about MAC Address X was not relevant to any RBridge that was not in the same VLAN. This is only a valid assumption if port learning is being done on a per VLAN basis. The current drafts do not have this problem, because they merely state that distribution might be limited based upon VLAN (which would be appropriate if the RBridges are known to have compatible scoping concepts). The language could be more explicit, but to be realistic, network administrators would generally avoid allowing this problem to exist in the first place. 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 l2B7PSwt021973 for <rbridge@postel.org>; Sat, 10 Mar 2007 23:25:28 -0800 (PST) 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 <0JEQ0000U9Y3YP00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 10 Mar 2007 23:25:15 -0800 (PST) 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 <0JEQ0051M9Y2HU00@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 10 Mar 2007 23:25:14 -0800 (PST) Received: from [152.70.2.164] (Forwarded-For: [142.131.243.242]) by mail-srv.sfvic.sunlabs.com (mshttpd); Sat, 10 Mar 2007 23:25:14 -0800 Date: Sat, 10 Mar 2007 23:25:14 -0800 From: Radia.Perlman@sun.com To: Erik Nordmark <erik.nordmark@sun.com> Message-id: <2f2a7526340.45f33e5a@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] VLAN Scoping / MAC Uniqueness 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, 11 Mar 2007 07:26:05 -0000 Status: RO Content-Length: 2326 I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked at as implicitly advertising the VLAN. In other words, the endnode information is announced in an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it). Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually store the information. Radia ----- Original Message ----- From: Erik Nordmark <erik.nordmark@sun.com> Date: Friday, March 9, 2007 4:11 pm Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness > Caitlin Bestler wrote: > > > This suggests three options: > > > > 1) Require all RBridges to scope on a per-VLAN basis. > > The only real flaw in this is that it is a RBridge > > requirement that does not apply to conventional bridges. > > > > 2) Allow all RBridges to have whatever scoping rules they > > want, but require that all updates go to all RBridgges. > > Each RBridge can judge for itself it the information is > > relevant to it, and organize that data however it wants. > > > > 3) Punt: require the network adminstrator to ensure that naming > > scopes enforced by RBRidges are "consistent" and provide > > only text-based suggestions on how to achieve this. > > I didn't see a conclusion on this discussion. > > I think 802.1D mandates that bridges be capable of doing learning > independently for each VLAN (what is called IVL). Thus mandating > the > same for RBridges (option 1 above) seems natural. > > I think this means that the link state routing protocol needs to be > able > to carry <VLAN tag, L2 address> in the LSAs instead of just <L2 > address>. If that is correct then we should clarify this in the > routing > requirements. They currently say > o layer 2 addresses of nodes within the domain which have > transmitted frames but have not transmitted ARP or ND replies > and that would need to be the tuple of VLAN tag and L2 address. > > Erik > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2A0BVuA004200 for <rbridge@postel.org>; Fri, 9 Mar 2007 16:11:31 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2A0BUmH013916; Sat, 10 Mar 2007 00:11:30 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2A0BS8i191360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 16:11:29 -0800 (PST) Message-ID: <45F1F7AD.3000909@sun.com> Date: Fri, 09 Mar 2007 16:11:25 -0800 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F1FBCF62@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1FBCF62@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness 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, 10 Mar 2007 00:12:01 -0000 Status: RO Content-Length: 1364 Caitlin Bestler wrote: > This suggests three options: > > 1) Require all RBridges to scope on a per-VLAN basis. > The only real flaw in this is that it is a RBridge > requirement that does not apply to conventional bridges. > > 2) Allow all RBridges to have whatever scoping rules they > want, but require that all updates go to all RBridgges. > Each RBridge can judge for itself it the information is > relevant to it, and organize that data however it wants. > > 3) Punt: require the network adminstrator to ensure that naming > scopes enforced by RBRidges are "consistent" and provide > only text-based suggestions on how to achieve this. I didn't see a conclusion on this discussion. I think 802.1D mandates that bridges be capable of doing learning independently for each VLAN (what is called IVL). Thus mandating the same for RBridges (option 1 above) seems natural. I think this means that the link state routing protocol needs to be able to carry <VLAN tag, L2 address> in the LSAs instead of just <L2 address>. If that is correct then we should clarify this in the routing requirements. They currently say o layer 2 addresses of nodes within the domain which have transmitted frames but have not transmitted ARP or ND replies and that would need to be the tuple of VLAN tag and L2 address. Erik 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 l2A06KbS002923 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Fri, 9 Mar 2007 16:06:20 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2A06DBM029521; Sat, 10 Mar 2007 00:06:17 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2A06EPQ189892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 16:06:15 -0800 (PST) Message-ID: <45F1F673.8010702@sun.com> Date: Fri, 09 Mar 2007 16:06:11 -0800 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com> References: <941D5DCD8C42014FAF70FB7424686DCF7B6AF8@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF7B6AF8@eusrcmw721.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Global MAC Addresses 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, 10 Mar 2007 00:06:27 -0000 Status: RO Content-Length: 1055 Eric Gray (LO/EUS) wrote: > Interstingly enough, I am really sure that the IPv6 folks > have looked at this before. And I am also sure that at least one > suggested solution has been considered. I do not know if any (of > possibly many) proposals were actually adopted but, if none were, > it would be because the IPv6 people did not see this as a problem. AFAIK the IPv6 folks have not considered this. But as you pointed out, the global IPv6 addresses would still be globally unique since they would have different subnet prefixes. The only issue for IPv6 is that this (and host-side virtualization in general) means that the the semantics of the universal bit in the modified EUI-64 format is even weaker than before. But there is no protocol to date which assumes anything about the semantics of this bit. As RFC 4291 says: The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope. Erik 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 l29NwwSY001263 for <rbridge@postel.org>; Fri, 9 Mar 2007 15:58:58 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29Nwvx8002937; Fri, 9 Mar 2007 23:58:57 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l29NwuBk186171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 15:58:56 -0800 (PST) Message-ID: <45F1F4B2.5040500@sun.com> Date: Fri, 09 Mar 2007 15:58:42 -0800 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Dino Farinacci <dino@cisco.com> References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> <45F1E1C6.7060905@sun.com> <EE4ECD02-103F-4352-8D9E-03DBC55D4D91@cisco.com> In-Reply-To: <EE4ECD02-103F-4352-8D9E-03DBC55D4D91@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 09 Mar 2007 23:59:35 -0000 Status: RO Content-Length: 2023 Dino Farinacci wrote: > The simplest example is when using multi-access links. The fact that > some switches use the multi-access link as an oif and others use the > link as an expected-incoming interface. > > So if the ones that are using the multi-access link as an oif happen to > join the root through one of the other switches (which can be many hops > away), then the multicast forwarding (and replication) loop occurs. With TRILL be clearly have to be careful at the edge (the ingress and egress rbridges) when it comes to the relationship between 802.1D and designated RBridge in order to handle topology changes. In particular since the frames without the TRILL header header doesn't have a TTL. But leaving that aside for a moment, the way Radia described the forwarding check (the "expected incoming adjacency" check), the transit paths between the RBridges would act as point-to-point due to checking both the incoming port and the previous hop RBridge. It was in such a pt-pt topology that I tried to find a simple example of a temporary loop. >> Have you observed temporary IP Multicast loops? (apart from the PIM SM >> ones before ASSERTS where added). What was the topology and change >> necessary to trigger those? > > Oh definitely, when two routers think the RP for a (*,G) are different. > And this can happen when the topology is in steady state. > > And this happens due to misconfiguration or in the early days of PIM > when you detect one RP down, you move to another one, but others in the > topology stayed with the original one. Again, in a steady-state > topology. The reason some thought the RP went down is because the > network was congested and the RP keepalives were all lost. Those were > interesting times. ;-) > > So this can happen in IS-IS as well if the not everyone is using the > same roots. But AFAICT that type of loop can't happen in TRILL since we have an explicit designator for the tree to use in every multi-destination data frame. Erik 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 l29Na4BC024800 for <rbridge@postel.org>; Fri, 9 Mar 2007 15:36:04 -0800 (PST) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2007 15:36:04 -0800 X-IronPort-AV: i="4.14,268,1170662400"; d="scan'208"; a="119715557:sNHT45711342" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l29Na4nj001280; Fri, 9 Mar 2007 15:36:04 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l29NZsxb002843; Fri, 9 Mar 2007 23:36:00 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 15:35:59 -0800 Received: from [10.253.200.34] ([10.21.81.164]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 15:35:59 -0800 In-Reply-To: <45F1E1C6.7060905@sun.com> References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> <45F1E1C6.7060905@sun.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <EE4ECD02-103F-4352-8D9E-03DBC55D4D91@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci <dino@cisco.com> Date: Fri, 9 Mar 2007 15:36:03 -0800 To: Erik Nordmark <erik.nordmark@sun.com> X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Mar 2007 23:35:59.0603 (UTC) FILETIME=[B13BDC30:01C762A3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1628; t=1173483364; x=1174347364; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=nHM4UA0KwpbCsRQQZ6HHE0zb+Tef9OLNC8IubgvxjyY=; b=GuSNCC+ZkbKaNC3rV+GqQ7+GUQLokO4grlBjk6+nNj0Jsbs/6RiE+xjO7yB3I5WGBbdHQ3p0 YnYqB7CvBKkNmbINNz5iX6X8RxBLZpFrfZGt6DKDvXGQmDRjG+umpTGj; Authentication-Results: sj-dkim-5; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@cisco.com Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 09 Mar 2007 23:36:32 -0000 Status: RO Content-Length: 1593 > I'm trying to draw an example topology where a change causes a > transient multicast loop (with an "expected incoming adjacency" > check) and I can't find one. Unicast is sooo much easier ;-) The simplest example is when using multi-access links. The fact that some switches use the multi-access link as an oif and others use the link as an expected-incoming interface. So if the ones that are using the multi-access link as an oif happen to join the root through one of the other switches (which can be many hops away), then the multicast forwarding (and replication) loop occurs. This only happens when the link state database is not in sync among the switches involved because each one thinks the root is located on a different path while still consider the same location of the receivers. > Have you observed temporary IP Multicast loops? (apart from the PIM > SM ones before ASSERTS where added). What was the topology and > change necessary to trigger those? Oh definitely, when two routers think the RP for a (*,G) are different. And this can happen when the topology is in steady state. And this happens due to misconfiguration or in the early days of PIM when you detect one RP down, you move to another one, but others in the topology stayed with the original one. Again, in a steady-state topology. The reason some thought the RP went down is because the network was congested and the RP keepalives were all lost. Those were interesting times. ;-) So this can happen in IS-IS as well if the not everyone is using the same roots. Dino Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29Mc0PP011160 for <rbridge@postel.org>; Fri, 9 Mar 2007 14:38:00 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29Mbxun013929; Fri, 9 Mar 2007 22:37:59 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l29MbwdA174717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 14:37:58 -0800 (PST) Message-ID: <45F1E1C6.7060905@sun.com> Date: Fri, 09 Mar 2007 14:37:58 -0800 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Dino Farinacci <dino@cisco.com> References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> In-Reply-To: <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 09 Mar 2007 22:38:24 -0000 Status: RO Content-Length: 673 Dino Farinacci wrote: >> Will you also agree with me that this technique is useful for >> network in >> a steady state, but does not prevent temporary loops when there is a >> topology change? > > I agree there will be transient multicast packet looping when there > are topology changes. Dino, I'm trying to draw an example topology where a change causes a transient multicast loop (with an "expected incoming adjacency" check) and I can't find one. Unicast is sooo much easier ;-) Have you observed temporary IP Multicast loops? (apart from the PIM SM ones before ASSERTS where added). What was the topology and change necessary to trigger those? Erik Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29LCPjR017483 for <rbridge@postel.org>; Fri, 9 Mar 2007 13:12:25 -0800 (PST) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 09 Mar 2007 13:12:13 -0800 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 030B72B0; Fri, 9 Mar 2007 13:12:13 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id E3F122AF for <rbridge@postel.org>; Fri, 9 Mar 2007 13:12:12 -0800 (PST) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FAP22606; Fri, 9 Mar 2007 13:12:12 -0800 (PST) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 4A28869CA4 for <rbridge@postel.org>; Fri, 9 Mar 2007 13:12:12 -0800 ( PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Mar 2007 13:12:11 -0800 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D030EA301@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <E1HPPYp-0007H7-JE@stiedprstage1.ietf.org> Thread-Topic: NITS RE: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt Thread-Index: AcdhxouSEzY9fPumQjKKH6czZxJ+LwAxxu4Q From: "Caitlin Bestler" <caitlinb@broadcom.com> To: rbridge@postel.org X-WSS-ID: 69EF122738G1388067-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l29LCPjR017483 Subject: [rbridge] NITS RE: I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt 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, 09 Mar 2007 21:12:56 -0000 Status: RO Content-Length: 441 The definition of "CRED" in section 2.2 fails to clarify where the "D" comes from. o CRED: Cooperating RBridges and Encapsulation Tunnels - a topological construct consisting of a set of cooperating RBridges, and the forwarding tunnels connecting them. The CFT-RDT table is not given a distinct long name. This is especially apparent when looking at the headers 3.2.1 and 3.2.2, which differ only by the short names. Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28MY8oA018134 for <rbridge@postel.org>; Thu, 8 Mar 2007 14:34:08 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2007 14:34:08 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="765971593:sNHT50213356" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l28MY7lC025736; Thu, 8 Mar 2007 14:34:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l28MY11r023981; Thu, 8 Mar 2007 22:34:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 14:34:00 -0800 Received: from [171.71.57.36] ([171.71.57.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 14:34:00 -0800 In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> References: <c63425231b3e.45efc977@sunlabs.com><0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com><45F04E8B.5090304@sun.com><9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com><45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <242EFFB6-40B0-42D5-978D-A62713169291@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci <dino@cisco.com> Date: Thu, 8 Mar 2007 14:34:05 -0800 To: "Silvano Gai" <sgai@nuovasystems.com> X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Mar 2007 22:34:00.0291 (UTC) FILETIME=[DDF02330:01C761D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=277; t=1173393247; x=1174257247; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=RejDwJa7iI6h4z1u+OQRmLi+P8lOwcnkMP3nvD4P8WU=; b=il7dX3xtGLz/ozZFV3UDnqFOVTYhUZm3zpcPIgkLFLKU+c952wpGX6DCZzf6BOSBS1xwebth kRVrs7umFdsAjjhODTRw7b1NrGHm8DZLx3B+YxKBe9Ci9ndueycSramT; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@cisco.com Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 22:34:35 -0000 Status: RO Content-Length: 268 > Will you also agree with me that this technique is useful for > network in > a steady state, but does not prevent temporary loops when there is a > topology change? I agree there will be transient multicast packet looping when there are topology changes. Dino 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 l28M14Dc009773 for <rbridge@postel.org>; Thu, 8 Mar 2007 14:01:04 -0800 (PST) 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, 8 Mar 2007 14:01:00 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2013011B7@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees thread-index: AcdhvGLm6W/ZqgQPShy0sUq5zITDOQAEJQkg References: <c63425231b3e.45efc977@sunlabs.com><0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com><45F04E8B.5090304@sun.com><9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com><45F05BC3.5090102@Sun.COM> <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Dino Farinacci" <dino@cisco.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 l28M14Dc009773 Cc: rbridge@postel.org Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 22:01:25 -0000 Status: RO Content-Length: 1038 I am glad you agree ;-) Will you also agree with me that this technique is useful for network in a steady state, but does not prevent temporary loops when there is a topology change? -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Dino Farinacci > Sent: Thursday, March 08, 2007 11:49 AM > To: Radia.Perlman@sun.com > Cc: rbridge@postel.org > Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge > trees > > > There is an open question, however, which is whether the "expected > > incoming interface" check should be > > SHOULD, MAY or MUST for checking not just port, but neighbor. The > > downside is the extra 6-byte > > check, as you point out. The upside is less likely to have bizarre > > temporary loops. I'd vote for > > MUST actually. > > I definitely agree with MUST. > > Dino > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28Ko8lb022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 8 Mar 2007 12:50:09 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D7405176C7; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007H7-JE; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1HPPYp-0007H7-JE@stiedprstage1.ietf.org> Date: Thu, 08 Mar 2007 15:50:03 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ietf@ietf.org Cc: rbridge@postel.org Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt 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, 08 Mar 2007 20:50:23 -0000 Status: RO Content-Length: 3764 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : The Architecture of an RBridge Solution to TRILL Author(s) : E. Gray Filename : draft-ietf-trill-rbridge-arch-02.txt Pages : 35 Date : 2007-3-8 RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine several of the benefits of the link layer with network layer routing benefits. RBridges use existing link state routing (without requiring configuration) to improve RBridge to RBridge aggregate throughput. RBridges also provide support for IP multicast and IP address resolution optimizations. They are intended to be applicable to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also support VLANs (although this generally requires configuration) and otherwise attempt to retain as much 'plug and play' as is already available in existing bridges. This document proposes an RBridge system as a solution to the TRILL problem. It also defines the RBridge architecture, defines its terminology, and describes basic components and desired behavior. One or more separate documents specify the protocols and mechanisms that satisfy the architecture presented herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trill-rbridge-arch-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trill-rbridge-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8121201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trill-rbridge-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-trill-rbridge-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8121201.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 l28Jn1hL007962 for <rbridge@postel.org>; Thu, 8 Mar 2007 11:49:01 -0800 (PST) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2007 11:49:01 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="364702245:sNHT56643876" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l28Jn1sB002487; Thu, 8 Mar 2007 11:49:01 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l28Jn1a3028331; Thu, 8 Mar 2007 19:49:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 11:49:00 -0800 Received: from [171.71.55.98] ([171.71.55.98]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 11:49:00 -0800 In-Reply-To: <45F05BC3.5090102@Sun.COM> References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> <45F05BC3.5090102@Sun.COM> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <875904EC-2B64-470F-A3A5-19CDFB957DB6@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci <dino@cisco.com> Date: Thu, 8 Mar 2007 11:49:04 -0800 To: Radia.Perlman@sun.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Mar 2007 19:49:00.0481 (UTC) FILETIME=[D1310310:01C761BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=378; t=1173383341; x=1174247341; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=ln0kn5O/6ItCxbSGbwAyGPQcYdz+gi1T6AoSGEOdwO8=; b=WwuDHhJM9JAk0CaVOdwbqhN18HREXDSeCh6KI7dmqjTJPxMnz4JM/NcoZAxjNAm99aGW+JXZ JeSnk62EHKpJ7UEhKnDYbgV6Pg2CfZZ1fwE+sH31ByEEsEGKMJtXvOn7; Authentication-Results: sj-dkim-6; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 19:49:24 -0000 Status: RO Content-Length: 367 > There is an open question, however, which is whether the "expected > incoming interface" check should be > SHOULD, MAY or MUST for checking not just port, but neighbor. The > downside is the extra 6-byte > check, as you point out. The upside is less likely to have bizarre > temporary loops. I'd vote for > MUST actually. I definitely agree with MUST. Dino 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 l28Iru3i023415 for <rbridge@postel.org>; Thu, 8 Mar 2007 10:53:57 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEL0074VLTWMW00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 08 Mar 2007 10:53:56 -0800 (PST) Received: from [129.145.154.55] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEL008GSLTVOP00@mail.sunlabs.com> for rbridge@postel.org; Thu, 08 Mar 2007 10:53:56 -0800 (PST) Date: Thu, 08 Mar 2007 10:53:55 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> To: Dino Farinacci <dino@cisco.com> Message-id: <45F05BC3.5090102@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060629 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Radia.Perlman@sun.com 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, 08 Mar 2007 18:54:24 -0000 Status: RO Content-Length: 4278 Yup. The bottom line, for those only skimming, is that you and I are not disagreeing about anything. And the action item from this thread is that the extra announcement "these are the trees I will specify" should go into IS-IS, in the core instance LSP. Also, in the protocol spec, it we should update the forwarding/filtering rules to include "allowed ingress RBridges on this adjacency/port", and make sure the filtering rules really do specify what you and I said, in different words. There is an open question, however, which is whether the "expected incoming interface" check should be SHOULD, MAY or MUST for checking not just port, but neighbor. The downside is the extra 6-byte check, as you point out. The upside is less likely to have bizarre temporary loops. I'd vote for MUST actually. Radia Dino Farinacci wrote On 03/08/07 10:20,: >>We're not talking about G's here, as in specific multicast >>destination addresses. We're talking >>about >>a) Distinct distribution trees: computed by using the link state >>database to compute a shortest path >>tree from the named Root >>b) ingress RBridges, for filtering based on "expected incoming >>interface (adjacency) check" >> >> > >Yes, I understand that. But the state storage cost here is more in >control-plane memory which is less of a concern than forwarding-plane >memory. That is why I spoke up. > > > >>(Note: when you say "interface" do you mean what I refer to as >>"adjacency" (which is a (port, neighbor) pair), >> >> > >I meant port, but if you want to do a last-hop neighbor incoming >check then you have to do a 6-byte compare and are required to have >the last-hop MAC address in the frame. I know the frame formats have >been changing, so not sure that the last-hop MAC address is still in >the frame (I'm behind on TRILL reading). > > > >>or do you mean "port"? -- I'll assume you mean "adjacency", and >>therefore I'll use "interface" because I >>never really liked the word "adjacency" --- too many syllables, and >>it's a word I never tend to use in >>ordinary conversation. >> >> > >Right, adjacency tends to be more unicast centric and means >downstream. We are talking about upstream interfaces here (closer to >the source and not closer towards the destination). > > > >>Anyway...where G's come in (as well as VLANs), is further filtering >>information on each interface in the >>named tree. >> >> > >Right. > > > >>So the rules are, if R3 receives a multicast packet on interface >>i, with named tree=R2, and ingress RBridge=R1, >>then: >> >>if R1 is not on the expected source list for interface i, then the >>packet is dropped >> >> > >Right, said another way if R1 is not the last-hop device on the >shortest path from R1 to R3, the packet is dropped. > > > >>passing that check, for each interface other than i, in tree R2, >>filtering is done based on whether the VLAN >> >> > >Yes. But I mentioned this before. The oif-list for the G is populated >based on the receivers downstream. So you actually filter by default >and only the ports in the oif-list get packets sent out on. > >I know why you say filtered, because you are describing a broadcast >tree which contains all links in the topology and the membership tree >is typically a subset of those links. > >Doesn't matter, just terms. I think we agree on the concept. > > > >>specified in the inner frame can be reached downstream on that >>interface, and for IP multicast group G, whether >>either IP multicast routers, or receivers for G are reachable >>downstream on that interface. >> >> > >Right. > >But just to reiterate my point, when a packet comes into an rBridge, >in fast switching mode, an entry like this exists to be forwarded on >if the DA is G: > > (*,G), incoming-interface: port i, oif-list: port j, k, l > >So as you say if the packet came in on port i, the packet gets >replicated out >ports j,k,l. If the packet comes in on any other port, it is dropped. > >What I describe above could be implemented in a fast hardware >implementation. > >Dino >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > 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 l28IKb2Q015363 for <rbridge@postel.org>; Thu, 8 Mar 2007 10:20:37 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2007 10:20:35 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="119276010:sNHT47950209" 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 l28IKYSe031365; Thu, 8 Mar 2007 10:20:34 -0800 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 l28IKUe3015219; Thu, 8 Mar 2007 18:20:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 10:20:34 -0800 Received: from [10.253.144.98] ([10.21.82.142]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 10:20:34 -0800 In-Reply-To: <45F04E8B.5090304@sun.com> References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> <45F04E8B.5090304@sun.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BCAE8CB-F39A-4099-82C9-CE0911C6952B@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci <dino@cisco.com> Date: Thu, 8 Mar 2007 10:20:36 -0800 To: Radia Perlman <Radia.Perlman@sun.com> X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Mar 2007 18:20:34.0174 (UTC) FILETIME=[7662D1E0:01C761AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3192; t=1173378035; x=1174242035; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=PpCys0nt6Vtepypcd9uAxCPA7oWTx0QjnRf89eIbfLE=; b=dESXXEUoFPzAnxic97Zu7z5bRqyt4/yVYKMuT2A24J0b/s1+S+AwxV3SrDhkDjI/4mR+d9Dm qQHH7rahmjYP1PpVPuHf0lEbLRwuh8ApquJ8RNNNjVepDxiczpOm6FaI; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 18:20:53 -0000 Status: RO Content-Length: 3110 > We're not talking about G's here, as in specific multicast > destination addresses. We're talking > about > a) Distinct distribution trees: computed by using the link state > database to compute a shortest path > tree from the named Root > b) ingress RBridges, for filtering based on "expected incoming > interface (adjacency) check" Yes, I understand that. But the state storage cost here is more in control-plane memory which is less of a concern than forwarding-plane memory. That is why I spoke up. > (Note: when you say "interface" do you mean what I refer to as > "adjacency" (which is a (port, neighbor) pair), I meant port, but if you want to do a last-hop neighbor incoming check then you have to do a 6-byte compare and are required to have the last-hop MAC address in the frame. I know the frame formats have been changing, so not sure that the last-hop MAC address is still in the frame (I'm behind on TRILL reading). > or do you mean "port"? -- I'll assume you mean "adjacency", and > therefore I'll use "interface" because I > never really liked the word "adjacency" --- too many syllables, and > it's a word I never tend to use in > ordinary conversation. Right, adjacency tends to be more unicast centric and means downstream. We are talking about upstream interfaces here (closer to the source and not closer towards the destination). > Anyway...where G's come in (as well as VLANs), is further filtering > information on each interface in the > named tree. Right. > So the rules are, if R3 receives a multicast packet on interface > i, with named tree=R2, and ingress RBridge=R1, > then: > > if R1 is not on the expected source list for interface i, then the > packet is dropped Right, said another way if R1 is not the last-hop device on the shortest path from R1 to R3, the packet is dropped. > passing that check, for each interface other than i, in tree R2, > filtering is done based on whether the VLAN Yes. But I mentioned this before. The oif-list for the G is populated based on the receivers downstream. So you actually filter by default and only the ports in the oif-list get packets sent out on. I know why you say filtered, because you are describing a broadcast tree which contains all links in the topology and the membership tree is typically a subset of those links. Doesn't matter, just terms. I think we agree on the concept. > specified in the inner frame can be reached downstream on that > interface, and for IP multicast group G, whether > either IP multicast routers, or receivers for G are reachable > downstream on that interface. Right. But just to reiterate my point, when a packet comes into an rBridge, in fast switching mode, an entry like this exists to be forwarded on if the DA is G: (*,G), incoming-interface: port i, oif-list: port j, k, l So as you say if the packet came in on port i, the packet gets replicated out ports j,k,l. If the packet comes in on any other port, it is dropped. What I describe above could be implemented in a fast hardware implementation. Dino 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 l28HvOmD009223 for <rbridge@postel.org>; Thu, 8 Mar 2007 09:57:24 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEL0072VJ7OMX00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 08 Mar 2007 09:57:24 -0800 (PST) Received: from sun.com ([129.150.17.32]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEL008AGJ7NOP00@mail.sunlabs.com> for rbridge@postel.org; Thu, 08 Mar 2007 09:57:24 -0800 (PST) Date: Thu, 08 Mar 2007 09:57:31 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> To: Dino Farinacci <dino@cisco.com> Message-id: <45F04E8B.5090304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <c63425231b3e.45efc977@sunlabs.com> <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 17:57:56 -0000 Status: RO Content-Length: 2054 We're not talking about G's here, as in specific multicast destination addresses. We're talking about a) Distinct distribution trees: computed by using the link state database to compute a shortest path tree from the named Root b) ingress RBridges, for filtering based on "expected incoming interface (adjacency) check" (Note: when you say "interface" do you mean what I refer to as "adjacency" (which is a (port, neighbor) pair), or do you mean "port"? -- I'll assume you mean "adjacency", and therefore I'll use "interface" because I never really liked the word "adjacency" --- too many syllables, and it's a word I never tend to use in ordinary conversation. Anyway...where G's come in (as well as VLANs), is further filtering information on each interface in the named tree. So the rules are, if R3 receives a multicast packet on interface i, with named tree=R2, and ingress RBridge=R1, then: if R1 is not on the expected source list for interface i, then the packet is dropped passing that check, for each interface other than i, in tree R2, filtering is done based on whether the VLAN specified in the inner frame can be reached downstream on that interface, and for IP multicast group G, whether either IP multicast routers, or receivers for G are reachable downstream on that interface. Radia Dino Farinacci wrote: > > The dominate state in the forwarding plane is number of group > entries, regardless of he number of roots. The forwarding plane > forwards on (*,G) entries, so that is the state volume we want to > keep an eye on. > >> The default is "compute a tree based on me" and "I will always choose >> tree rooted as me", which would result in (# of trees) state. The only >> RPF state at R2, for tree R1, >> is to put R1 onto the adjacency from which frames >> from R1 should arrive, and the null set on the other adjacencies in >> the R1 tree. > > > This doesn't make sense to me. You want to choose one root for a > particular (*,G) entry and all rBridges use the same root for this > entry. > > Dino 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 l28HW2iB002567 for <rbridge@postel.org>; Thu, 8 Mar 2007 09:32:02 -0800 (PST) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2007 09:31:54 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="469331336:sNHT46401144" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l28HVs70001357; Thu, 8 Mar 2007 09:31:54 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l28HViaT009204; Thu, 8 Mar 2007 17:31:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:31:51 -0800 Received: from [10.253.144.98] ([10.21.82.142]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:31:50 -0800 In-Reply-To: <c63425231b3e.45efc977@sunlabs.com> References: <c63425231b3e.45efc977@sunlabs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0046DBA4-E5E2-4006-99E7-2F2C2A2BFD9C@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci <dino@cisco.com> Date: Thu, 8 Mar 2007 09:31:54 -0800 To: Radia.Perlman@sun.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Mar 2007 17:31:50.0799 (UTC) FILETIME=[A7EB31F0:01C761A7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1178; t=1173375114; x=1174239114; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=MIxi4jdRw/nDOEmJWzdTPMaAS/h15KYUESgXPBtXNlg=; b=gAsmh8uSB7Br0LFJttZhErwWz3XHuSzznvcukxKxMMTHrSf7oSzZmQM1CkwMHx0Py0KSYvTD PSJV/aHJceW789TMKOWlYOOy/hXmTafNhbl62jjjTp8l+tiAIjckafn9; Authentication-Results: sj-dkim-8; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dino@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 17:32:30 -0000 Status: RO Content-Length: 1147 > As for terminology, I don't care. Is there a better term than "RPF > check"? It it not an RPF check, because as you and Sanjay described it, the best-path from an rBridge to a receiver is on the forward path. So an appropriate and less misleading term is "the expected incoming interface check". > And as you observed, the reason for having R1 announce the set of > trees > it will select is to avoid having (# of trees) * (# of RBridges) > RPF state. The dominate state in the forwarding plane is number of group entries, regardless of he number of roots. The forwarding plane forwards on (*,G) entries, so that is the state volume we want to keep an eye on. > The default is "compute a tree based on me" and "I will always choose > tree rooted as me", which would result in (# of trees) state. The only > RPF state at R2, for tree R1, > is to put R1 onto the adjacency from which frames > from R1 should arrive, and the null set on the other adjacencies in > the R1 tree. This doesn't make sense to me. You want to choose one root for a particular (*,G) entry and all rBridges use the same root for this entry. Dino 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 l28GTiHl013737 for <rbridge@postel.org>; Thu, 8 Mar 2007 08:29:44 -0800 (PST) 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 <0JEL0070FF5KMW00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 08 Mar 2007 08:29:44 -0800 (PST) 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 <0JEL00ED8F5JZB30@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 08 Mar 2007 08:29:43 -0800 (PST) Received: from [152.70.2.164] (Forwarded-For: [66.126.243.35]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 08 Mar 2007 08:29:43 -0800 Date: Thu, 08 Mar 2007 08:29:43 -0800 From: Radia.Perlman@sun.com To: "Sanjay Sane (sanjays)" <sanjays@cisco.com> Message-id: <c63425231b3e.45efc977@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] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 16:30:25 -0000 Status: RO Content-Length: 4388 Sanjay, We are agreeing on the technical details. As for terminology, I don't care. Is there a better term than "RPF check"? And as you observed, the reason for having R1 announce the set of trees it will select is to avoid having (# of trees) * (# of RBridges) RPF state. The default is "compute a tree based on me" and "I will always choose tree rooted as me", which would result in (# of trees) state. The only RPF state at R2, for tree R1, is to put R1 onto the adjacency from which frames from R1 should arrive, and the null set on the other adjacencies in the R1 tree. The only reasons R1 should choose a tree other than itself are: a) R1 is configured to decline being a tree root, in order to cut down on the number of trees RBridges need to compute, in which case R1 will, in most cases, be configured to just announce one tree, and always select that one b) R1 is sourcing some high volume multicast sources, in which case R1 is likely to be configured to choose perhaps 2, maybe 3, but not "lots of" different trees. So with this announcement of which trees R1 will choose when ingressing packets, it greatly simplifies RPF state. Radia ----- Original Message ----- From: "Sanjay Sane (sanjays)" <sanjays@cisco.com> Date: Wednesday, March 7, 2007 11:19 pm Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees > > What every rbridge wants to do is -- > for every rbridge Rx that could use tree R1, > On this tree R1, find which is the interface that leads me towards Rx, > or leads Rx towards me. > Multicast packets ingressed from Rx, and using tree R1, should be > allowed to come in only on this interface. > > The RPF state per interface could potentially be > #ofswitches * #oftrees > > By announcing this field, are you just trying to reduce the RPF > state ? > > btw, should we use the term "RPF" to denote what's being checked here? > What we're really checking is whether the ingress rbridge is really > forwarding as per a given R1 tree. > > -Sanjay > > > -----Original Message----- > From: rbridge-bounces@postel.org [rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Wednesday, March 07, 2007 6:18 PM > To: rbridge@postel.org > Subject: [rbridge] How to do RPF checks for bidirectional RBridge > trees > It isn't totally obvious how to do RPF (reverse path forwarding) > checksto make multicast forwarding safer, when we're doing > bidirectional trees > (ingress is R1, but R1 chooses tree root R2). > > So after thinking about it, I think this is how it would work, and it > introduces a new field that would be nice to add to the core instance > IS-IS LSP. The field is "I promise to only choose the following set of > RBridges to be tree roots". The only reasons for R1 to choose a > distribution tree rooted on an RBridge other than itself are: > > a) R1 is configured not to ask to be a tree root (so that RBridges > don'thave to calculate as many trees) > > b) R1 wants to multipath multicast originating on its attached links. > > The reason for having R1 preannounce is to simplify creating an RPF > database associated with each tree. > > If tree R1 is used if and only if R1 is the ingress for the data, then > the RPF tree for tree R1 would look like this, at some RBridge R in > thecore: > > for each "adjacency" (neighbor/port): one of the following: not in > tree,in-port, or out-port. The RPF check would discard any incoming > data for > tree R1 except on the in-port. > > However, if R1 chooses R2 as the root of the multicast tree, then the > RPF database associated with the tree R2, at some core RBridge R looks > like this: > > Let S be the set of RBridges that have announced, in their LSPs, that > they might choose R2 as the tree for multicast traffic they are > sourcinginto the campus. > > R keeps, for tree R2, and for each adjacency, {set of RBridges that > areplausible ingress RBridges for packets received on that adjacency}. > > The set union of all of those will be S. > > I hope that's correct, and that I've explained it clearly.... > > 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-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l287JLpO009149 for <rbridge@postel.org>; Wed, 7 Mar 2007 23:19:21 -0800 (PST) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2007 23:19:21 -0800 X-IronPort-AV: i="4.14,263,1170662400"; d="scan'208"; a="46488593:sNHT60593526" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l287JKXp004961; Wed, 7 Mar 2007 23:19:20 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l287JKxR010186; Thu, 8 Mar 2007 07:19:20 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 23:19:20 -0800 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, 7 Mar 2007 23:19:23 -0800 Message-ID: <7178B7E237F45D45BE404AFF0AF58D8702AA2DBD@xmb-sjc-213.amer.cisco.com> In-Reply-To: <45EF724E.2040706@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees Thread-Index: AcdhKkY4Dt6+4fFfTE6Tk3HJ8iVSOAAIth1A From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 08 Mar 2007 07:19:20.0425 (UTC) FILETIME=[16FD2590:01C76152] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2819; t=1173338360; x=1174202360; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=20=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:=20RE=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=j/3/YerqSpa/62l4/hTTDXQfDaTUuoucfptkZKaZCU0=; b=MCXUjLS2VQ2G3I+PFFcX9fOx0b3tdXcs45OGFOXdHXTR98eHN6lAH1xAP/nay82vUJ/dMYHO JpbhBLr5YVC+6E6ykrz/TlVlGEYCuqaNn81yV+hP5k8bWZKXiz0VZULq; Authentication-Results: sj-dkim-6; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l287JLpO009149 Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 07:19:54 -0000 Status: RO Content-Length: 2732 What every rbridge wants to do is -- for every rbridge Rx that could use tree R1, On this tree R1, find which is the interface that leads me towards Rx, or leads Rx towards me. Multicast packets ingressed from Rx, and using tree R1, should be allowed to come in only on this interface. The RPF state per interface could potentially be #ofswitches * #oftrees By announcing this field, are you just trying to reduce the RPF state ? btw, should we use the term "RPF" to denote what's being checked here? What we're really checking is whether the ingress rbridge is really forwarding as per a given R1 tree. -Sanjay -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Wednesday, March 07, 2007 6:18 PM To: rbridge@postel.org Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees It isn't totally obvious how to do RPF (reverse path forwarding) checks to make multicast forwarding safer, when we're doing bidirectional trees (ingress is R1, but R1 chooses tree root R2). So after thinking about it, I think this is how it would work, and it introduces a new field that would be nice to add to the core instance IS-IS LSP. The field is "I promise to only choose the following set of RBridges to be tree roots". The only reasons for R1 to choose a distribution tree rooted on an RBridge other than itself are: a) R1 is configured not to ask to be a tree root (so that RBridges don't have to calculate as many trees) b) R1 wants to multipath multicast originating on its attached links. The reason for having R1 preannounce is to simplify creating an RPF database associated with each tree. If tree R1 is used if and only if R1 is the ingress for the data, then the RPF tree for tree R1 would look like this, at some RBridge R in the core: for each "adjacency" (neighbor/port): one of the following: not in tree, in-port, or out-port. The RPF check would discard any incoming data for tree R1 except on the in-port. However, if R1 chooses R2 as the root of the multicast tree, then the RPF database associated with the tree R2, at some core RBridge R looks like this: Let S be the set of RBridges that have announced, in their LSPs, that they might choose R2 as the tree for multicast traffic they are sourcing into the campus. R keeps, for tree R2, and for each adjacency, {set of RBridges that are plausible ingress RBridges for packets received on that adjacency}. The set union of all of those will be S. I hope that's correct, and that I've explained it clearly.... 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 l282Hgkg007499 for <rbridge@postel.org>; Wed, 7 Mar 2007 18:17:43 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEK005JEBPIX300@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 07 Mar 2007 18:17:42 -0800 (PST) Received: from sun.com ([129.150.18.109]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEK006ZZBPIWW10@mail.sunlabs.com> for rbridge@postel.org; Wed, 07 Mar 2007 18:17:42 -0800 (PST) Date: Wed, 07 Mar 2007 18:17:50 -0800 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <45EF724E.2040706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees 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, 08 Mar 2007 02:18:13 -0000 Status: RO Content-Length: 1723 It isn't totally obvious how to do RPF (reverse path forwarding) checks to make multicast forwarding safer, when we're doing bidirectional trees (ingress is R1, but R1 chooses tree root R2). So after thinking about it, I think this is how it would work, and it introduces a new field that would be nice to add to the core instance IS-IS LSP. The field is "I promise to only choose the following set of RBridges to be tree roots". The only reasons for R1 to choose a distribution tree rooted on an RBridge other than itself are: a) R1 is configured not to ask to be a tree root (so that RBridges don't have to calculate as many trees) b) R1 wants to multipath multicast originating on its attached links. The reason for having R1 preannounce is to simplify creating an RPF database associated with each tree. If tree R1 is used if and only if R1 is the ingress for the data, then the RPF tree for tree R1 would look like this, at some RBridge R in the core: for each "adjacency" (neighbor/port): one of the following: not in tree, in-port, or out-port. The RPF check would discard any incoming data for tree R1 except on the in-port. However, if R1 chooses R2 as the root of the multicast tree, then the RPF database associated with the tree R2, at some core RBridge R looks like this: Let S be the set of RBridges that have announced, in their LSPs, that they might choose R2 as the tree for multicast traffic they are sourcing into the campus. R keeps, for tree R2, and for each adjacency, {set of RBridges that are plausible ingress RBridges for packets received on that adjacency}. The set union of all of those will be S. I hope that's correct, and that I've explained it clearly.... Radia 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 l27IwIiQ021029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <rbridge@postel.org>; Wed, 7 Mar 2007 10:58:18 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l27IwDc1011234 for <rbridge@postel.org>; Wed, 7 Mar 2007 18:58:17 GMT Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l27IwDj7607098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 10:58:13 -0800 (PST) Message-ID: <45EF0B45.6050100@sun.com> Date: Wed, 07 Mar 2007 10:58:13 -0800 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: rbridge@postel.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: [rbridge] Draft meeting agenda 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, 07 Mar 2007 18:58:24 -0000 Status: RO Content-Length: 91 The draft agenda is at http://www3.ietf.org/proceedings/07mar/agenda/trill.txt Erik 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 l271ZMVT009236 for <rbridge@postel.org>; Tue, 6 Mar 2007 17:35:22 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEI004U0F2U6600@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 06 Mar 2007 17:35:18 -0800 (PST) Received: from [129.145.154.55] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEI005UEF2T3410@mail.sunlabs.com> for rbridge@postel.org; Tue, 06 Mar 2007 17:35:18 -0800 (PST) Date: Tue, 06 Mar 2007 17:35:17 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <E0B2F4588FD7B8498D1798DA073BEF3D01F8E64A@hq-exch-2.corp.brocade.com> To: Phanidhar Koganti <pkoganti@Brocade.COM> Message-id: <45EE16D5.1020303@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <E0B2F4588FD7B8498D1798DA073BEF3D01F8E64A@hq-exch-2.corp.brocade.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060629 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] RBridge Ingress Address X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Radia.Perlman@sun.com 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, 07 Mar 2007 01:35:53 -0000 Status: RO Content-Length: 5122 There were various arguments about that as well. Personally, I think it's reasonable either way, and actually there might be a reason for some endnodes to be learned one way and others another. For instance, for access points in which endnodes enroll, it is likely better to send around announcements in IS-IS. Some of the arguments, again, off the top of my head, for why it's good to announce at least some of the endnodes a) sometimes it is clear when an endnode is no longer there (for instance, the access point finds out) in which case it's advantageous to tell everyone b) for IP nodes, it is possible for the RBridge to ping its attached endnodes to make sure they really are there. Perhaps only in response to seeing some other RBridge announce an attached endnode. c) in general only the egress RBridge will find out about S. If lots of people talk to S, then that traffic will be flooded, unless S's RBridge announces where S is. d) there might be a node that only occasionally talks and lots of nodes send it data, in which case traffic to it will often be flooded. e) I think some implementors were telling me that they didn't want to have to learn from decapsulated traffic. f) we probably do want to announce (layer 3, layer 2) pairs based on ARP/ND replies, so as to not require flooding ARP/ND queries. If most nodes are IP nodes, then that would mean most (if not all) would be advertised anyway. One reason I was happy the WG wanted to put in ingress RBridge as well as egress RBridge was because of the possibility of implicitly learning some of the endnodes. Radia Phanidhar Koganti wrote On 03/06/07 17:13,: >Radia, > >Thanks for the response. > >In you point c) if can learn end node addresses from the data-path >then why are we not doing it? Wouldn't it be a more scalable solution >for the control plane (ISIS). > >Thanks >Phanidhar Koganti >Brocade >408 333 5455 > >-----Original Message----- >From: Radia Perlman [mailto:Radia.Perlman@sun.com] >Sent: Tuesday, March 06, 2007 1:50 PM >To: Phanidhar Koganti >Cc: rbridge@postel.org >Subject: Re: [rbridge] RBridge Ingress Address > >You've really kind of answered your own question. Originally the shim >header only >had a single RBridge nickname. For unicast it was "egress". For >multicast it was >"ingress". Everything is engineering tradeoffs. There's seldom a "right > >answer", >but often two perfectly reasonable choices, and we don't want the WG >agonizing forever, >se we seem to have chosen having both ingress and egress. > >The cost of having both ingress and >egress is an extra 4 bytes. > >The advantages of having both are: >a) some IEEE things (like BCN -- congestion notification) require >knowing where something >came from, so could use "ingress RBridge" >b) tunneling usually has both source and destination, so it's "more >natural" >c) we might at some point choose, as you suggested, to learn some or all > >of the endnodes >based on decapsulated traffic (so only the egress RBridge would learn >the mapping between >the source MAC and the ingress RBridge) >d) for multicast, it allows multipathing by having the ingress RBridge >R1 choose a different >tree (not the one rooted at R1), for distributing the multicast frame >e) for multicast, it allows configuring things to compute fewer trees, >because instead of >requiring all RBridges to compute a tree rooted at every ingress, >RBridges can request >that they not be tree Roots. (except the RBridges with lowest IS-IS ID >-- that one has to be the >root of a tree so that there is always at least one tree all the >RBridges compute). > >There might have been other reasons, but these are the ones I could >remember off the top of my head. > >Radia > > > >Phanidhar Koganti wrote On 03/06/07 12:45,: > > > >>Hi, >> >>Went through the below draft briefly and had a basic question. Bear >> >> >with > > >>me if this has already been answered on the list >> >>http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0 >> >> >3 > > >>.txt >> >>For Known DA >> >> Trill.EgressRBridgesAddress = egress RBRIDGE; >> Trill.IngressRBridgesAddress = ingress RBRIDGE; >> >>For Unknown DA / Multicast Traffic >> >> Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution >>Tree >> Trill.IngressRBridgesAddress = ingress RBRIDGE; >> >>In both the above cases the unicast forwarding and the distribution >> >> >tree > > >>to use is conveyed using "Trill.EgressRBridgesAddress". >> >>My question is where does the "Trill.IngressRBridgesAddress" play a >>role? >> >> >>My second question is >> >>Learning of L2 end-node addresses are done using ISIS TLVs, why can't >> >> >we > > >>learn from the data-path similar to 802.1D/Q? >>(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) >> >>In such a case there would be use for the >> >> >"Trill.IngressRBridgesAddress" > > >>Thanks >>Phanidhar Koganti >>Brocade >> >>_______________________________________________ >>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 l271DWiI004174 for <rbridge@postel.org>; Tue, 6 Mar 2007 17:13:32 -0800 (PST) Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 06 Mar 2007 17:13:32 -0800 X-IronPort-AV: i="4.14,255,1170662400"; d="scan'208"; a="5959785:sNHT21314027" Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with SMTP id 0F63E238394; Tue, 6 Mar 2007 17:13:26 -0800 (PST) Received: from hq-exch-2.corp.brocade.com ([10.3.8.22]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 17:13:31 -0800 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, 6 Mar 2007 17:13:31 -0800 Message-ID: <E0B2F4588FD7B8498D1798DA073BEF3D01F8E64A@hq-exch-2.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] RBridge Ingress Address Thread-Index: AcdgOXICMgN3ApUISqWbcX12A6tYrQAHA5gA From: "Phanidhar Koganti" <pkoganti@Brocade.COM> To: <Radia.Perlman@sun.com> X-OriginalArrivalTime: 07 Mar 2007 01:13:31.0815 (UTC) FILETIME=[D22F4B70:01C76055] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: pkoganti@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l271DWiI004174 Cc: rbridge@postel.org Subject: Re: [rbridge] RBridge Ingress Address 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, 07 Mar 2007 01:14:30 -0000 Status: RO Content-Length: 3262 Radia, Thanks for the response. In you point c) if can learn end node addresses from the data-path then why are we not doing it? Wouldn't it be a more scalable solution for the control plane (ISIS). Thanks Phanidhar Koganti Brocade 408 333 5455 -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@sun.com] Sent: Tuesday, March 06, 2007 1:50 PM To: Phanidhar Koganti Cc: rbridge@postel.org Subject: Re: [rbridge] RBridge Ingress Address You've really kind of answered your own question. Originally the shim header only had a single RBridge nickname. For unicast it was "egress". For multicast it was "ingress". Everything is engineering tradeoffs. There's seldom a "right answer", but often two perfectly reasonable choices, and we don't want the WG agonizing forever, se we seem to have chosen having both ingress and egress. The cost of having both ingress and egress is an extra 4 bytes. The advantages of having both are: a) some IEEE things (like BCN -- congestion notification) require knowing where something came from, so could use "ingress RBridge" b) tunneling usually has both source and destination, so it's "more natural" c) we might at some point choose, as you suggested, to learn some or all of the endnodes based on decapsulated traffic (so only the egress RBridge would learn the mapping between the source MAC and the ingress RBridge) d) for multicast, it allows multipathing by having the ingress RBridge R1 choose a different tree (not the one rooted at R1), for distributing the multicast frame e) for multicast, it allows configuring things to compute fewer trees, because instead of requiring all RBridges to compute a tree rooted at every ingress, RBridges can request that they not be tree Roots. (except the RBridges with lowest IS-IS ID -- that one has to be the root of a tree so that there is always at least one tree all the RBridges compute). There might have been other reasons, but these are the ones I could remember off the top of my head. Radia Phanidhar Koganti wrote On 03/06/07 12:45,: >Hi, > >Went through the below draft briefly and had a basic question. Bear with >me if this has already been answered on the list > >http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0 3 >.txt > >For Known DA > > Trill.EgressRBridgesAddress = egress RBRIDGE; > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >For Unknown DA / Multicast Traffic > > Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution >Tree > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >In both the above cases the unicast forwarding and the distribution tree >to use is conveyed using "Trill.EgressRBridgesAddress". > >My question is where does the "Trill.IngressRBridgesAddress" play a >role? > > >My second question is > >Learning of L2 end-node addresses are done using ISIS TLVs, why can't we >learn from the data-path similar to 802.1D/Q? >(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) > >In such a case there would be use for the "Trill.IngressRBridgesAddress" > >Thanks >Phanidhar Koganti >Brocade > >_______________________________________________ >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 l26LoTY0015803 for <rbridge@postel.org>; Tue, 6 Mar 2007 13:50:29 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JEI004EI4NT6600@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 06 Mar 2007 13:50:17 -0800 (PST) Received: from [129.145.154.55] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JEI0054S4NO3410@mail.sunlabs.com> for rbridge@postel.org; Tue, 06 Mar 2007 13:50:17 -0800 (PST) Date: Tue, 06 Mar 2007 13:50:11 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <E0B2F4588FD7B8498D1798DA073BEF3D01EE4413@hq-exch-2.corp.brocade.com> To: Phanidhar Koganti <pkoganti@Brocade.COM> Message-id: <45EDE213.7050507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <E0B2F4588FD7B8498D1798DA073BEF3D01EE4413@hq-exch-2.corp.brocade.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060629 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] RBridge Ingress Address X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Radia.Perlman@sun.com 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, 06 Mar 2007 21:51:00 -0000 Status: RO Content-Length: 2800 You've really kind of answered your own question. Originally the shim header only had a single RBridge nickname. For unicast it was "egress". For multicast it was "ingress". Everything is engineering tradeoffs. There's seldom a "right answer", but often two perfectly reasonable choices, and we don't want the WG agonizing forever, se we seem to have chosen having both ingress and egress. The cost of having both ingress and egress is an extra 4 bytes. The advantages of having both are: a) some IEEE things (like BCN -- congestion notification) require knowing where something came from, so could use "ingress RBridge" b) tunneling usually has both source and destination, so it's "more natural" c) we might at some point choose, as you suggested, to learn some or all of the endnodes based on decapsulated traffic (so only the egress RBridge would learn the mapping between the source MAC and the ingress RBridge) d) for multicast, it allows multipathing by having the ingress RBridge R1 choose a different tree (not the one rooted at R1), for distributing the multicast frame e) for multicast, it allows configuring things to compute fewer trees, because instead of requiring all RBridges to compute a tree rooted at every ingress, RBridges can request that they not be tree Roots. (except the RBridges with lowest IS-IS ID -- that one has to be the root of a tree so that there is always at least one tree all the RBridges compute). There might have been other reasons, but these are the ones I could remember off the top of my head. Radia Phanidhar Koganti wrote On 03/06/07 12:45,: >Hi, > >Went through the below draft briefly and had a basic question. Bear with >me if this has already been answered on the list > >http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 >.txt > >For Known DA > > Trill.EgressRBridgesAddress = egress RBRIDGE; > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >For Unknown DA / Multicast Traffic > > Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution >Tree > Trill.IngressRBridgesAddress = ingress RBRIDGE; > >In both the above cases the unicast forwarding and the distribution tree >to use is conveyed using "Trill.EgressRBridgesAddress". > >My question is where does the "Trill.IngressRBridgesAddress" play a >role? > > >My second question is > >Learning of L2 end-node addresses are done using ISIS TLVs, why can't we >learn from the data-path similar to 802.1D/Q? >(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) > >In such a case there would be use for the "Trill.IngressRBridgesAddress" > >Thanks >Phanidhar Koganti >Brocade > >_______________________________________________ >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 l26KjAfJ028747 for <rbridge@postel.org>; Tue, 6 Mar 2007 12:45:10 -0800 (PST) Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 06 Mar 2007 12:45:10 -0800 X-IronPort-AV: i="4.14,255,1170662400"; d="scan'208"; a="7267116:sNHT17235246" Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with SMTP id B2603238398 for <rbridge@postel.org>; Tue, 6 Mar 2007 12:45:04 -0800 (PST) Received: from hq-exch-2.corp.brocade.com ([10.3.8.22]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 12:45:10 -0800 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, 6 Mar 2007 12:45:09 -0800 Message-ID: <E0B2F4588FD7B8498D1798DA073BEF3D01EE4413@hq-exch-2.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RBridge Ingress Address Thread-Index: Acc6g4j0kMFoZDvXTQOgWkSr53zkxglq85Qw From: "Phanidhar Koganti" <pkoganti@Brocade.COM> To: <rbridge@postel.org> X-OriginalArrivalTime: 06 Mar 2007 20:45:10.0291 (UTC) FILETIME=[54EDB630:01C76030] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: pkoganti@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l26KjAfJ028747 Subject: [rbridge] RBridge Ingress Address 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, 06 Mar 2007 20:45:44 -0000 Status: RO Content-Length: 1003 Hi, Went through the below draft briefly and had a basic question. Bear with me if this has already been answered on the list http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 .txt For Known DA Trill.EgressRBridgesAddress = egress RBRIDGE; Trill.IngressRBridgesAddress = ingress RBRIDGE; For Unknown DA / Multicast Traffic Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution Tree Trill.IngressRBridgesAddress = ingress RBRIDGE; In both the above cases the unicast forwarding and the distribution tree to use is conveyed using "Trill.EgressRBridgesAddress". My question is where does the "Trill.IngressRBridgesAddress" play a role? My second question is Learning of L2 end-node addresses are done using ISIS TLVs, why can't we learn from the data-path similar to 802.1D/Q? (Trill.IngressRBridgeAddress <-> Inner SRC MAC Address) In such a case there would be use for the "Trill.IngressRBridgesAddress" Thanks Phanidhar Koganti Brocade Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l25No6LW018108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 5 Mar 2007 15:50:06 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B2248177E4; Mon, 5 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOMwM-0000yJ-EL; Mon, 05 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1HOMwM-0000yJ-EL@stiedprstage1.ietf.org> Date: Mon, 05 Mar 2007 18:50:02 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ietf@ietf.org Cc: rbridge@postel.org Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-03.txt 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, 05 Mar 2007 23:50:31 -0000 Status: RO Content-Length: 3123 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : RBridges: Base Protocol Specification Author(s) : R. Perlman, et al. Filename : draft-ietf-trill-rbridge-protocol-03.txt Pages : 36 Date : 2007-3-5 RBridges allow for optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and the ability to cut down on ARP/ND and IP multicast traffic. They achieve these goals by replacing the Spanning Tree protocol with IS-IS. The design also supports VLANs, and allows forwarding tables to be based on RBridge destinations (rather than endnode destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trill-rbridge-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-5155229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-trill-rbridge-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5155229.I-D@ietf.org> --OtherAccess-- --NextPart--
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Radia Perlman
- [rbridge] Shared VLAN learning: What is it and wh… Sanjay Sane sanjays
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Dale W. Carder
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Russ White
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Radia Perlman
- [rbridge] Shared VLAN learning: What is it and wh… Radia Perlman
- [rbridge] Disable transit for a VLAN was (RE: Sha… Silvano Gai
- [rbridge] Other reason for Confusion (RE: Shared … Silvano Gai
- [rbridge] Disable transit for a VLAN was (RE: Sha… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Sanjay Sane sanjays
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… J. R. Rivers
- [rbridge] Shared VLAN learning: What is it and wh… Radia Perlman
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Caitlin Bestler
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… J. R. Rivers
- [rbridge] Two "shared VLAN" alternative proposals Radia Perlman
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Russ White
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Eric Gray LO/EUS
- [rbridge] Shared VLAN learning: What is it and wh… Dale W. Carder
- [rbridge] Shared VLAN learning: What is it and wh… Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] Shared VLAN learning: What is it and wh… Dinesh G Dutt
- [rbridge] Two "shared VLAN" alternative proposals Caitlin Bestler
- [rbridge] Two "shared VLAN" alternative proposals Joel M. Halpern
- [rbridge] Two "shared VLAN" alternative proposals Caitlin Bestler
- [rbridge] Two "shared VLAN" alternative proposals Radia Perlman
- [rbridge] Two "shared VLAN" alternative proposals Caitlin Bestler
- [rbridge] Two "shared VLAN" alternative proposals Joel M. Halpern
- [rbridge] Two "shared VLAN" alternative proposals Radia Perlman
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Caitlin Bestler
- [rbridge] Two "shared VLAN" alternative proposals J. R. Rivers
- [rbridge] Two "shared VLAN" alternative proposals Caitlin Bestler
- [rbridge] Two "shared VLAN" alternative proposals J. R. Rivers
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Silvano Gai
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Caitlin Bestler
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Eric Gray LO/EUS
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Eric Gray LO/EUS
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… J. R. Rivers
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Eric Gray LO/EUS
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… J. R. Rivers
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Eric Gray LO/EUS
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… J. R. Rivers
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Eric Gray LO/EUS
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Silvano Gai
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… J. R. Rivers
- [rbridge] Two "shared VLAN" alternative proposals Anoop Ghanwani
- [rbridge] Two "shared VLAN" alternative proposals Radia Perlman
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Anoop Ghanwani
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] ARP/ND (was RE: Two "shared VLAN" alter… Eastlake III Donald-LDE008
- [rbridge] Two "shared VLAN" alternative proposals Anoop Ghanwani
- [rbridge] Two "shared VLAN" alternative proposals Radia Perlman
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Anoop Ghanwani
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Silvano Gai
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS
- [rbridge] Two "shared VLAN" alternative proposals Eastlake III Donald-LDE008
- [rbridge] Two "shared VLAN" alternative proposals Eric Gray LO/EUS