[rbridge] TRILL Header Format
sgai at nuovasystems.com (Silvano Gai) Mon, 30 April 2007 19:21 UTC
From: "sgai at nuovasystems.com"
Date: Mon, 30 Apr 2007 12:21:06 -0700
Subject: [rbridge] TRILL Header Format
In-Reply-To: <46364123.2060008@cisco.com>
References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461E80DA.9010902@sun.com> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com> <461EB133.9030606@isi.edu> <461ED237.6020404@sun.com> <461ED550.9080501@isi.! edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is! ! ! i.e du> <34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com>
Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2015E42B8@nuova-ex1.hq.nuovaimpresa.com>
I agree with these two changes -- Silvano > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt at cisco.com] > Sent: Monday, April 30, 2007 12:19 PM > To: Silvano Gai > Cc: Rbridge at postel.org > Subject: Re: [rbridge] TRILL Header Format > > Two small corrections. In the second format, we really don't need any > indication of .1Q/.1S. The tag that is to be added at the egress port > maybe different from the tag that we received at the ingress port and is > part of the port logic. For example, the frame may have come in with a > .1Q tag and may go out a port that accepts no tagging at all. > > Given that we don't need to carry any indication of .1Q/.1S in the TRILL > header, I suggest that we also define the field "Inner 802.1Q/S tag" to > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and call > it DE (drop eligibility). This way if RBridges along the way can choose > to set the DE bit in the inner header, instead of treating it as an > opaque field. > > Dinesh > Silvano Gai wrote: > > The purpose of the following message is to converge on the final > > structure of the TRILL header. > > > > The format proposed in: > > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 > > .txt > > has been stable for a while. This message only describes the > > differences. > > > > At the last IETF Donald proposed to support a single extension header > > containing multiple extensions. > > > > After some discussion two solutions seem possible. Please express your > > preference by replying to this email. > > > > -- Silvano > > > > > > Solution 1 > > ========== > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | V |M|RSD|EH-length| Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Where: > > - RSD (2 bits) is reserved > > - EH-Length (5 bits) is the extension header length, expressed in units > > of in 4 bytes words. > > > > If EH-length is zero there is no extension header; > > else, the extensions follow immediately after the Egress Rbridge > > Nickname field, and the total length of all the extensions is as > > indicated by the EH-length field, expressed in units of 4-byte words. > > > > This solution allows 128 bytes of extensions. > > > > > > Solution 2 > > ========== > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | V |M|S| RSD | Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSD | EH-length | Inner IEEE 802.1Q/S tag | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority) > > into the TRILL header. The Inner 1Q/1S tag is no longer present in the > > inner frame. > > > > This simplifies the parsing for the core RBridges. On the other hand the > > Ingress/Egress Rbridges need to do slightly more work. > > > > This has more reserved space. Since the inner 1Q/1S tag is removed from > > the frame (4 bytes), it uses the same overall space of solution 1. > > > > The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1). > > > > The EH-length is 8 bits, with a granularity of 2 bytes it allows up to > > 512 bytes of extensions. > > > > The Hop Count can grow to 8 bits. > > > > > > A word of caution > > ================= > > > > Extensions are very appealing, but their practical deployment has been > > very limited. Often Router and Switches are not able to process in HW > > frames with extensions and they send them to SW. > > > > > > Example with Solution 1 > > ======================= > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = IEEE 802.1Q | UP |C| Outer VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = TRILL | V |M|RSD|EH-length| Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | InnerSource MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = IEEE 802.1Q | UP |C| Inner VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > | Original Ethernet Payload | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | New FCS | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TRILL Encapsulation over Ethernet with Solution 1 > > > > > > > > > > Example with Solution 2 > > ======================= > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = IEEE 802.1Q | UP |C| Outer VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = TRILL | V |M|S| RSD | Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSD | EH-length | UP |C| Inner VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | InnerSource MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > | Original Ethernet Payload | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | New FCS | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TRILL Encapsulation over Ethernet with Solution 2 > > > > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at 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 l3UJLChl003446 for <Rbridge@postel.org>; Mon, 30 Apr 2007 12:21:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Apr 2007 12:21:06 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2015E42B8@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <46364123.2060008@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TRILL Header Format Thread-Index: AceLXHeoa5ymOyrWTL6gJGFNQoWevQAACyqw References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461E80DA.9010902@sun.com> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com> <461EB133.9030606@isi.edu> <461ED237.6020404@sun.com> <461ED550.9080501@isi.! edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is! ! ! i.e du> <34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Dinesh G Dutt" <ddutt@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l3UJLChl003446 Cc: Rbridge@postel.org Subject: Re: [rbridge] TRILL Header Format 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, 30 Apr 2007 19:21:44 -0000 Status: RO Content-Length: 7889 I agree with these two changes -- Silvano > -----Original Message----- > From: Dinesh G Dutt [mailto:ddutt@cisco.com] > Sent: Monday, April 30, 2007 12:19 PM > To: Silvano Gai > Cc: Rbridge@postel.org > Subject: Re: [rbridge] TRILL Header Format > > Two small corrections. In the second format, we really don't need any > indication of .1Q/.1S. The tag that is to be added at the egress port > maybe different from the tag that we received at the ingress port and is > part of the port logic. For example, the frame may have come in with a > .1Q tag and may go out a port that accepts no tagging at all. > > Given that we don't need to carry any indication of .1Q/.1S in the TRILL > header, I suggest that we also define the field "Inner 802.1Q/S tag" to > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and call > it DE (drop eligibility). This way if RBridges along the way can choose > to set the DE bit in the inner header, instead of treating it as an > opaque field. > > Dinesh > Silvano Gai wrote: > > The purpose of the following message is to converge on the final > > structure of the TRILL header. > > > > The format proposed in: > > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 > > .txt > > has been stable for a while. This message only describes the > > differences. > > > > At the last IETF Donald proposed to support a single extension header > > containing multiple extensions. > > > > After some discussion two solutions seem possible. Please express your > > preference by replying to this email. > > > > -- Silvano > > > > > > Solution 1 > > ========== > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | V |M|RSD|EH-length| Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Where: > > - RSD (2 bits) is reserved > > - EH-Length (5 bits) is the extension header length, expressed in units > > of in 4 bytes words. > > > > If EH-length is zero there is no extension header; > > else, the extensions follow immediately after the Egress Rbridge > > Nickname field, and the total length of all the extensions is as > > indicated by the EH-length field, expressed in units of 4-byte words. > > > > This solution allows 128 bytes of extensions. > > > > > > Solution 2 > > ========== > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | V |M|S| RSD | Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSD | EH-length | Inner IEEE 802.1Q/S tag | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority) > > into the TRILL header. The Inner 1Q/1S tag is no longer present in the > > inner frame. > > > > This simplifies the parsing for the core RBridges. On the other hand the > > Ingress/Egress Rbridges need to do slightly more work. > > > > This has more reserved space. Since the inner 1Q/1S tag is removed from > > the frame (4 bytes), it uses the same overall space of solution 1. > > > > The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1). > > > > The EH-length is 8 bits, with a granularity of 2 bytes it allows up to > > 512 bytes of extensions. > > > > The Hop Count can grow to 8 bits. > > > > > > A word of caution > > ================= > > > > Extensions are very appealing, but their practical deployment has been > > very limited. Often Router and Switches are not able to process in HW > > frames with extensions and they send them to SW. > > > > > > Example with Solution 1 > > ======================= > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = IEEE 802.1Q | UP |C| Outer VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = TRILL | V |M|RSD|EH-length| Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | InnerSource MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = IEEE 802.1Q | UP |C| Inner VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > | Original Ethernet Payload | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | New FCS | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TRILL Encapsulation over Ethernet with Solution 1 > > > > > > > > > > Example with Solution 2 > > ======================= > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Destination MAC Address | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = IEEE 802.1Q | UP |C| Outer VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethertype = TRILL | V |M|S| RSD | Hop Count | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSD | EH-length | UP |C| Inner VID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ingress RBridge Nickname | Egress RBridge Nickname | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Destination MAC Address | InnerSource MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner Source MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > | Original Ethernet Payload | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | New FCS | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > TRILL Encapsulation over Ethernet with Solution 2 > > > > > > > > > > _______________________________________________ > > 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 rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3UJJ1fO002814 for <Rbridge@postel.org>; Mon, 30 Apr 2007 12:19:02 -0700 (PDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2007 15:19:02 -0400 X-IronPort-AV: i="4.14,471,1170651600"; d="scan'208"; a="59038719:sNHT61454100" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3UJJ1Jt013519; Mon, 30 Apr 2007 15:19:01 -0400 Received: from [10.82.216.183] (rtp-vpn3-183.cisco.com [10.82.216.183]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UJIxlG000079; Mon, 30 Apr 2007 19:19:00 GMT Message-ID: <46364123.2060008@cisco.com> Date: Mon, 30 Apr 2007 12:18:59 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461E80DA.9010902@sun.com> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com> <461EB133.9030606@isi.edu> <461ED237.6020404@sun.com> <461ED550.9080501@isi.! edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is! ! ! i.e du> <34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.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=8372; t=1177960741; x=1178824741; c=relaxed/simple; s=rtpdkim2001; 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]=20TRILL=20Header=20Format |Sender:=20 |To:=20Silvano=20Gai=20<sgai@nuovasystems.com>; bh=urY+/7c/bzzRXJA73mTP4eoKmA8Ptz2nwXUBwOYy1jA=; b=pI2saygf8F0lv2nxkf4HgUiGQkrUh/oHqX+X180SQjg9Xk0vI0WssoZDGMMSHlKUwJGGPVXI uftsBmeUWTD6128K4Nmv56AbLqCVB8aVDcP0xvH+RzySz52PuwCzdmXq; Authentication-Results: rtp-dkim-2; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: Rbridge@postel.org Subject: Re: [rbridge] TRILL Header Format 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, 30 Apr 2007 19:20:15 -0000 Status: RO Content-Length: 8195 Two small corrections. In the second format, we really don't need any indication of .1Q/.1S. The tag that is to be added at the egress port maybe different from the tag that we received at the ingress port and is part of the port logic. For example, the frame may have come in with a .1Q tag and may go out a port that accepts no tagging at all. Given that we don't need to carry any indication of .1Q/.1S in the TRILL header, I suggest that we also define the field "Inner 802.1Q/S tag" to be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and call it DE (drop eligibility). This way if RBridges along the way can choose to set the DE bit in the inner header, instead of treating it as an opaque field. Dinesh Silvano Gai wrote: > The purpose of the following message is to converge on the final > structure of the TRILL header. > > The format proposed in: > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 > .txt > has been stable for a while. This message only describes the > differences. > > At the last IETF Donald proposed to support a single extension header > containing multiple extensions. > > After some discussion two solutions seem possible. Please express your > preference by replying to this email. > > -- Silvano > > > Solution 1 > ========== > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | V |M|RSD|EH-length| Hop Count | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress RBridge Nickname | Egress RBridge Nickname | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where: > - RSD (2 bits) is reserved > - EH-Length (5 bits) is the extension header length, expressed in units > of in 4 bytes words. > > If EH-length is zero there is no extension header; > else, the extensions follow immediately after the Egress Rbridge > Nickname field, and the total length of all the extensions is as > indicated by the EH-length field, expressed in units of 4-byte words. > > This solution allows 128 bytes of extensions. > > > Solution 2 > ========== > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | V |M|S| RSD | Hop Count | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSD | EH-length | Inner IEEE 802.1Q/S tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress RBridge Nickname | Egress RBridge Nickname | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority) > into the TRILL header. The Inner 1Q/1S tag is no longer present in the > inner frame. > > This simplifies the parsing for the core RBridges. On the other hand the > Ingress/Egress Rbridges need to do slightly more work. > > This has more reserved space. Since the inner 1Q/1S tag is removed from > the frame (4 bytes), it uses the same overall space of solution 1. > > The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1). > > The EH-length is 8 bits, with a granularity of 2 bytes it allows up to > 512 bytes of extensions. > > The Hop Count can grow to 8 bits. > > > A word of caution > ================= > > Extensions are very appealing, but their practical deployment has been > very limited. Often Router and Switches are not able to process in HW > frames with extensions and they send them to SW. > > > Example with Solution 1 > ======================= > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer Destination MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer Destination MAC Address | Outer Source MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer Source MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethertype = IEEE 802.1Q | UP |C| Outer VID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethertype = TRILL | V |M|RSD|EH-length| Hop Count | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress RBridge Nickname | Egress RBridge Nickname | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner Destination MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner Destination MAC Address | InnerSource MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner Source MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethertype = IEEE 802.1Q | UP |C| Inner VID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Original Ethernet Payload | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | New FCS | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > TRILL Encapsulation over Ethernet with Solution 1 > > > > > Example with Solution 2 > ======================= > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer Destination MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer Destination MAC Address | Outer Source MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer Source MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethertype = IEEE 802.1Q | UP |C| Outer VID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethertype = TRILL | V |M|S| RSD | Hop Count | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSD | EH-length | UP |C| Inner VID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress RBridge Nickname | Egress RBridge Nickname | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner Destination MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner Destination MAC Address | InnerSource MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner Source MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Original Ethernet Payload | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | New FCS | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > TRILL Encapsulation over Ethernet with Solution 2 > > > > > _______________________________________________ > 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 l3UG6YaN014625 for <Rbridge@postel.org>; Mon, 30 Apr 2007 09:06:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Apr 2007 09:06:27 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TRILL Header Format Thread-Index: AceCN5wruuaX6T3WSK29pQEeR2PdVAAdXODQACgoHDAAOtOJ4AAICWcAAFYPHuAAaHHwIAAwvwog References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <941D5DCD8C42014FAF70FB7424686DCFB50CE7@eusrcmw721.eamcs.ericsson.se> <461BCD66.7070700@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA20151ABFE@nuova-ex1.hq.nuovaimpresa.com> <461C17AB.7000805@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFB514C5@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA20151AD73@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFB515A4@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA20151AE1E@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFB516B4@eusrcmw721.eamcs.ericsson.se> <461E80DA.9010902@sun.com> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com> <461EB133.9030606@isi.edu> <461ED237.6020404@sun.com> <461ED550.9080501@isi.! edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is! ! ! i.e du> <34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: <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 l3UG6YaN014625 Subject: [rbridge] TRILL Header Format 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, 30 Apr 2007 16:07:14 -0000 Status: RO Content-Length: 6878 The purpose of the following message is to converge on the final structure of the TRILL header. The format proposed in: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03 .txt has been stable for a while. This message only describes the differences. At the last IETF Donald proposed to support a single extension header containing multiple extensions. After some discussion two solutions seem possible. Please express your preference by replying to this email. -- Silvano Solution 1 ========== +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |M|RSD|EH-length| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Nickname | Egress RBridge Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: - RSD (2 bits) is reserved - EH-Length (5 bits) is the extension header length, expressed in units of in 4 bytes words. If EH-length is zero there is no extension header; else, the extensions follow immediately after the Egress Rbridge Nickname field, and the total length of all the extensions is as indicated by the EH-length field, expressed in units of 4-byte words. This solution allows 128 bytes of extensions. Solution 2 ========== +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |M|S| RSD | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSD | EH-length | Inner IEEE 802.1Q/S tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Nickname | Egress RBridge Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority) into the TRILL header. The Inner 1Q/1S tag is no longer present in the inner frame. This simplifies the parsing for the core RBridges. On the other hand the Ingress/Egress Rbridges need to do slightly more work. This has more reserved space. Since the inner 1Q/1S tag is removed from the frame (4 bytes), it uses the same overall space of solution 1. The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1). The EH-length is 8 bits, with a granularity of 2 bytes it allows up to 512 bytes of extensions. The Hop Count can grow to 8 bits. A word of caution ================= Extensions are very appealing, but their practical deployment has been very limited. Often Router and Switches are not able to process in HW frames with extensions and they send them to SW. Example with Solution 1 ======================= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Outer VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = TRILL | V |M|RSD|EH-length| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Nickname | Egress RBridge Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | InnerSource MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Inner VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Ethernet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TRILL Encapsulation over Ethernet with Solution 1 Example with Solution 2 ======================= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Outer VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = TRILL | V |M|S| RSD | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSD | EH-length | UP |C| Inner VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Nickname | Egress RBridge Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | InnerSource MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Ethernet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TRILL Encapsulation over Ethernet with Solution 2 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 l3QJfrP1002933 for <Rbridge@postel.org>; Thu, 26 Apr 2007 12:41:54 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 26 Apr 2007 12:41:40 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D8E7A2B0; Thu, 26 Apr 2007 12:41:40 -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 C446C2AF; Thu, 26 Apr 2007 12:41:40 -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 FGB28223; Thu, 26 Apr 2007 12:41: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 50A9D69CA3; Thu, 26 Apr 2007 12:41:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Apr 2007 12:41:26 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0398C249@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <3870C46029D1F945B1472F170D2D97900274342B@de01exm64.ds.mot.com> Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHngAAGsXvAAASz28AAL6XcQAC7FlVA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, Rbridge@postel.org X-WSS-ID: 6A2FDFFE38G22151972-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 l3QJfrP1002933 Subject: Re: [rbridge] Rbridge port security 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, 26 Apr 2007 19:42:56 -0000 Status: RO Content-Length: 2074 rbridge-bounces@postel.org wrote: > Hi Eric, > > There are IESG members who will be intent on assuring that > Rbridges are manageable and have reasonable provisions for > security and I tend to agree with them. See below at @@@. > That's valid, and we can provide security guidance even before deployment (although Eric raised a valid point on the exact wording of that advice). My main concern is that we do allow multiple methods of achieving the goal of only accepting RBridge encapsulated traffic on ports where it is reasonable for a known RBridge to have sent them. Specifically, as part of its overall RBridge/Bridge functionality, an RBridge MAY already have anti-spoofing protections that guard against ANY frame arriving on a port that is inconsistent with the source address of the frame. Further, I believe it is a safe statement that any network middlebox is always free to choose not to associate with other network elements when the local configuration indicates that it would be unsafe or against administrative policy to do so. Therefore, without needing to add something to the protocol specifications, I believe an RBridge could already be configured with instructions that amount to "join NO RBRidge-collective that claims to have RBridges on port X", or "port X support is limited to at most N MAC addresses, none of which may be an RBridge", or even "only the following MAC addresses are supported on port x". That implies that a totally safe method of controlling where RBridges can exist could be implemented with all of the *additional* security checking being done during RBridge discovery. *Existing* per-frame anti-spoofing techniques would not need to be enhanced, no matter how slightly. Shifting from MUST to SHOULD does't really solve the problem. I would argue that an RBridge SHOULD NOT perform per-frame security checks that are completely redundant. If the per-frame checks are generalize anti-spoofing checks then there is an equivalent security measure in place then there is no point in also doing redundant per-frame checks. 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 l3QIdbLH012568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Thu, 26 Apr 2007 11:39:37 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l3QIeEjF005146; Thu, 26 Apr 2007 13:40:14 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:39:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Apr 2007 13:39:28 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFCC7F7F@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D97900274342B@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHngAAGsXvAAASz28AAL6XcQAColVvA= References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D9790027049B6@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC9290A@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D97900274342B@de01exm64.ds.mot.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 26 Apr 2007 18:39:34.0516 (UTC) FILETIME=[3C52F340:01C78832] 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 l3QIdbLH012568 Subject: Re: [rbridge] Rbridge port security 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, 26 Apr 2007 18:40:23 -0000 Status: RO Content-Length: 10499 Donald, Specific excerpts from your response below: @@@ I don't buy that we have to deploy Rbridges and have experience before we specify some basic security provisions. Good, because I ain't sellin' it. For control plane activities, we have 4 things to consider (and address) in the interactions between RBridges: 1. IS-IS (as extended) interactions - presumably we will not define new security mechanisms (in TRILL) that apply more generally to IS-IS. 2. Bridge control interactions - we WILL NOT define security mechanisms that apply to this general area, whatever the IESG may, or may not, feel about existing L2 exposures. 3. Merged bridging and IS-IS interactions that introduce new vulnerabilities not encountered previously. 4. Other vulnerabilities introduced in RBridge interactions not specifically related to either bridging or IS-IS. It cannot be over-emphasized that it is only in interactions between RBridges that any of these things become relevant in defining RBridge control protocol specifications, including those relating to security. Items 3 and 4 above are the areas where we will need to say something directly about security - both what the risks are and how we feel they might be addressed. But what we say is likely to be largely based on a SWAG - except where we may have experience in interactions between multiple RBridges, built by multiple RBridge vendors. To think otherwise, is - IMO - overly optimistic. Hence, what we say should be said with this in mind; i.e. - we need to state what we think the issues will be, but also acknowledge that the list is likely to be incomplete. AND we need to propose mechanisms that address at least those parts of any specific security solution that are related to how a set of RBridges need to interact with each other in dealing with the issues we know about. There is nothing in any of this that implies we should not define "basic security provisions." @@@ I don't think the Architecture draft needs many details. Nor do all the details necessarily have to be in a successor to the current protocol specification as there could be a separate document on management. Agree. @@@ I think that if we want to get it approved for publication, the Architecture document will have to say what protocol we expect to be used to manage RBridges, e.g., SNMP, and may have to say how we expect them to be configured, e.g., via a TRILL MIB. Possibly, but I believe it is safe to say that this is a new requirement of architecture documents, assuming it is a requirement even now. I don't know - off hand - of a single architecture document in the RFC database right now that addresses this aspect of a device or solution architecture. I looked at a number of them, just to make sure I hadn't missed out on this aspect in existing architecture RFCs, and found exactly one single example of an architecture RFC that says anything specific about how a protocol is going to be managed. The ones I looked at included at least a dozen of the most recent RFCs on architecture. The exception was RFC 4655 - which has an experimental "manageability section" and includes an operational model explicitly based on use of a network management system. That RFC does not mention SNMP, but it does state that there must be a (one or more) management MIB(s) for managing the system that architecture defines. The inclusion of manageability considerations is based on an "experiment" that is currently in Internet Draft form, and that (currently) addresses PCE documents only. I believe that there is no requirement for us to include such a section (at present) and that doing so requires a consensus from the working group (to include that same section in all working group documents). Hence, I am inclined to believe that any IESG member who proposes to make this a major issue is simply being a tad on the capricious side... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake@motorola.com] > Sent: Wednesday, April 25, 2007 11:15 PM > To: Eric Gray (LO/EUS); Rbridge@postel.org > Subject: RE: [rbridge] Rbridge port security > Importance: High > > Hi Eric, > > There are IESG members who will be intent on assuring that > Rbridges are > manageable and have reasonable provisions for security and I tend to > agree with them. See below at @@@. > > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 25, 2007 11:33 AM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: RE: [rbridge] Rbridge port security > > Donald, > > I can't say that I understand why. Is there nothing along > the same lines in any of the IS-IS specifications? If there is > not, why are we expected to make statements about IS-IS security > that are likely to apply to a more general problem? If there is, > cannot we simply refer to that? > > @@@ IS-IS might be the biggest component an RBridge but it is > not all of > it. The concern will be with the management and security of Rbridges, > not just of their IS-IS component. > > @@@ Looks like the IS-IS MIB is in RFC 4444. It's probably pretty > thorough. At least the RFC is over 100 pages :-) If it covers this > point, of course we could just reference it. Looks like 802.1 bridge > MIBs are in RFC 4188 and RFC 4363. If someone is familiar with these > MIBs, or is willing to read them and comment on their applicability to > TRILL, I think that would be very useful for this working group. > > While I tend to agree that there should be a general way to > manage devices to accomplish identical results - rather than ask > each vendor to come up with their own and all users/operators to > deal with the associated complexity. But, as Silvano indicated, > this may not be done the same way for each vendor and - more > importantly - we are not in an experiential position to guess (at > this point) what way is the best way to handle this particular > set of security issues... > > @@@ I don't buy that we have to deploy Rbridges and have experience > before we specify some basic security provisions. > > @@@ I think that if we want to get it approved for publication, the > Architecture document will have to say what protocol we expect to be > used to manage RBridges, e.g., SNMP, and may have to say how we expect > them to be configured, e.g., via a TRILL MIB. We already have at least > one new per-Rbridge configuration variable, called RequestTree in > protocol draft -03. > > @@@ I don't think the Architecture draft needs many details. > Nor do all > the details necessarily have to be in a successor to the current > protocol specification as there could be a separate document on > management. > > @@@ Thanks, > @@@ Donald > > Thanks! > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: Eastlake III Donald-LDE008 > > [mailto:Donald.Eastlake@motorola.com] > > Sent: Wednesday, April 25, 2007 11:15 AM > > To: Eric Gray (LO/EUS); Rbridge@postel.org > > Subject: RE: [rbridge] Rbridge port security > > Importance: High > > > > Eric, > > > > Sure, we don't want to get too bogged down in details. On the other > > hand, while some of the IESG comments on the routing requirements > > document seem to be based on a misunderstanding of the > purpose of that > > document, I still feel that security and management will both be a > > primary concerns for the architecture and protocol documents. > > > > Our charter requirement of "zero or minimal" configuration is > > helpful in > > motivating a default configuration for Rbridges which has security > > weaknesses that parallel those of unmanaged bridges. However, > > I think we > > are going to have to say something about management and > provide for a > > standard way to configure Rbridges to provide at least the suggested > > ability to not run IS-IS on selected ports. > > > > Donald > > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > Sent: Wednesday, April 25, 2007 10:09 AM > > To: Eastlake III Donald-LDE008; Rbridge@postel.org > > Subject: RE: [rbridge] Rbridge port security > > > > Donald, > > > > In the past, it has not been necessary to explicitly state > > this sort of thing, except in some general way. Otherwise, it is > > easy to get snarled up in phraseology around things like "RBridge > > enabled ports" and so on. > > > > As an historical example (I am sure there are others), the > > concept of global label spaces in MPLS is intended to be similarly > > constrained. > > > > To a certain extent, we don't want to get wrapped up around > > an axle in trying to tell people how to build good implementations > > - our focus should be on interoperable implementations, right? > > > > Thanks! > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > > Donald-LDE008 > > > Sent: Friday, April 20, 2007 3:53 PM > > > To: Rbridge@postel.org > > > Subject: [rbridge] Rbridge port security > > > > > > Hi, > > > > > > I'm continuing to work through the comments on our first > > > document to hit > > > the IESG, the routing requirements document. > > > > > > Based on these, I would say that we have to add a per port > > > configuration > > > variable for Rbridges that indicates there are no Rbridges > > > connected via > > > that port. The effect would be that any TRILL frames > > arriving on that > > > port would be assumed to be forged and would be discarded. > > This would > > > include frames claiming to be core or per-VLAN IS-IS messages > > > as well as > > > messages that claim to be TRILL encapsulated frames. Of > > > course, the zero > > > configuration default would be to accept TRILL frames on > all ports. > > > > > > Unless there is some objection, this will be added to the protocol > > > specification and should probably be mentioned in the architecture > > > document. > > > > > > Thanks, > > > Donald > > > > > > _______________________________________________ > > > 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 l3QIQK1j009410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 26 Apr 2007 11:26:21 -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 l3QIQxu8001541; Thu, 26 Apr 2007 13:26:59 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:26:18 -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, 26 Apr 2007 13:26:12 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFCC7F63@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <39BA3BC178B4394DB184389E88A97F8C022C5796@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAFDs4AQlSv2QABs1FhA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467AF0@nuova-ex1.hq.nuovaimpresa.com> <39BA3BC178B4394DB184389E88A97F8C022C5796@hq-exch-1.corp.brocade.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Anoop Ghanwani" <anoop@brocade.com>, "J. R. Rivers" <jrrivers@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 26 Apr 2007 18:26:18.0860 (UTC) FILETIME=[62137AC0:01C78830] 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 l3QIQK1j009410 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 26 Apr 2007 18:26:43 -0000 Status: RO Content-Length: 2619 Anoop, There are (at least) two possible interpretations of what is meant by "multi-pathing." One is the sort of multipathing that is roughly analogous to either link-bundling (at L2) or ECMP (usually for L3 routing). The other is the sort that has to do with the more general form of "load-sharing" - i.e. - simply trying to ensure that all possible links are being used, roughly at some proportional ratio relative to their capacities. This form of multi-pathing is not dependent on multiple-path use for essentially the same traffic (i.e. - as defined by edge-to-edge unidirectional forwarding). I believe that many people (especially those who are not completely up to speed on - for example - MSTP) are thinking of the second form of "multi-pathing" when they refer to this term. When using MSTP, there are no unused links and load-sharing is a natural consequence of the assignment of VIDs on the basis of separate spanning tree instances. As you may know, there are problems that must be addressed in using the first form of multi-pathing scheme if we need to be able to maintain forwarding symmetry on an end-point pair basis. These difficulties are reduced by using a hierarchical (tunneled) overlay with RBridges, but they are not eliminated... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@brocade.com] > Sent: Tuesday, April 24, 2007 9:14 PM > To: J. R. Rivers; Caitlin Bestler; Silvano Gai; Eric Gray > (LO/EUS); Radia Perlman; rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > Importance: High > > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of J. R. Rivers > > Sent: Tuesday, April 03, 2007 3:47 PM > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > Perlman; rbridge@postel.org > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > > > > I would have thought that RBridges are "better bridges" > > because they allow multi-pathing at layer 2 creating > > significantly more available bandwidth and with a deployment > > cost/complexity relatively close to > > 802.1 bridges. > > Is TRILL going to solve the multipathing problem? > > From > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r > eqs-02.txt > However, support for multi-pathing is potentially > problematic and is > assumed - in this document - to be a non-goal. Multi-path > forwarding > has the potential to confound the bridge learning process. > > Anoop > Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3QIIUfG007294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 26 Apr 2007 11:18:30 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l3QIJ6oH031988; Thu, 26 Apr 2007 13:19:07 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:18:26 -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, 26 Apr 2007 13:18:20 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFCC7F4E@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <46302330.2020500@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: AceHtvra7VJqZ66wTbCFPhYfRGekuwAd+NKw References: <39BA3BC178B4394DB184389E88A97F8C022C5796@hq-exch-1.corp.brocade.com> <46302330.2020500@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Anoop Ghanwani" <anoop@brocade.com> X-OriginalArrivalTime: 26 Apr 2007 18:18:26.0743 (UTC) FILETIME=[48AC2470:01C7882F] 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 l3QIIUfG007294 Cc: rbridge@postel.org Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 26 Apr 2007 18:19:27 -0000 Status: RO Content-Length: 974 Radia, I started to reply to Anoop, but decided to hold of because this is a complicated discussion and there are more than enough of those going around. The issue is that not all of us mean the same thing when we say "multi-pathing." I guess I will fire of my response to Anoop after all... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Wednesday, April 25, 2007 11:58 PM > To: Anoop Ghanwani > Cc: J. R. Rivers; Caitlin Bestler; Silvano Gai; Eric Gray > (LO/EUS); rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > Anoop Ghanwani wrote: > > Is TRILL going to solve the multipathing problem? > Multipathing comes "for free" because of using layer 3 routing > technology. Whatever > capabilities IS-IS has for routing to a destination can be used for > routing to the > egress RBridge. > > So the answer is yes. > > 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 l3Q3vD6E004807 for <rbridge@postel.org>; Wed, 25 Apr 2007 20:57:14 -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 <0JH3002DD6ZBRA00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 25 Apr 2007 20:57:11 -0700 (PDT) Received: from [127.0.0.1] ([129.150.17.144]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JH300FVH6ZADF00@mail.sunlabs.com> for rbridge@postel.org; Wed, 25 Apr 2007 20:57:11 -0700 (PDT) Date: Wed, 25 Apr 2007 20:57:36 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <39BA3BC178B4394DB184389E88A97F8C022C5796@hq-exch-1.corp.brocade.com> To: Anoop Ghanwani <anoop@brocade.com> Message-id: <46302330.2020500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <39BA3BC178B4394DB184389E88A97F8C022C5796@hq-exch-1.corp.brocade.com> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 26 Apr 2007 03:57:19 -0000 Status: RO Content-Length: 289 Anoop Ghanwani wrote: > Is TRILL going to solve the multipathing problem? Multipathing comes "for free" because of using layer 3 routing technology. Whatever capabilities IS-IS has for routing to a destination can be used for routing to the egress RBridge. So the answer is yes. Radia Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l3Q3EvHw025476 for <Rbridge@postel.org>; Wed, 25 Apr 2007 20:14:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1177557293!19981586!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27861 invoked from network); 26 Apr 2007 03:14:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 26 Apr 2007 03:14:54 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3Q3EnLv008604 for <Rbridge@postel.org>; Wed, 25 Apr 2007 20:14:53 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l3Q3En6S009439 for <Rbridge@postel.org>; Wed, 25 Apr 2007 22:14:49 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3Q3Emra009429 for <Rbridge@postel.org>; Wed, 25 Apr 2007 22:14:48 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Apr 2007 23:14:48 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900274342B@de01exm64.ds.mot.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFC9290A@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security thread-index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHngAAGsXvAAASz28AAL6XcQ References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D9790027049B6@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC9290A@eusrcmw721.eamcs.ericsson.se> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, <Rbridge@postel.org> X-Vontu: Pass 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 l3Q3EvHw025476 Subject: Re: [rbridge] Rbridge port security 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, 26 Apr 2007 03:15:24 -0000 Status: RO Content-Length: 5817 Hi Eric, There are IESG members who will be intent on assuring that Rbridges are manageable and have reasonable provisions for security and I tend to agree with them. See below at @@@. -----Original Message----- From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] Sent: Wednesday, April 25, 2007 11:33 AM To: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: RE: [rbridge] Rbridge port security Donald, I can't say that I understand why. Is there nothing along the same lines in any of the IS-IS specifications? If there is not, why are we expected to make statements about IS-IS security that are likely to apply to a more general problem? If there is, cannot we simply refer to that? @@@ IS-IS might be the biggest component an RBridge but it is not all of it. The concern will be with the management and security of Rbridges, not just of their IS-IS component. @@@ Looks like the IS-IS MIB is in RFC 4444. It's probably pretty thorough. At least the RFC is over 100 pages :-) If it covers this point, of course we could just reference it. Looks like 802.1 bridge MIBs are in RFC 4188 and RFC 4363. If someone is familiar with these MIBs, or is willing to read them and comment on their applicability to TRILL, I think that would be very useful for this working group. While I tend to agree that there should be a general way to manage devices to accomplish identical results - rather than ask each vendor to come up with their own and all users/operators to deal with the associated complexity. But, as Silvano indicated, this may not be done the same way for each vendor and - more importantly - we are not in an experiential position to guess (at this point) what way is the best way to handle this particular set of security issues... @@@ I don't buy that we have to deploy Rbridges and have experience before we specify some basic security provisions. @@@ I think that if we want to get it approved for publication, the Architecture document will have to say what protocol we expect to be used to manage RBridges, e.g., SNMP, and may have to say how we expect them to be configured, e.g., via a TRILL MIB. We already have at least one new per-Rbridge configuration variable, called RequestTree in protocol draft -03. @@@ I don't think the Architecture draft needs many details. Nor do all the details necessarily have to be in a successor to the current protocol specification as there could be a separate document on management. @@@ Thanks, @@@ Donald Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake@motorola.com] > Sent: Wednesday, April 25, 2007 11:15 AM > To: Eric Gray (LO/EUS); Rbridge@postel.org > Subject: RE: [rbridge] Rbridge port security > Importance: High > > Eric, > > Sure, we don't want to get too bogged down in details. On the other > hand, while some of the IESG comments on the routing requirements > document seem to be based on a misunderstanding of the purpose of that > document, I still feel that security and management will both be a > primary concerns for the architecture and protocol documents. > > Our charter requirement of "zero or minimal" configuration is > helpful in > motivating a default configuration for Rbridges which has security > weaknesses that parallel those of unmanaged bridges. However, > I think we > are going to have to say something about management and provide for a > standard way to configure Rbridges to provide at least the suggested > ability to not run IS-IS on selected ports. > > Donald > > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 25, 2007 10:09 AM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: RE: [rbridge] Rbridge port security > > Donald, > > In the past, it has not been necessary to explicitly state > this sort of thing, except in some general way. Otherwise, it is > easy to get snarled up in phraseology around things like "RBridge > enabled ports" and so on. > > As an historical example (I am sure there are others), the > concept of global label spaces in MPLS is intended to be similarly > constrained. > > To a certain extent, we don't want to get wrapped up around > an axle in trying to tell people how to build good implementations > - our focus should be on interoperable implementations, right? > > Thanks! > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Friday, April 20, 2007 3:53 PM > > To: Rbridge@postel.org > > Subject: [rbridge] Rbridge port security > > > > Hi, > > > > I'm continuing to work through the comments on our first > > document to hit > > the IESG, the routing requirements document. > > > > Based on these, I would say that we have to add a per port > > configuration > > variable for Rbridges that indicates there are no Rbridges > > connected via > > that port. The effect would be that any TRILL frames > arriving on that > > port would be assumed to be forged and would be discarded. > This would > > include frames claiming to be core or per-VLAN IS-IS messages > > as well as > > messages that claim to be TRILL encapsulated frames. Of > > course, the zero > > configuration default would be to accept TRILL frames on all ports. > > > > Unless there is some objection, this will be added to the protocol > > specification and should probably be mentioned in the architecture > > document. > > > > Thanks, > > Donald > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3PFWmNu027347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 25 Apr 2007 08:32:48 -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 l3PFVm0m013530; Wed, 25 Apr 2007 10:31:48 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 10:32:46 -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, 25 Apr 2007 10:32:43 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFC9290A@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D9790027049B6@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHngAAGsXvAAASz28A== References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D9790027049B6@de01exm64.ds.mot.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 25 Apr 2007 15:32:46.0088 (UTC) FILETIME=[F92AD080:01C7874E] 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 l3PFWmNu027347 Subject: Re: [rbridge] Rbridge port security 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, 25 Apr 2007 15:33:34 -0000 Status: RO Content-Length: 4097 Donald, I can't say that I understand why. Is there nothing along the same lines in any of the IS-IS specifications? If there is not, why are we expected to make statements about IS-IS security that are likely to apply to a more general problem? If there is, cannot we simply refer to that? While I tend to agree that there should be a general way to manage devices to accomplish identical results - rather than ask each vendor to come up with their own and all users/operators to deal with the associated complexity. But, as Silvano indicated, this may not be done the same way for each vendor and - more importantly - we are not in an experiential position to guess (at this point) what way is the best way to handle this particular set of security issues... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake@motorola.com] > Sent: Wednesday, April 25, 2007 11:15 AM > To: Eric Gray (LO/EUS); Rbridge@postel.org > Subject: RE: [rbridge] Rbridge port security > Importance: High > > Eric, > > Sure, we don't want to get too bogged down in details. On the other > hand, while some of the IESG comments on the routing requirements > document seem to be based on a misunderstanding of the purpose of that > document, I still feel that security and management will both be a > primary concerns for the architecture and protocol documents. > > Our charter requirement of "zero or minimal" configuration is > helpful in > motivating a default configuration for Rbridges which has security > weaknesses that parallel those of unmanaged bridges. However, > I think we > are going to have to say something about management and provide for a > standard way to configure Rbridges to provide at least the suggested > ability to not run IS-IS on selected ports. > > Donald > > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 25, 2007 10:09 AM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: RE: [rbridge] Rbridge port security > > Donald, > > In the past, it has not been necessary to explicitly state > this sort of thing, except in some general way. Otherwise, it is > easy to get snarled up in phraseology around thinsg like "RBridge > enabled ports" and so on. > > As an historical example (I am sure there are others), the > concept of global label spaces in MPLS is intended to be similarly > constrained. > > To a certain extent, we don't want to get wrapped up around > an axle in trying to tell people how to build good implementations > - our focus should be on interoperable implementations, right? > > Thanks! > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Friday, April 20, 2007 3:53 PM > > To: Rbridge@postel.org > > Subject: [rbridge] Rbridge port security > > > > Hi, > > > > I'm continuing to work through the comments on our first > > document to hit > > the IESG, the routing requirements document. > > > > Based on these, I would say that we have to add a per port > > configuration > > variable for Rbridges that indicates there are no Rbridges > > connected via > > that port. The effect would be that any TRILL frames > arriving on that > > port would be assumed to be forged and would be discarded. > This would > > include frames claiming to be core or per-VLAN IS-IS messages > > as well as > > messages that claim to be TRILL encapsulated frames. Of > > course, the zero > > configuration default would be to accept TRILL frames on all ports. > > > > Unless there is some objection, this will be added to the protocol > > specification and should probably be mentioned in the architecture > > document. > > > > Thanks, > > Donald > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l3PFF5hd022383 for <Rbridge@postel.org>; Wed, 25 Apr 2007 08:15:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1177514104!8447768!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12945 invoked from network); 25 Apr 2007 15:15:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 25 Apr 2007 15:15:04 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3PFF4vL023117 for <Rbridge@postel.org>; Wed, 25 Apr 2007 08:15:04 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3PFF3Pv025864 for <Rbridge@postel.org>; Wed, 25 Apr 2007 10:15:03 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3PFF3A3025844 for <Rbridge@postel.org>; Wed, 25 Apr 2007 10:15:03 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Apr 2007 11:14:57 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790027049B6@de01exm64.ds.mot.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security thread-index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHngAAGsXvA= References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, <Rbridge@postel.org> X-Vontu: Pass 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 l3PFF5hd022383 Subject: Re: [rbridge] Rbridge port security 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, 25 Apr 2007 15:15:55 -0000 Status: RO Content-Length: 2832 Eric, Sure, we don't want to get too bogged down in details. On the other hand, while some of the IESG comments on the routing requirements document seem to be based on a misunderstanding of the purpose of that document, I still feel that security and management will both be a primary concerns for the architecture and protocol documents. Our charter requirement of "zero or minimal" configuration is helpful in motivating a default configuration for Rbridges which has security weaknesses that parallel those of unmanaged bridges. However, I think we are going to have to say something about management and provide for a standard way to configure Rbridges to provide at least the suggested ability to not run IS-IS on selected ports. Donald -----Original Message----- From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] Sent: Wednesday, April 25, 2007 10:09 AM To: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: RE: [rbridge] Rbridge port security Donald, In the past, it has not been necessary to explicitly state this sort of thing, except in some general way. Otherwise, it is easy to get snarled up in phraseology around thinsg like "RBridge enabled ports" and so on. As an historical example (I am sure there are others), the concept of global label spaces in MPLS is intended to be similarly constrained. To a certain extent, we don't want to get wrapped up around an axle in trying to tell people how to build good implementations - our focus should be on interoperable implementations, right? Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, April 20, 2007 3:53 PM > To: Rbridge@postel.org > Subject: [rbridge] Rbridge port security > > Hi, > > I'm continuing to work through the comments on our first > document to hit > the IESG, the routing requirements document. > > Based on these, I would say that we have to add a per port > configuration > variable for Rbridges that indicates there are no Rbridges > connected via > that port. The effect would be that any TRILL frames arriving on that > port would be assumed to be forged and would be discarded. This would > include frames claiming to be core or per-VLAN IS-IS messages > as well as > messages that claim to be TRILL encapsulated frames. Of > course, the zero > configuration default would be to accept TRILL frames on all ports. > > Unless there is some objection, this will be added to the protocol > specification and should probably be mentioned in the architecture > document. > > Thanks, > Donald > > _______________________________________________ > 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 l3PEpGdE015447 for <Rbridge@postel.org>; Wed, 25 Apr 2007 07:51:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Apr 2007 07:51:08 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2015E35B8@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHngAAGBtCA= References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.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 l3PEpGdE015447 Subject: Re: [rbridge] Rbridge port security 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, 25 Apr 2007 14:51:31 -0000 Status: RO Content-Length: 2671 I agree with Eric, I am not sure I want to specify a specific port configuration variable for this particular case. Products will implement this through a potentially more complex scheme that may include trusted/non-trusted ports/VLANs, authentications, ACLs, etc. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eric Gray (LO/EUS) > Sent: Wednesday, April 25, 2007 7:09 AM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: Re: [rbridge] Rbridge port security > > Donald, > > In the past, it has not been necessary to explicitly state > this sort of thing, except in some general way. Otherwise, it is > easy to get snarled up in phraseology around thinsg like "RBridge > enabled ports" and so on. > > As an historical example (I am sure there are others), the > concept of global label spaces in MPLS is intended to be similarly > constrained. > > To a certain extent, we don't want to get wrapped up around > an axle in trying to tell people how to build good implementations > - our focus should be on interoperable implementations, right? > > Thanks! > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Friday, April 20, 2007 3:53 PM > > To: Rbridge@postel.org > > Subject: [rbridge] Rbridge port security > > > > Hi, > > > > I'm continuing to work through the comments on our first > > document to hit > > the IESG, the routing requirements document. > > > > Based on these, I would say that we have to add a per port > > configuration > > variable for Rbridges that indicates there are no Rbridges > > connected via > > that port. The effect would be that any TRILL frames arriving on that > > port would be assumed to be forged and would be discarded. This would > > include frames claiming to be core or per-VLAN IS-IS messages > > as well as > > messages that claim to be TRILL encapsulated frames. Of > > course, the zero > > configuration default would be to accept TRILL frames on all ports. > > > > Unless there is some objection, this will be added to the protocol > > specification and should probably be mentioned in the architecture > > document. > > > > Thanks, > > Donald > > > > _______________________________________________ > > rbridge mailing list > > rbridge@postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3PE9ONk003237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 25 Apr 2007 07:09:24 -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 l3PE8NZT031994; Wed, 25 Apr 2007 09:08:23 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 09:09:20 -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, 25 Apr 2007 09:09:19 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFC927E3@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwDvSHng References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 25 Apr 2007 14:09:20.0832 (UTC) FILETIME=[51CD5C00:01C78743] 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 l3PE9ONk003237 Subject: Re: [rbridge] Rbridge port security 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, 25 Apr 2007 14:09:58 -0000 Status: RO Content-Length: 1862 Donald, In the past, it has not been necessary to explicitly state this sort of thing, except in some general way. Otherwise, it is easy to get snarled up in phraseology around thinsg like "RBridge enabled ports" and so on. As an historical example (I am sure there are others), the concept of global label spaces in MPLS is intended to be similarly constrained. To a certain extent, we don't want to get wrapped up around an axle in trying to tell people how to build good implementations - our focus should be on interoperable implementations, right? Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, April 20, 2007 3:53 PM > To: Rbridge@postel.org > Subject: [rbridge] Rbridge port security > > Hi, > > I'm continuing to work through the comments on our first > document to hit > the IESG, the routing requirements document. > > Based on these, I would say that we have to add a per port > configuration > variable for Rbridges that indicates there are no Rbridges > connected via > that port. The effect would be that any TRILL frames arriving on that > port would be assumed to be forged and would be discarded. This would > include frames claiming to be core or per-VLAN IS-IS messages > as well as > messages that claim to be TRILL encapsulated frames. Of > course, the zero > configuration default would be to accept TRILL frames on all ports. > > Unless there is some objection, this will be added to the protocol > specification and should probably be mentioned in the architecture > document. > > Thanks, > Donald > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l3PDvskh000019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <Rbridge@postel.org>; Wed, 25 Apr 2007 06:57:55 -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 l3PDurXK029640; Wed, 25 Apr 2007 08:56:53 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 08:57:51 -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, 25 Apr 2007 08:57:49 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFC927B6@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D038B3EE6@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwAAZDSgAAz3CMAAgboSQABf8juA References: <3870C46029D1F945B1472F170D2D9790026C332E@de01exm64.ds.mot.com> <1EF1E44200D82B47BD5BA61171E8CE9D038B3EE6@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <Rbridge@postel.org> X-OriginalArrivalTime: 25 Apr 2007 13:57:51.0352 (UTC) FILETIME=[B6D70F80:01C78741] 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 l3PDvskh000019 Subject: Re: [rbridge] Rbridge port security 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, 25 Apr 2007 13:58:26 -0000 Status: RO Content-Length: 1109 Caitlin, We need to be careful at this point about what we claim to know will work... :-) Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler > Sent: Monday, April 23, 2007 12:13 PM > To: Eastlake III Donald-LDE008; Rbridge@postel.org > Subject: Re: [rbridge] Rbridge port security > > Eastlake III Donald-LDE008 wrote: > > > > > @@@ I would have no problems with using "SHOULD" for the > > default of running the core IS-IS and most of this, with an > > example of an exception being a special purpose device where > > you have additional knowledge. > > > > @@@ Thanks, > > @@@ Donald > > I could even see a requirement that there MUST be a method > that once enabled can ensure that no RBridge enapsulated > will be accepted via RBridge-disabled ports, and that two > mechanisms known to achieve this are... > > > _______________________________________________ > 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 l3P1FeDf008675 for <rbridge@postel.org>; Tue, 24 Apr 2007 18:15:40 -0700 (PDT) Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 24 Apr 2007 18:15:39 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="9435092:sNHT15453669" Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 9317F23836B; Tue, 24 Apr 2007 18:14:30 -0700 (PDT) Received: from hq-exch-1.corp.brocade.com ([10.3.8.21]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 18:15:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 24 Apr 2007 18:14:18 -0700 Message-ID: <39BA3BC178B4394DB184389E88A97F8C022C5796@hq-exch-1.corp.brocade.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467AF0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAFDs4AQlSv2Q From: "Anoop Ghanwani" <anoop@brocade.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 25 Apr 2007 01:15:37.0880 (UTC) FILETIME=[3B910980:01C786D7] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l3P1FeDf008675 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 25 Apr 2007 01:16:07 -0000 Status: RO Content-Length: 916 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of J. R. Rivers > Sent: Tuesday, April 03, 2007 3:47 PM > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > I would have thought that RBridges are "better bridges" > because they allow multi-pathing at layer 2 creating > significantly more available bandwidth and with a deployment > cost/complexity relatively close to > 802.1 bridges. Is TRILL going to solve the multipathing problem? From http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt However, support for multi-pathing is potentially problematic and is assumed - in this document - to be a non-goal. Multi-path forwarding has the potential to confound the bridge learning process. Anoop 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 l3NGDDN8011162 for <Rbridge@postel.org>; Mon, 23 Apr 2007 09:13:13 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 23 Apr 2007 09:12:56 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E0E782AF; Mon, 23 Apr 2007 09:12: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 CC7B32AE; Mon, 23 Apr 2007 09:12: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 FFS69979; Mon, 23 Apr 2007 09:12:51 -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 4BB0069CA4; Mon, 23 Apr 2007 09:12:51 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Apr 2007 09:12:38 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D038B3EE6@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790026C332E@de01exm64.ds.mot.com> Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwAAZDSgAAz3CMAAgboSQA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, Rbridge@postel.org X-WSS-ID: 6A32048237021058611-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 l3NGDDN8011162 Subject: Re: [rbridge] Rbridge port security 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, 23 Apr 2007 16:14:41 -0000 Status: RO Content-Length: 502 Eastlake III Donald-LDE008 wrote: > > @@@ I would have no problems with using "SHOULD" for the > default of running the core IS-IS and most of this, with an > example of an exception being a special purpose device where > you have additional knowledge. > > @@@ Thanks, > @@@ Donald I could even see a requirement that there MUST be a method that once enabled can ensure that no RBridge enapsulated will be accepted via RBridge-disabled ports, and that two mechanisms known to achieve this are... 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 l3LKnGLh010730 for <Rbridge@postel.org>; Sat, 21 Apr 2007 13:49:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1177188552!20622516!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 14765 invoked from network); 21 Apr 2007 20:49:12 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-2.tower-119.messagelabs.com with SMTP; 21 Apr 2007 20:49:12 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l3LKnBOe013320 for <Rbridge@postel.org>; Sat, 21 Apr 2007 13:49:11 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3LKnAZ6009262 for <Rbridge@postel.org>; Sat, 21 Apr 2007 15:49:11 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 21 Apr 2007 16:49:08 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790026C332E@de01exm64.ds.mot.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D038B3B67@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Rbridge port security thread-index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwAAZDSgAAz3CMA= References: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> <1EF1E44200D82B47BD5BA61171E8CE9D038B3B67@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, <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 l3LKnGLh010730 Subject: Re: [rbridge] Rbridge port security 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, 21 Apr 2007 20:49:31 -0000 Status: RO Content-Length: 5144 Hi Caitlin, See below at @@@ -----Original Message----- From: Caitlin Bestler [mailto:caitlinb@broadcom.com] Sent: Friday, April 20, 2007 4:22 PM To: Eastlake III Donald-LDE008; Rbridge@postel.org Subject: RE: [rbridge] Rbridge port security rbridge-bounces@postel.org wrote: > Hi, > > I'm continuing to work through the comments on our first > document to hit the IESG, the routing requirements document. > > Based on these, I would say that we have to add a per port > configuration variable for Rbridges that indicates there are > no Rbridges connected via that port. The effect would be that > any TRILL frames arriving on that port would be assumed to be > forged and would be discarded. This would include frames > claiming to be core or per-VLAN IS-IS messages as well as > messages that claim to be TRILL encapsulated frames. Of > course, the zero configuration default would be to accept TRILL > frames on all ports. @@@ My message should have also said that IS-IS messages are not emitted. (It does not need to say that TRILL encapsulated messages are not emitted since an RBridge should never do that if it has not detected any Rbridges out that port and it can't detect them if it doesn't receive and emit IS-IS Hellos.) Probably the better way to say all this is that it doesn't run the core IS-IS instance on that port. > Unless there is some objection, this will be added to the > protocol specification and should probably be mentioned in the > architecture document. > > Thanks, > Donald Two questions: Would the default be that a port was allowed to have RBridge encapsulated traffic on it? Given the zero- configuration intent I think that default needs to be made explicit. @@@ Sure. The default has to be such that Rbridges will provide their intended service. Secondly, does this really need to be a per-frame check that is specific to RBridge traffic? Wouldn't the following be sufficient? An implementation MAY have configuration constraints on the results of RBridge discovery. Possible examples could include "discovered topology MUST be a subset of the pre-configured topology", "all discovered RBridges MUST be no more than 2 hops from X", "at most N RBridges", etc. And it SHOULD/MUST include the ability to configure ports that do not lead to other RBridges. Each RBridge MAY/SHOULD drop frames allegedly from other RBRidges where the ingress port is inconsistent with the discovered topology. That would make the RBridge specific logic pertain only during RBridge discovery, and then allow generic "acceptable ingress port" logic to apply rather than an RBridge specific rule. @@@ I assume by "ingress port" in the two paragraphs above you mean the port on which the Rbridge receives the frame, not the TRILL ingress, which is where a frame gets encapsulated. I would agree that it is also reasonable to drop frames received on a port which the Rbridge believes has no other Rbridges attached to it even if Rbridge discovery isn't configured off for that port. If a given bridge already has anti-spoofing features it wouldn't make much sense to require additional RBridge specific checks. @@@ Well, a bridge isn't an Rbridge and I wasn't proposing to make any changes in bridges. @@@ I believe that bridges sometimes have a per port "anti-spoofing" feature which could be expressed as controlling whether or not *STP runs on that port (i.e., whether it discards any received BPDUs and does not emit any for that port). But such a feature would do nothing to protect against forged TRILL messages. One way or another you have to either expand the "anti-spoofing feature" configuration or add an additional "anti-spoofing feature" which is Rbridge specific. Also, bridges don't encapsulate or modify native frames so it really wouldn't make any sense to say you want to block bridged frames but Rbridges do encapsulate native frames so it is reasonable to block such "Rbridged" frames on ports which are not supposed to have any Rbridges attached to them. @@@ I think the best way to think of the feature I am talking about is controlling whether or not the core instance of IS-IS runs on a port. And to satisfy the eventual security and management considerations review of our protocol draft, there will have to be some standard way to configure this, presumably via SNMP and a standard MIB. For an example, an RBridge built into a piece of equipment could indeed know that its internal "ports" have no RBridges on them. But it might know that because it knows the MAC address associated with each of those ports. It can easily enforce that they are not RBridges during discovery, and it can easily enforce that the only traffic originating on those ports have the correct MAC address. Given those checks, I see no need for such an implementation to dynamically block RBridge encapsulated frames from originating on the internal ports. @@@ I would have no problems with using "SHOULD" for the default of running the core IS-IS and most of this, with an example of an exception being a special purpose device where you have additional knowledge. @@@ Thanks, @@@ Donald 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 l3KKMOdt025650 for <Rbridge@postel.org>; Fri, 20 Apr 2007 13:22:24 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 20 Apr 2007 13:22:11 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id AC6492AF; Fri, 20 Apr 2007 13:22:11 -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 98E872AE; Fri, 20 Apr 2007 13:22: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 FFM52312; Fri, 20 Apr 2007 13:22: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 1703369CA5; Fri, 20 Apr 2007 13:22:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Apr 2007 13:22:02 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D038B3B67@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> Thread-Topic: [rbridge] Rbridge port security Thread-Index: AceDhYb1cypxxsmkTE6hUQzLBFlMvwAAZDSg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, Rbridge@postel.org X-WSS-ID: 6A37FF793A419561660-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 l3KKMOdt025650 Subject: Re: [rbridge] Rbridge port security 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, 20 Apr 2007 20:22:57 -0000 Status: RO Content-Length: 2727 rbridge-bounces@postel.org wrote: > Hi, > > I'm continuing to work through the comments on our first > document to hit the IESG, the routing requirements document. > > Based on these, I would say that we have to add a per port > configuration variable for Rbridges that indicates there are > no Rbridges connected via that port. The effect would be that > any TRILL frames arriving on that port would be assumed to be > forged and would be discarded. This would include frames > claiming to be core or per-VLAN IS-IS messages as well as > messages that claim to be TRILL encapsulated frames. Of > course, the zero configuration default would be to accept TRILL > frames on all ports. > > Unless there is some objection, this will be added to the > protocol specification and should probably be mentioned in the > architecture document. > > Thanks, > Donald > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Two questions: Would the default be that a port was allowed to have RBridge encapsulated traffic on it? Given the zero- configuration intent I think that default needs to be made explicit. Secondly, does this really need to be a per-frame check that is specific to RBridge traffic? Wouldn't the following be sufficient? An implementation MAY have configuration constraints on the results of RBridge discovery. Possible examples could include "discovered topology MUST be a subset of the pre-configured topoloty", "all discovered RBridges MUST be no more than 2 hops from X", "at most N RBridges", etc. And it SHOULD/MUST include the ability to configure ports that do not lead to other RBridges. Each RBridge MAY/SHOULD drop frames allegedly from other RBRidges where the ingress port is inconsistent with the discovered topology. That would make the RBridge specific logic pertain only during RBridge discovery, and then allow generic "acceptable ingress port" logic to apply rather than an RBridge specific rule. If a given bridge already has anti-spoofing features it wouldn't make much sense to require additional RBridge specific checks. For an example, an RBridge built into a piece of equipment could indeed know that its internal "ports" have no RBridges on them. But it might know that because it knows the MAC address associated with each of those ports. It can easily enforce that they are not RBridges during discovery, and it can easily enforce that the only traffic originating on those ports have the correct MAC address. Given those checks, I see no need for such an implementation to dynamically block RBridge encapsulated frames from originating on the internal ports. Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l3KJrHbX018346 for <Rbridge@postel.org>; Fri, 20 Apr 2007 12:53:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1177098796!1098903!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13037 invoked from network); 20 Apr 2007 19:53:16 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 20 Apr 2007 19:53:16 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3KJrErT012592 for <Rbridge@postel.org>; Fri, 20 Apr 2007 12:53:16 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l3KJrDJg009099 for <Rbridge@postel.org>; Fri, 20 Apr 2007 14:53:14 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3KJrDwL009092 for <Rbridge@postel.org>; Fri, 20 Apr 2007 14:53:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Apr 2007 15:53:12 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790026C3183@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rbridge port security thread-index: AceDhYb1cypxxsmkTE6hUQzLBFlMvw== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-Vontu: Pass 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 l3KJrHbX018346 Subject: [rbridge] Rbridge port security 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, 20 Apr 2007 19:53:24 -0000 Status: RO Content-Length: 786 Hi, I'm continuing to work through the comments on our first document to hit the IESG, the routing requirements document. Based on these, I would say that we have to add a per port configuration variable for Rbridges that indicates there are no Rbridges connected via that port. The effect would be that any TRILL frames arriving on that port would be assumed to be forged and would be discarded. This would include frames claiming to be core or per-VLAN IS-IS messages as well as messages that claim to be TRILL encapsulated frames. Of course, the zero configuration default would be to accept TRILL frames on all ports. Unless there is some objection, this will be added to the protocol specification and should probably be mentioned in the architecture document. Thanks, Donald Received: from web30712.mail.mud.yahoo.com (web30712.mail.mud.yahoo.com [68.142.201.250]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l3KJ3JZn003857 for <rbridge@postel.org>; Fri, 20 Apr 2007 12:03:19 -0700 (PDT) Received: (qmail 74805 invoked by uid 60001); 20 Apr 2007 19:03:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=IzvrO63IIR1rFZy8QjAG6bABCOJELl1WTqfhdXubE+8QdwY7AaDOLMdSETZhU5X16cimPDzamYv3QvUU0N0qcSEk5XM8aBqYf4LgtVZqmei+MkOpF5uy4/7XHRWOqhObG4W2ipGpjTy98p7y/AOAnTLRuGW6E2sYaWLG6b/atwQ=; X-YMail-OSG: 8uasYlgVM1ndzuZY8PTtYBGyoeZZlPrEq6KqQMildjCaRTF6KNgTDlkHAYpl2H.Eb_iftJ75ZZRcaTI3zbZHVhphwhQo0IoO.DMZt50oVZmXDksqcmqV5znCD7Bcua.u.CYU3ciD.ZP0swzD Received: from [209.191.118.121] by web30712.mail.mud.yahoo.com via HTTP; Fri, 20 Apr 2007 12:03:17 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Fri, 20 Apr 2007 12:03:16 -0700 (PDT) From: Gary H <bug_hunter32@yahoo.com> To: rbridge@postel.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-149186721-1177095796=:74056" Message-ID: <448885.74056.qm@web30712.mail.mud.yahoo.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bug_hunter32@yahoo.com Subject: [rbridge] Frame format for 802.1ah MAC-in-MAC? 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, 20 Apr 2007 19:03:34 -0000 Status: RO Content-Length: 15847 --0-149186721-1177095796=:74056 Content-Type: text/plain; charset=ascii Hello All: I am looking at 802.1ah draft 3.4 and I see that section 9.5 clearly defines the Service Instance Tag but I do not see anywhere in the spec that clearly defines the format of the Backbone VLAN Tag (aka Service VLAN Tag). I do see someone posted their interpretation of the frame format back in December (see below). Is this still what people expect to be the final frame format? Below is my stab at putting into words what is described from the post in Decemeber. Please ignire the values I put in for MAC addresses. Backbone VLAN Tag Backbone Destination MAC (hex) = 12:34:56:00:00:01 Backbone Source MAC (hex) = 12:34:56:00:00:02 EtherType (hex) = 8100 Backbone VLAN Tag (hex) = 0101 (user defined) EtherType (hex) = 88a8 Instance VLAN Tag Priority (bits) = 000 Drop Eligible (bit) = 0 Res1 (bits) = 00 Res2 (bits) = 00 Service ID (bits) = 000000000000000000000000 Customer Tag Customer Destination MAC (hex) = ab:cd:ef:00:00:11 Customer Source MAC (hex) = ab:cd:ef:00:00:12 Ethertype (hex) = 88b5 | 1 | 2 | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -2 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2 | Backbone Destination Address [B-DA] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Backbone Source Address [B-SA] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | | .1ad Ethertype [B-TAG] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | .1ad B-TAG TCI/VID | .1ah Ethertype [ ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+ 18 | .1ah I-TAG TCI/SID [ - ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+ 22 | Customer Destination Address [ A ] | + +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+ 26 | | [ ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ ] + 30 | Customer Source Address [ ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ ]-+-+-+ 34 | Encap Ethertype | [ ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .1ah I-TAG TCI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P/DE |R1 |R2 | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Gary __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-149186721-1177095796=:74056 Content-Type: text/html; charset=ascii <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>Hello All:</DIV> <DIV> </DIV> <DIV> I am looking at 802.1ah draft 3.4 and I see that section 9.5 clearly defines the Service Instance Tag but I do not see anywhere in the spec that clearly defines the format of the Backbone VLAN Tag (aka Service VLAN Tag). I do see someone posted their interpretation of the frame format back in December (see below). Is this still what people expect to be the final frame format?</DIV> <DIV> </DIV> <DIV>Below is my stab at putting into words what is described from the post in Decemeber. Please ignire the values I put in for MAC addresses.</DIV> <DIV> </DIV> <DIV> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone VLAN Tag<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone Destination MAC (hex) = 12:34:56:00:00:01<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone Source MAC (hex) = 12:34:56:00:00:02<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">EtherType (hex) = 8100<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone VLAN Tag (hex) = 0101 (user defined)</SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">EtherType (hex) = 88a8<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Instance VLAN Tag<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Priority (bits) = 000<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Drop Eligible (bit) = 0<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Res1 (bits) = 00<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Res2 (bits) = 00<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Service ID (bits) = 000000000000000000000000<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Customer Tag<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Customer Destination MAC (hex) = ab:cd:ef:00:00:11<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Customer Source MAC (hex) = ab:cd:ef:00:00:12<o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ethertype (hex) = 88b5<o:p></o:p></SPAN></P></DIV> <DIV><FONT size=2><SPAN style="mso-spacerun: yes"> </SPAN></FONT></DIV> <DIV><PRE><o:p><FONT size=2><PRE><SPAN style="mso-spacerun: yes"> </SPAN><o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>1<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>2<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>3<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>4<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN><o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE> -2 |<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<SPAN style="mso-spacerun: yes"> </SPAN>+<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>2 |<SPAN style="mso-spacerun: yes"> </SPAN>Backbone Destination Address<SPAN style="mso-spacerun: yes"> </SPAN>[B-DA]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>6 |<SPAN style="mso-spacerun: yes"> </SPAN>Backbone Source Address<SPAN style="mso-spacerun: yes"> </SPAN>[B-SA]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+<SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE> 10 |<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>.1ad Ethertype<SPAN style="mso-spacerun: yes"> </SPAN>[B-TAG]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE> 14 |<SPAN style="mso-spacerun: yes"> </SPAN>.1ad B-TAG TCI/VID<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>.1ah Ethertype<SPAN style="mso-spacerun: yes"> </SPAN>[<SPAN style="mso-spacerun: yes"> </SPAN>]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+<o:p></o:p></PRE><PRE> 18 |<SPAN style="mso-spacerun: yes"> </SPAN>.1ah I-TAG TCI/SID<SPAN style="mso-spacerun: yes"> </SPAN>[ - ]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+<o:p></o:p></PRE><PRE> 22 |<SPAN style="mso-spacerun: yes"> </SPAN>Customer Destination Address<SPAN style="mso-spacerun: yes"> </SPAN>[ A ]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+<SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+<o:p></o:p></PRE><PRE> 26 |<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>[<SPAN style="mso-spacerun: yes"> </SPAN>]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<SPAN style="mso-spacerun: yes"> </SPAN>[<SPAN style="mso-spacerun: yes"> </SPAN>]<SPAN style="mso-spacerun: yes"> </SPAN>+<o:p></o:p></PRE><PRE> 30 |<SPAN style="mso-spacerun: yes"> </SPAN>Customer Source Address<SPAN style="mso-spacerun: yes"> </SPAN>[<SPAN style="mso-spacerun: yes"> </SPAN>]<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[<SPAN style="mso-spacerun: yes"> </SPAN>]-+-+-+<o:p></o:p></PRE><PRE> 34 |<SPAN style="mso-spacerun: yes"> </SPAN>Encap Ethertype<SPAN style="mso-spacerun: yes"> </SPAN>|<SPAN style="mso-spacerun: yes"> </SPAN>[<SPAN style="mso-spacerun: yes"> </SPAN>]<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE><o:p> </o:p></PRE><PRE><o:p> </o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>.1ah I-TAG TCI<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>| P/DE<SPAN style="mso-spacerun: yes"> </SPAN>|R1 |R2 |<SPAN style="mso-spacerun: yes"> </SPAN>I-SID<SPAN style="mso-spacerun: yes"> </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes"> </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman" size=3> </FONT></o:p></P></FONT></o:p></PRE></DIV> <DIV> <P class=MsoNormal style="MARGIN: 0in 0in 0pt">Thanks,</P> <P class=MsoNormal style="MARGIN: 0in 0in 0pt">Gary</P> </DIV></div><br> <hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out <a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a> </body></html> --0-149186721-1177095796=:74056-- 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 l3JEDvMf008574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 19 Apr 2007 07:13:57 -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 l3JECgRw001575; Thu, 19 Apr 2007 09:12:42 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 09:13:56 -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, 19 Apr 2007 09:13:45 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFC1881D@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4625220E.4030509@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Proposal for making per-VLAN instance optional (to listento) Thread-Index: AceBKZ4hw83sZfGeQgewgxMpWDDKbABWtKUg References: <4625220E.4030509@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 19 Apr 2007 14:13:56.0415 (UTC) FILETIME=[F7957CF0:01C7828C] 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 l3JEDvMf008574 Cc: rbridge@postel.org Subject: Re: [rbridge] Proposal for making per-VLAN instance optional (to listento) 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, 19 Apr 2007 14:14:23 -0000 Status: RO Content-Length: 8248 Radia, I think you are making this too hard. Please see my comments below. Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, April 17, 2007 3:38 PM > To: rbridge@postel.org > Subject: [rbridge] Proposal for making per-VLAN instance > optional (to listento) > > First an explanation of the issue: > > Some people have expressed a scalability concern: that if > there are many more endnodes (that the Designated RBridge > R1 knows about) than ones that are talking to endnodes on > Designated RBridge R2's link, there is no reason for R2 to > know about all those other endnodes, and the traffic to > keep R2 informed about R1's endnodes' comings and goings > might be a concern. A picture right about here would be extremely useful. > > TRILL will work if some RBridges decide they want to learn > endnode locations from decapsulated traffic rather than > from the per-VLAN instance in which the Designated RBridge > announces its attached endnodes. (and other RBridges learn > from the per-VLAN instance). This is true. Is it worth the price to other RBridges (in terms of option complexity) to support this? > > So it is OK to make *learning* from the IS-IS endnode > announcements optional. I am unsure that this follows. When you say "it is ok", you are apparently referring to the fact that it will work. That is not the same as "it is okay" (acceptable), IMO. > R2 could learn only from the source MAC address of frames > it decapsulates onto its link, even if other RBridges are > learning from the IS-IS endnode announcements. There are (at least) three ways in which this impacts the way other RBridges are required to behave: 1) it now becomes an issue for either configuration (yech!) or negotiation in protocol to determine which of two kinds of behavior will apply; 2) this might occur in one of three ways - a) on the basis of peer-adjacency - in which case a peer will need to decide whether or not to propagate IS-IS end-node announcements on a per-peer basis, b) on the basis of domain-wide policy that applies to all RBridges in a campus, or c) some complicated combination of both; 3) all RBridges are likely to have to endure a greater load of unicast flooding as a result of information not kept by the "lame-duck" implementations that simply do not want to receive (or retain) IS-IS endnode announcements. > > But we can't make *advertising* attached endnodes optional, > because if there's any RBridge R3 that does NOT want to > learn from decapsulated traffic, and wants to learn from > IS-IS announcements, then if all the other RBridges stop > advertising, then R3 will flood everything. This is but one issue with making the decision on a basis of peer adjacencies. Another is that - in a deployment where the majority of edge RBridges elect not to receive such announcements, the core RBridges (in environments where there is actually a real distinction between "core" and "edge" RBridges) should be configured not to receive them either. Otherwise, the edge RBridges will originate a lot of announcement traffic that will then be dropped rather than being propagated. But, of course, if the core RBridges are configured not to receive these announcements, then your problem arises. I assume that we're not suggesting that all RBridges MUST support this "old-style" learning, so even when the ones that do not are a minority, they still need to receive the endnode announcements. > > So--you ask--why don't we *only* learn from decapsulated > data traffic? Not my question at all. Learning from decapsulation is a flagrant layer violation, and - as such - is either too risky, or too restrictive in future developments. With that caveat, if you want to do it, more power to you. > > The reasons are as follows: > a) some people have said that router products don't like > to learn from the data plane; they want to forward > traffic without thinking very hard, and want to do > the work of updating forwarding tables based on control > traffic > b) there are some layer 2 technologies in which endnodes > enroll, and being able to announce these attached > endnodes is nice because it is definitive > -- you know when they attach, you know when they go away > -- it's more secure than learning from data, since anyone > can send data with any source address and cause > disruption. > > The IS-IS announcement can even modify how definitive the > attached endnode is > "it enrolled" > "it enrolled cryptographically" > "I learned it just because I heard a data packet with > that as source address" > > c) the per-VLAN IS-IS endnode announcements also announce the > layer 3/layer 2 correspondence to facilitate proxy ARP/ND > (though that could probably be learned from decapsulated > data traffic as well). This last point assumes a behavior that - IMO - should be included, but is not (AFAIK) included in the current WG consensus. > > *********************** > OK, now the proposal: > > One suggestion of course is to eliminate the per-VLAN IS-IS > instance, and make everyone learn from data traffic. I don't > have strong opinions on that, but we should make sure the > people doing router products can cope with this, and that > we don't care about the other potential advantages of > advertising endnodes with IS-IS. > > But I think we can have a compromise that will make both > sides happy. > > The idea is to have RB1 announce, in its core instance, > whether it wants to learn from IS-IS endnode announcements. > If any RBridge in VLAN A wants to learn from endnode > announcements, then all the RBridges in VLAN A MUST send > IS-IS endnode announcements. > > But if *all* the RBridges in VLAN A say they don't want them, > then the VLAN A endnode announcements stop. > > Even if there are endnodes announcements in VLAN A, it is > optional for an RBridge whether it wants to learn from data > or from the announcements, or from some combination of the > two (like perhaps it will only learn from endnode > announcements which are definitive, or that it will learn > from endnode announcements, but if it runs out of room to > store them, it will fall back on learning from data). > > We could even have core RBridges filter IS-IS endnode > announcements for VLAN A to only deliver them to RBridges > in VLAN A that say that want to learn from them. > > *************** > What do people think? As I said above, I think you are making this too hard. As with bridges before them, all RBridges may eventually have to deal with memory (scale) limitations by purging their least-used, or least recently refreshed "filter" information. This implies two choices in implementation: 1) optimize for the IS-IS approach by designing both for large and expandable memory capacity to minimize the need for purging and (potentially) having to re-learn 2) optimize for the data-learning approach, save on cost of memory at a cost of increased forwarding complexity Clearly if the IS-IS endnode announcements are sent to all RBridges in a campus, then any that are unable to retain the information (because of their optimization choices) will be able to either ignore them, or purge their DBs according to whatever local policy applies to their own implementation. The only time the IS-IS endnode announcement traffic is likely to be a problem is if all RBridges are ignoring them. Since this will be an exclusive property of those RBridges that only use "old-style" learning, I assume it will be possible to configure those same RBridges not to send IS-IS announcements in the event that a specific deployment scenario does not require them. This places the (minimal) additional complexity in those RBridges that choose to learn without any impact at all on those that choose to use IS-IS endnode announcements. > > Radia > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > 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 l3IEk3nN025172 for <rbridge@postel.org>; Wed, 18 Apr 2007 07:46:03 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 18 Apr 2007 07:45:53 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BF2692AF; Wed, 18 Apr 2007 07:45:53 -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 AB79C2AE; Wed, 18 Apr 2007 07: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 FFG15562; Wed, 18 Apr 2007 07:45:53 -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 46C3869CA3; Wed, 18 Apr 2007 07:45:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Apr 2007 07:45:44 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D037B67EA@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <4625220E.4030509@sun.com> Thread-Topic: [rbridge] Proposal for making per-VLAN instance optional ( to listen to) Thread-Index: AceBKo7iK2heeK3wR4ei3vT8/YeZugAnUDDg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A38F0AB3A418637490-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 l3IEk3nN025172 Subject: Re: [rbridge] Proposal for making per-VLAN instance optional (to listen to) 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, 18 Apr 2007 14:46:33 -0000 Status: RO Content-Length: 365 The proposal strikes me as a reasonable compromise that ensures interoperability while allowing specific implementations to optimize as they see best for their target deployment. Assuming both this and the VLAN-sharing ideas make it into the next draft, it might be worth noting than RBridges using the VLAN-sharing concept will need the IS-IS 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 l3HJbfTf014997 for <rbridge@postel.org>; Tue, 17 Apr 2007 12:37:41 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JGN005FYQINQ910@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 17 Apr 2007 12:37:35 -0700 (PDT) Received: from [127.0.0.1] ([129.150.17.161]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JGN00K0JQIKLS00@mail.sunlabs.com> for rbridge@postel.org; Tue, 17 Apr 2007 12:37:34 -0700 (PDT) Date: Tue, 17 Apr 2007 12:37:50 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <4625220E.4030509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Proposal for making per-VLAN instance optional (to listen to) 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, 17 Apr 2007 19:38:07 -0000 Status: RO Content-Length: 3678 First an explanation of the issue: Some people have expressed a scalability concern: that if there are many more endnodes (that the Designated RBridge R1 knows about) than ones that are talking to endnodes on Designated RBridge R2's link, there is no reason for R2 to know about all those other endnodes, and the traffic to keep R2 informed about R1's endnodes' comings and goings might be a concern. TRILL will work if some RBridges decide they want to learn endnode locations from decapsulated traffic rather than from the per-VLAN instance in which the Designated RBridge announces its attached endnodes. (and other RBridges learn from the per-VLAN instance). So it is OK to make *learning* from the IS-IS endnode announcements optional. R2 could learn only from the source MAC address of frames it decapsulates onto its link, even if other RBridges are learning from the IS-IS endnode announcements. But we can't make *advertising* attached endnodes optional, because if there's any RBridge R3 that does NOT want to learn from decapsulated traffic, and wants to learn from IS-IS announcements, then if all the other RBridges stop advertising, then R3 will flood everything. So--you ask--why don't we *only* learn from decapsulated data traffic? The reasons are as follows: a) some people have said that router products don't like to learn from the data plane; they want to forward traffic without thinking very hard, and want to do the work of updating forwarding tables based on control traffic b) there are some layer 2 technologies in which endnodes enroll, and being able to announce these attached endnodes is nice because it is definitive -- you know when they attach, you know when they go away -- it's more secure than learning from data, since anyone can send data with any source address and cause disruption. The IS-IS announcement can even modify how definitive the attached endnode is "it enrolled" "it enrolled cryptographically" "I learned it just because I heard a data packet with that as source address" c) the per-VLAN IS-IS endnode announcements also announce the layer 3/layer 2 correspondence to facilitate proxy ARP/ND (though that could probably be learned from decapsulated data traffic as well). *********************** OK, now the proposal: One suggestion of course is to eliminate the per-VLAN IS-IS instance, and make everyone learn from data traffic. I don't have strong opinions on that, but we should make sure the people doing router products can cope with this, and that we don't care about the other potential advantages of advertising endnodes with IS-IS. But I think we can have a compromise that will make both sides happy. The idea is to have RB1 announce, in its core instance, whether it wants to learn from IS-IS endnode announcements. If any RBridge in VLAN A wants to learn from endnode announcements, then all the RBridges in VLAN A MUST send IS-IS endnode announcements. But if *all* the RBridges in VLAN A say they don't want them, then the VLAN A endnode announcements stop. Even if there are endnodes announcements in VLAN A, it is optional for an RBridge whether it wants to learn from data or from the announcements, or from some combination of the two (like perhaps it will only learn from endnode announcements which are definitive, or that it will learn from endnode announcements, but if it runs out of room to store them, it will fall back on learning from data). We could even have core RBridges filter IS-IS endnode announcements for VLAN A to only deliver them to RBridges in VLAN A that say that want to learn from them. *************** What do people think? 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 l39KaAbJ008044 for <rbridge@postel.org>; Mon, 9 Apr 2007 13:36:10 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JG800D3PZW6OJ00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 09 Apr 2007 13:36:06 -0700 (PDT) Received: from [127.0.0.1] ([129.150.17.105]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JG8002A4ZW5NF00@mail.sunlabs.com> for rbridge@postel.org; Mon, 09 Apr 2007 13:36:06 -0700 (PDT) Date: Mon, 09 Apr 2007 13:36:24 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D0360E9BE@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <461AA3C8.6010806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <1EF1E44200D82B47BD5BA61171E8CE9D0360E9BE@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Thunderbird 1.5 (Windows/20051201) 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 proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 09 Apr 2007 20:36:32 -0000 Status: RO Content-Length: 1211 Actually, with IS-IS, R1 can't delete information from R2's LSP If R1 is not interesting in it. Anyone participating in the flooding of R1's LSP must keep R1's LSP intact. Someone downstream might be interested in that information. Even once R1's neighbors acknowledge they've received R2's LSP, R1 must still retain the information in case one of R1's neighbors goes down and loses state. With the per-VLAN instance of IS-IS, since the topology is a single hop, R1 would never need to forward R2's LSP to anyone else, so in theory R1 could ignore R2's endnode announcements. Radia Caitlin Bestler wrote: > Radia Perlman wrote: > > >> I'd suggest the TRILL spec just say that you SHOULD put the >> information into the core instance of IS-IS if you are >> configured, and not say anything about what any RBridge would >> do with the information. >> >> > The TRILL spec would merely add the information to the RBridge > discovery data. It could explicitly state that any RBridge could > choose to not retain information that it would have no use of. > > The same would apply to the additional attribute in the endnode > discovery. If it's not relevant to you, discard or ignore it. > > > > 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 l39KIFRU002299 for <rbridge@postel.org>; Mon, 9 Apr 2007 13:18:15 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 09 Apr 2007 13:18:06 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 81CE52B0; Mon, 9 Apr 2007 13:18:06 -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 6DED42AF; Mon, 9 Apr 2007 13:18:06 -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 FEF65425; Mon, 9 Apr 2007 13:18:06 -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 0CED669CA4; Mon, 9 Apr 2007 13:18:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Apr 2007 13:18:07 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0360E9BE@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <461A91C6.1090706@sun.com> Thread-Topic: [rbridge] Shared VLAN proposal Thread-Index: Acd62/3QGEhWuFXJR5WU79v6F8JEnAAB9QLQ From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A0440F438G14860745-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 l39KIFRU002299 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 09 Apr 2007 20:18:29 -0000 Status: RO Content-Length: 560 Radia Perlman wrote: > > I'd suggest the TRILL spec just say that you SHOULD put the > information into the core instance of IS-IS if you are > configured, and not say anything about what any RBridge would > do with the information. > The TRILL spec would merely add the information to the RBridge discovery data. It could explicitly state that any RBridge could choose to not retain information that it would have no use of. The same would apply to the additional attribute in the endnode discovery. If it's not relevant to you, discard or ignore it. 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 l39JJK10015138 for <rbridge@postel.org>; Mon, 9 Apr 2007 12:19:20 -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 <0JG800C7WWC4EQ10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 09 Apr 2007 12:19:16 -0700 (PDT) Received: from [127.0.0.1] ([129.150.17.105]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JG8001MSWC3BY10@mail.sunlabs.com> for rbridge@postel.org; Mon, 09 Apr 2007 12:19:16 -0700 (PDT) Date: Mon, 09 Apr 2007 12:19:34 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D0360E900@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <461A91C6.1090706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <1EF1E44200D82B47BD5BA61171E8CE9D0360E900@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Thunderbird 1.5 (Windows/20051201) 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 proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 09 Apr 2007 19:19:35 -0000 Status: RO Content-Length: 8458 Yes.! Thanks, Caitlin. This seems like the right way to go. It offers the best part of both the proposals I wrote up earlier, without the disadvantages or either, and it's simple. a) only the RBridges attached to a VLAN in the group need to know about the VLAN group b) packets don't get duplicated And it accomplishes this by having RBridges that are in the VLAN group pretend to be in all the relevant other VLANs. This way they receive multicasts, including IS-IS endnode announcements, for all the VLANs they should be receiving. To say it in other words, a) There is a VLAN group consisting of {Z=primary, A, B, C, D} b) An RBridge is configured to know about this group iff it attaches to a link in one of those VLANs c) "Core RBridges" (by which I mean those that are forwarding packets that are already encapsulated) forward a multicast frame tagged with a VLAN in that group exactly as it would have without there being a VLAN group d) For an RBridge RB1 that attaches to one of the VLANs in the group: . If RB1 is attached to a secondary VLAN, say VLAN C, RB1 claims, in its core instance of IS-IS, that RB1 is actually attached to both VLAN C and VLAN Z. This causes multicast packets tagged with VLAN C or VLAN Z to get delivered to RB1. . If RB1 is attached to the primary VLAN Z, the RB1 claims, in its core instance of IS-IS, to also be connected to VLANs A, B, C, and D. That way RB1 will receive any multicast packet tagged with any of the VLANs in the group e) The per-VLAN instance of IS-IS in which endnode membership is announced is not changed; there is still one for A, one for B, one for C, one for D, and one for Z. Because RB1, in Z, has announced it is part of A, B, C, and D as well, RB1 will receive endnode announcements for all of the VLANs A, B, C, and D f) If RB1 receives, from endnode S in VLAN Z, a unicast for destination D, RB1 checks to find D in its endnode databases for all of the VLANs in the group (Z, A, B, C, and D). If it finds D in VLAN C, with egress RBridge RB2, then RB1 encapsulates the packet with inner VLAN tag Z (the source's VLAN), and specifies egress RBridge=RB2. RB2 receives this unicast for D, and forwards it to D even though the frame is marked as VLAN=Z, and D is in VLAN C. RB2 removes the VLAN tag, changes it to C, or leaves it as Z, whatever is appropriate, and presumably RB2 is configured to know which of these three is appropriate for the outgoing port. If RB1 cannot find D in any of the endnode tables for {Z, A, B, C, or D}, then RB1 floods the packet tagged with VLAN=Z (the source's VLAN). g) If any rbridge RB1 receives a multicast packet from a source in any VLAN, whether that VLAN is part of a group or not, RB1 floods the packet tagged with the source's VLAN ********** One thing I'd like to add is for RBridges that are part of a group to announce the group in their core instance. Core RBridges would ignore this. It would not change their behavior, so there is no disadvantage (other than a trivial amount of space in the core instance LSP). The advantages are: a) perhaps one could avoid configuring every RBridge, and an RBridge could be willing to take the word of another RBridge what the VLAN groupings should be b) at the very least, it would be a good debugging tool, and a way of detecting misconfiguration I'd suggest the TRILL spec just say that you SHOULD put the information into the core instance of IS-IS if you are configured, and not say anything about what any RBridge would do with the information. ********** So -- what do people think about this? Radia Caitlin Bestler wrote: > This is a proposal on how to support "shared VLANs" and resolve the > whole MAC/IP uniqueness question. It avoids the incosistencies of > simply assuming that MAC and IP addresses are always scoped by VLANs, > but does so without requiring any action from any RBridge that is not > directly involved in a "VLAN Group". > > By default the per-VLAN IS-IS instances are totally independent from > each > other. There is no presumed correlation between identicial MAC or IP > addresses when they are in different VLAN instances. > > However, RBridges MAY offer the capability of recognized groups of VLANs > that represent a single unique namespace for both MAC and IP addresses > and > where there is a primary or shared VLAN that is accessible from all of > the > other VLANs in the group. > > For example, a VLAN group might consist of {Z,A,B,C,D} where Z is the > designated primary VLAN. Endnodes in VLAN A would be capable of sending > ethernet frames within VLAN A, and to VLAN Z. Endnodes in VLAN B could > send to {Z,B}, those in C to {Z,C} and those in D to {Z,D}. While > endnodes > in the shared or primary VLAN (Z) would be able to send to all VLANs in > the > group {Z,A,B,C,D}. > > The impact on the RBridge protocol is that RBridges which support a > VLAN Group would have more information in the IS-IS instances for > the VLAN Group. Specifically: > > Endnodes that are part of the primary VLAN (Z) would be > represented > in the IS-IS instances for the entire group {A,B,C,D,Z}. > > Endnodes that are part of a non-primary VLAN (for example, A) > would > also be represented in the instance for the group's primary VLAN > (Z). > > RBridge ingress behavior is essentially unchanged. The exception is that > a frame being attempted from one non-primary VLAN (A) to another > non-primary > VLAN (B) can be short-circuited at the source. Because of the sharing > between > the IS-IS instances within the VLAN Group the ingress RBridge MAY > recognize > that the destination is unreachable, whereas without this information it > > would merely be unknown (it would also be unreachable, but the ingress > RBridge would not have known that). > > For RBridges supporting VLAN Groups, egress behavior is enhanced to > allow > an endnode that otherwise would have been considered to be just the > primary > to also be part of all VLANs in the group, and for an endnode that > otherwise > would have been part of any non-primary VLAN in the group to also be > part > of the group's primary VLAN. > > This option requires no supporting action from any RBridge that is not > part of > the VLAN group. The additional information need only be retained in > IS-IS > instances that are part of a VLAN Group. No RBridge is required to > support > VLAN Groups. > > The only required enhancement to RBridge protocols is that the endnode > discovery > advertisement needs to explicitly indicate the VLAN associated with the > discovered > endnode. It may also be desirable for each the RBridge discovery > advertisement to > explicitly list any VLAN Group that the RBridge is part of. > > All RBridges that are part of a VLAN Group MUST have the same list of > member VLANs > for the VLAN Group. > > All RBridges that are part of a VLAN Group MUST participate directly in > the group's > primary VLAN ('Z' in the example), and MUST maintain a VLAN Z IS-IS > instance. > > Endnode discoveries by any RBridge within a VLAN Group MUST be > distributed via the > group's primary VLAN. > > When an RBridge receives an endnode discovery advertisement for and > endnode that > belongs to the primary VLAN it MUST include that information within each > IS-IS > instance that it maintains for the entire VLAN Group. It MUST enforce > any consistency > rules that are relevant according to that VLAN Group's rules, for > example discovery of > an IP Address within one VLAN might require removal from another VLAN. > > Consistency rules of this type reflect the rules of that VLAN Group. The > RBridge protocol > neither requires nor forbids such VLAN Group specific rules. > > When an RBridge receives an endnode discovery advertisement for a > non-primary VLAN, the > endode is only added to the receiving RBRidge's IS-IS instance for the > group's primary > VLAN (Z). The receiving RBridge would also remove any endnode record > that was inconsistent > with the new information, such as the same MAC or IP address having a > conflicting meaning, > from other VLAN IS-IS instances. > > Determination as to whether an entry is "conflicting" is based upon the > rules of the > VLAN Group, and is not part of the RBridge protocol specificatins. > > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > 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 l39I3o3R015906 for <rbridge@postel.org>; Mon, 9 Apr 2007 11:03:51 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 09 Apr 2007 11:03:41 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A00E22AF; Mon, 9 Apr 2007 11:03: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 8D1D82AE for <rbridge@postel.org>; Mon, 9 Apr 2007 11:03: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 FEF28090; Mon, 9 Apr 2007 11:03:26 -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 1C0B269CA4 for <rbridge@postel.org>; Mon, 9 Apr 2007 11:03:26 -0700 ( PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Apr 2007 11:03:35 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0360E900@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: Shared VLAN proposal Thread-Index: Acd60WPvyG/qtLl+TxqBaeMONOIjFw== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: rbridge@postel.org X-WSS-ID: 6A04A0773A414790639-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 l39I3o3R015906 Subject: [rbridge] Shared VLAN proposal X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 09 Apr 2007 18:04:00 -0000 Status: RO Content-Length: 4425 This is a proposal on how to support "shared VLANs" and resolve the whole MAC/IP uniqueness question. It avoids the incosistencies of simply assuming that MAC and IP addresses are always scoped by VLANs, but does so without requiring any action from any RBridge that is not directly involved in a "VLAN Group". By default the per-VLAN IS-IS instances are totally independent from each other. There is no presumed correlation between identicial MAC or IP addresses when they are in different VLAN instances. However, RBridges MAY offer the capability of recognized groups of VLANs that represent a single unique namespace for both MAC and IP addresses and where there is a primary or shared VLAN that is accessible from all of the other VLANs in the group. For example, a VLAN group might consist of {Z,A,B,C,D} where Z is the designated primary VLAN. Endnodes in VLAN A would be capable of sending ethernet frames within VLAN A, and to VLAN Z. Endnodes in VLAN B could send to {Z,B}, those in C to {Z,C} and those in D to {Z,D}. While endnodes in the shared or primary VLAN (Z) would be able to send to all VLANs in the group {Z,A,B,C,D}. The impact on the RBridge protocol is that RBridges which support a VLAN Group would have more information in the IS-IS instances for the VLAN Group. Specifically: Endnodes that are part of the primary VLAN (Z) would be represented in the IS-IS instances for the entire group {A,B,C,D,Z}. Endnodes that are part of a non-primary VLAN (for example, A) would also be represented in the instance for the group's primary VLAN (Z). RBridge ingress behavior is essentially unchanged. The exception is that a frame being attempted from one non-primary VLAN (A) to another non-primary VLAN (B) can be short-circuited at the source. Because of the sharing between the IS-IS instances within the VLAN Group the ingress RBridge MAY recognize that the destination is unreachable, whereas without this information it would merely be unknown (it would also be unreachable, but the ingress RBridge would not have known that). For RBridges supporting VLAN Groups, egress behavior is enhanced to allow an endnode that otherwise would have been considered to be just the primary to also be part of all VLANs in the group, and for an endnode that otherwise would have been part of any non-primary VLAN in the group to also be part of the group's primary VLAN. This option requires no supporting action from any RBridge that is not part of the VLAN group. The additional information need only be retained in IS-IS instances that are part of a VLAN Group. No RBridge is required to support VLAN Groups. The only required enhancement to RBridge protocols is that the endnode discovery advertisement needs to explicitly indicate the VLAN associated with the discovered endnode. It may also be desirable for each the RBridge discovery advertisement to explicitly list any VLAN Group that the RBridge is part of. All RBridges that are part of a VLAN Group MUST have the same list of member VLANs for the VLAN Group. All RBridges that are part of a VLAN Group MUST participate directly in the group's primary VLAN ('Z' in the example), and MUST maintain a VLAN Z IS-IS instance. Endnode discoveries by any RBridge within a VLAN Group MUST be distributed via the group's primary VLAN. When an RBridge receives an endnode discovery advertisement for and endnode that belongs to the primary VLAN it MUST include that information within each IS-IS instance that it maintains for the entire VLAN Group. It MUST enforce any consistency rules that are relevant according to that VLAN Group's rules, for example discovery of an IP Address within one VLAN might require removal from another VLAN. Consistency rules of this type reflect the rules of that VLAN Group. The RBridge protocol neither requires nor forbids such VLAN Group specific rules. When an RBridge receives an endnode discovery advertisement for a non-primary VLAN, the endode is only added to the receiving RBRidge's IS-IS instance for the group's primary VLAN (Z). The receiving RBridge would also remove any endnode record that was inconsistent with the new information, such as the same MAC or IP address having a conflicting meaning, from other VLAN IS-IS instances. Determination as to whether an entry is "conflicting" is based upon the rules of the VLAN Group, and is not part of the RBridge protocol specificatins. Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l39FsEIk022164 for <Rbridge@postel.org>; Mon, 9 Apr 2007 08:54:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1176134053!1507613!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8910 invoked from network); 9 Apr 2007 15:54:13 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 9 Apr 2007 15:54:13 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l39Fs9Z7019642 for <Rbridge@postel.org>; Mon, 9 Apr 2007 08:54:13 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l39Fs8MO002469 for <Rbridge@postel.org>; Mon, 9 Apr 2007 10:54:08 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l39Fs8k0002466 for <Rbridge@postel.org>; Mon, 9 Apr 2007 10:54:08 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Apr 2007 11:54:07 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790025C1D04@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D979002539B67@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some routine changes to the specifications draft thread-index: Acds9nEJ6TNvlSzTRKe1rccbs2phqgEiGyjwAA3rniAAAZQkIABP67wAAAD+myABwRkjIA== References: <3870C46029D1F945B1472F170D2D9790024F5DC1@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA20146712A@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002539B67@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-Vontu: Pass 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 l39FsEIk022164 Subject: [rbridge] Some routine changes to the specifications draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 09 Apr 2007 15:54:22 -0000 Status: RO Content-Length: 1443 Unless there is some objection, the following changes, which I hope will be non-controversial, will be made in the specification draft: (1) There are no IANA Considerations for the reserved bits in the shim or for version number values. I suggest that both require a Standards Action as modified by RFC 4020. (2) The draft currently says nothing about the reserved bits. Typical IETF language would be "must be zero on transmission and are ignored on receipt". But, thinking about it, I'm not so sure that's right in this case. Zero on transmit is fine but, of the seven reserved bits, perhaps some of them should be ignored and some should cause the frame to be dropped if they are non-zero and the receiving Rbridge does not know that they means. Of course, I'm only talking about what the specification would say about unallocated bits. We may, in completing the specification, give a specific meaning of some of those bits currently labeled as reserved in which case we can say what we like about their setting on transmission and interpretation on receipt and the generic language would only apply to remaining reserved bits. (3) Also, if versions are going to actually be useful in an incremental deployment scenario, I think it would be useful for Rbridges to know what version is supported by another RBridge they are talking to. This could be easily accomplished by adding that information to the core link state. Thanks, Donald 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 l354bNR4028049 for <Rbridge@postel.org>; Wed, 4 Apr 2007 21:37:23 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.58.166]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l354bMGW004269; Thu, 5 Apr 2007 04:37: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 l354bAPv360867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 21:37:11 -0700 (PDT) Message-ID: <46147CF6.7030003@sun.com> Date: Wed, 04 Apr 2007 21:37:10 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> References: <3870C46029D1F945B1472F170D2D9790025816CD@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790025816CD@de01exm64.ds.mot.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] Prague minutes 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, 05 Apr 2007 04:37:33 -0000 Status: RO Content-Length: 439 Eastlake III Donald-LDE008 wrote: > Minutes of the Prague TRILL meeting have been uploaded to the 68th IETF > Meeting Materials page: > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Please send any corrections to the minutes to the co-chairs or the list including any issues with the consensus to use "nickname" to describe the short designators of the RBridges that are in the TRILL header. Erik & Donald Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l353n5bf018043 for <Rbridge@postel.org>; Wed, 4 Apr 2007 20:49:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1175744944!3523344!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 18264 invoked from network); 5 Apr 2007 03:49:04 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-4.tower-153.messagelabs.com with SMTP; 5 Apr 2007 03:49:04 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l353n3rF014537 for <Rbridge@postel.org>; Wed, 4 Apr 2007 22:49:04 -0500 (CDT) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l353n3TS018632 for <Rbridge@postel.org>; Wed, 4 Apr 2007 22:49:03 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l353n2Fi018616 for <Rbridge@postel.org>; Wed, 4 Apr 2007 22:49:02 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 23:48:58 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790025816CD@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prague minutes thread-index: Acd3NVdAZf2PUBB6Qc2OMfBcUsqySw== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <Rbridge@postel.org> X-Vontu: Pass 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 l353n5bf018043 Subject: [rbridge] Prague minutes 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, 05 Apr 2007 03:49:26 -0000 Status: RO Content-Length: 186 Minutes of the Prague TRILL meeting have been uploaded to the 68th IETF Meeting Materials page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Thanks, Donald Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l34GmBSI022519 for <rbridge@postel.org>; Wed, 4 Apr 2007 09:48:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 09:47:57 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014BB43A@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFB068C0@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6gAAAPqTAAAZl3AAABIIFAAAHMUcA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8CC@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3B3@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFB068C0@eusrcmw721.eamcs.ericsson.se> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.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 l34GmBSI022519 Cc: rbridge@postel.org Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 16:48:45 -0000 Status: RO Content-Length: 9859 I don't disagree... I couldn't make the connection between this and proxy ARP/ND. JR > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 04, 2007 9:07 AM > To: J. R. Rivers > Cc: rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > > JR, > > Just to be precise, in the working group discussions, we have > been making a very strong distinction between multicast and broadcast. > > I agree that - in an environment where multicast is a large > factor (where large means something like more than 1% of the total > injected traffic), the traffic associated with ARP is way down in > the noise. However, if any effective form of multicast optimization > is implemented, the impact of potentially looping multicast can be > scoped to affected VLANs (and possibly even to multicast "listeners") > by techniques other than TTL (such as queue management that provides > effective isolation of logical interfaces, or hard upper limits on > total multicast traffic, for instance). > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > Sent: Wednesday, April 04, 2007 11:26 AM > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > Importance: High > > > > > > Sorry I must have mis-stated my point. It seems that if ARP > > is the bulk > > of your multicast traffic, then optimizing it doesn't seem like much > > return-on-investment. If other multicast comprises the bulk, then > > optimizing ARP doesn't seem to provide much return-on-investment. > > > > JR > > > > > > > -----Original Message----- > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > Sent: Wednesday, April 04, 2007 7:38 AM > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > > > > It doesn't. However, you mentioned IP multicast as > another area of > > > concern... > > > > > > Thanks! > > > > > > -- > > > Eric Gray > > > Principal Engineer > > > Ericsson > > > > > > > -----Original Message----- > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > Sent: Wednesday, April 04, 2007 10:36 AM > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > > Perlman; rbridge@postel.org > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > alternative proposals) > > > > Importance: High > > > > > > > > > > > > Why does ARP/ND equate to IP multicast optimization? > > > > > > > > JR > > > > > > > > > > > > > -----Original Message----- > > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > > Sent: Wednesday, April 04, 2007 7:34 AM > > > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > > > > Perlman; rbridge@postel.org > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > alternative proposals) > > > > > > > > > > JR, > > > > > > > > > > I agree. However, I believe we (as a working > > group) have > > > > > already > > > > > agreed that the IP multicast optimization is essential. > > > > > Also, it is my > > > > > point (and it is certainly arguable) that perhaps TRILL > > > > should not be > > > > > targetting the general applications of L2 where other forms > > > > > of L2 bcast > > > > > are likely to be a significant factor - but should instead > > > > > focus on the > > > > > applications of L2 specific to IP only (or IP dominant) > > networks. > > > > > > > > > > -- > > > > > Eric Gray > > > > > Principal Engineer > > > > > Ericsson > > > > > > > > > > > -----Original Message----- > > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > > Sent: Wednesday, April 04, 2007 9:58 AM > > > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > > > > Perlman; rbridge@postel.org > > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > alternative proposals) > > > > > > Importance: High > > > > > > > > > > > > > > > > > > It seems that if ARP is the bulk of your > > > > > broadcast/multicast, then you > > > > > > don't really need a very efficient broadcast/multicast > > > > > > mechanism. Some > > > > > > networks can be characterized as you've stated; > > > however, there are > > > > > > others that use L2/IP multicast in a substantial fashion. > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > > > > Sent: Wednesday, April 04, 2007 6:14 AM > > > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > > > > > > Perlman; rbridge@postel.org > > > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > > alternative proposals) > > > > > > > > > > > > > > Silvano, > > > > > > > > > > > > > > Where IP (v4 or v6) is the exclusive higher > > > > layer in a specific > > > > > > > network deployment, it is likely that ARP is one of the > > > > > most common > > > > > > > forms of broadcast traffic that may occur. As we've > > > > > > > previously agreed > > > > > > > that broadcast traffic is of particular concern in > > TRILL, the > > > > > > > potential > > > > > > > to drastically reduce (or possibly eliminate) common > > > > > > broadcast traffic > > > > > > > should be considered a worth-while objective. > > > > > > > > > > > > > > -- > > > > > > > Eric Gray > > > > > > > Principal Engineer > > > > > > > Ericsson > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray > > > (LO/EUS); Radia > > > > > > > > Perlman; rbridge@postel.org > > > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > > > alternative proposals) > > > > > > > > Importance: High > > > > > > > > > > > > > > > > > > > > > > > > Do we have any quantitatively data about the need of > > > > > ARP/ND proxy? > > > > > > > > > > > > > > > > With an ARP cache of 30 minutes, typical in hosts > > > today, even > > > > > > > > with a 100 > > > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. > > Since not > > > > > > > > all the hosts > > > > > > > > talk with each other, it is more typically like > 5 ARP/sec. > > > > > > > > > > > > > > > > The ARP/ND cache on the RBridge must be significantly > > > > > > > shorter than 30 > > > > > > > > minutes to not increase the amount of obsolete > > information. > > > > > > > > > > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for > > 100 K hosts > > > > > > > per VLAN? > > > > > > > > > > > > > > > > Is this the big optimization for which we care > to create > > > > > > > corner cases > > > > > > > > and potential incompatibilities? > > > > > > > > > > > > > > > > -- Silvano > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > > > > > > Radia Perlman; > > > > > > > > > rbridge@postel.org > > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: J. R. Rivers > [mailto:jrrivers@nuovasystems.com] > > > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray > > > > (LO/EUS); Radia > > > > > > > > > > Perlman; rbridge@postel.org > > > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all > > > > > RBridges have the > > > > > > > > > > > information that would enable them to > > efficiently and > > > > > > > > > > reliably act as > > > > > > > > > > > an ARP/ND proxy. > > > > > > > > > > > > > > > > > > > > It depends on how you define the requirements > > of ARP/ND > > > > > > > > > > proxy. I have seen this general mechanism > > used in many > > > > > > > > > > contexts... only one of which is covered by > > an IETF RFC > > > > > > > > > > (AFAIK). Bridges in their basic definition don't > > > > > have ARP/ND > > > > > > > > > > proxy. Only bridges that subsume some type of > > > IP related > > > > > > > > > > functionality contain these. > > > > > > > > > > > > > > > > > > > > If an RBridge "looks and smells" like a bridge, > > > > > then there is > > > > > > > > > > natural traffic separation between VLANs, and > > > this allows > > > > > > > > > > systems companies to view RBridges as "better > > bridges". > > > > > > > > > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > > > > > > deal with the issues of large subnets far better than > > > > > > > > > bridges do. > > > > > > > > > > > > > > > > > > Efficient distribution of ARP/ND information is also > > > > > > > > > an issue where a "better bridge" is needed to scale > > > > > > > > > to larger subnets efficiently. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 l34GUVUo017660 for <rbridge@postel.org>; Wed, 4 Apr 2007 09:30:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 09:30:21 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014BB414@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014BB3B3@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6gAAAPqTAAAZl3AAACGTQg References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8CC@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3B3@nuova-ex1.hq.nuovaimpresa.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Caitlin Bestler" <caitlinb@broadcom.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 l34GUVUo017660 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 16:30:41 -0000 Status: RO Content-Length: 8677 Let me try to summarize what I learnt from the replies to my message. ARP/ND optimization: 1) it is not justified by a bandwidth issue; 2) it is not justified by a latency issue; 3) may help reduce the problem with the broadcast storm, but the problem is really IP multicast. Solution like the one proposed by Radia at the last IETF address both IP multicast and ARP; therefore there is no need for a special ARP/ND solution; 4) it introduces corner cases. Why do we want to do ARP/ND optimization in the first version of TRILL? I restate my proposal: let's drop it by the first version of TRILL and deal with it later, in a separate document. -- Silvano > -----Original Message----- > From: J. R. Rivers > Sent: Wednesday, April 04, 2007 8:26 AM > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia Perlman; > rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative > proposals) > > > Sorry I must have mis-stated my point. It seems that if ARP is the bulk > of your multicast traffic, then optimizing it doesn't seem like much > return-on-investment. If other multicast comprises the bulk, then > optimizing ARP doesn't seem to provide much return-on-investment. > > JR > > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > Sent: Wednesday, April 04, 2007 7:38 AM > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > > > It doesn't. However, you mentioned IP multicast as another area of > > concern... > > > > Thanks! > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > Sent: Wednesday, April 04, 2007 10:36 AM > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > Importance: High > > > > > > > > > Why does ARP/ND equate to IP multicast optimization? > > > > > > JR > > > > > > > > > > -----Original Message----- > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > Sent: Wednesday, April 04, 2007 7:34 AM > > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > > > Perlman; rbridge@postel.org > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > alternative proposals) > > > > > > > > JR, > > > > > > > > I agree. However, I believe we (as a working group) have > > > > already > > > > agreed that the IP multicast optimization is essential. > > > > Also, it is my > > > > point (and it is certainly arguable) that perhaps TRILL > > > should not be > > > > targetting the general applications of L2 where other forms > > > > of L2 bcast > > > > are likely to be a significant factor - but should instead > > > > focus on the > > > > applications of L2 specific to IP only (or IP dominant) networks. > > > > > > > > -- > > > > Eric Gray > > > > Principal Engineer > > > > Ericsson > > > > > > > > > -----Original Message----- > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > Sent: Wednesday, April 04, 2007 9:58 AM > > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > > > Perlman; rbridge@postel.org > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > alternative proposals) > > > > > Importance: High > > > > > > > > > > > > > > > It seems that if ARP is the bulk of your > > > > broadcast/multicast, then you > > > > > don't really need a very efficient broadcast/multicast > > > > > mechanism. Some > > > > > networks can be characterized as you've stated; > > however, there are > > > > > others that use L2/IP multicast in a substantial fashion. > > > > > > > > > > JR > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > > > Sent: Wednesday, April 04, 2007 6:14 AM > > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > > > > > Perlman; rbridge@postel.org > > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > alternative proposals) > > > > > > > > > > > > Silvano, > > > > > > > > > > > > Where IP (v4 or v6) is the exclusive higher > > > layer in a specific > > > > > > network deployment, it is likely that ARP is one of the > > > > most common > > > > > > forms of broadcast traffic that may occur. As we've > > > > > > previously agreed > > > > > > that broadcast traffic is of particular concern in TRILL, the > > > > > > potential > > > > > > to drastically reduce (or possibly eliminate) common > > > > > broadcast traffic > > > > > > should be considered a worth-while objective. > > > > > > > > > > > > -- > > > > > > Eric Gray > > > > > > Principal Engineer > > > > > > Ericsson > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray > > (LO/EUS); Radia > > > > > > > Perlman; rbridge@postel.org > > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > > alternative proposals) > > > > > > > Importance: High > > > > > > > > > > > > > > > > > > > > > Do we have any quantitatively data about the need of > > > > ARP/ND proxy? > > > > > > > > > > > > > > With an ARP cache of 30 minutes, typical in hosts > > today, even > > > > > > > with a 100 > > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not > > > > > > > all the hosts > > > > > > > talk with each other, it is more typically like 5 ARP/sec. > > > > > > > > > > > > > > The ARP/ND cache on the RBridge must be significantly > > > > > > shorter than 30 > > > > > > > minutes to not increase the amount of obsolete information. > > > > > > > > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts > > > > > > per VLAN? > > > > > > > > > > > > > > Is this the big optimization for which we care to create > > > > > > corner cases > > > > > > > and potential incompatibilities? > > > > > > > > > > > > > > -- Silvano > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > > > > > Radia Perlman; > > > > > > > > rbridge@postel.org > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray > > > (LO/EUS); Radia > > > > > > > > > Perlman; rbridge@postel.org > > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all > > > > RBridges have the > > > > > > > > > > information that would enable them to efficiently and > > > > > > > > > reliably act as > > > > > > > > > > an ARP/ND proxy. > > > > > > > > > > > > > > > > > > It depends on how you define the requirements of ARP/ND > > > > > > > > > proxy. I have seen this general mechanism used in many > > > > > > > > > contexts... only one of which is covered by an IETF RFC > > > > > > > > > (AFAIK). Bridges in their basic definition don't > > > > have ARP/ND > > > > > > > > > proxy. Only bridges that subsume some type of > > IP related > > > > > > > > > functionality contain these. > > > > > > > > > > > > > > > > > > If an RBridge "looks and smells" like a bridge, > > > > then there is > > > > > > > > > natural traffic separation between VLANs, and > > this allows > > > > > > > > > systems companies to view RBridges as "better bridges". > > > > > > > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > > > > > deal with the issues of large subnets far better than > > > > > > > > bridges do. > > > > > > > > > > > > > > > > Efficient distribution of ARP/ND information is also > > > > > > > > an issue where a "better bridge" is needed to scale > > > > > > > > to larger subnets efficiently. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 l34G6sxb010839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 09:06:55 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l34G6rAe029445; Wed, 4 Apr 2007 11:06:54 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 11:06:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 11:06:42 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFB068C0@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014BB3B3@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6gAAAPqTAAAZl3AAABIIFA References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8CC@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3B3@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com> X-OriginalArrivalTime: 04 Apr 2007 16:06:53.0762 (UTC) FILETIME=[43005220:01C776D3] 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 l34G6sxb010839 Cc: rbridge@postel.org Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 16:07:16 -0000 Status: RO Content-Length: 8979 JR, Just to be precise, in the working group discussions, we have been making a very strong distinction between multicast and broadcast. I agree that - in an environment where multicast is a large factor (where large means something like more than 1% of the total injected traffic), the traffic associated with ARP is way down in the noise. However, if any effective form of multicast optimization is implemented, the impact of potentially looping multicast can be scoped to affected VLANs (and possibly even to multicast "listeners") by techniques other than TTL (such as queue management that provides effective isolation of logical interfaces, or hard upper limits on total multicast traffic, for instance). -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Wednesday, April 04, 2007 11:26 AM > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > Importance: High > > > Sorry I must have mis-stated my point. It seems that if ARP > is the bulk > of your multicast traffic, then optimizing it doesn't seem like much > return-on-investment. If other multicast comprises the bulk, then > optimizing ARP doesn't seem to provide much return-on-investment. > > JR > > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > Sent: Wednesday, April 04, 2007 7:38 AM > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > > > It doesn't. However, you mentioned IP multicast as another area of > > concern... > > > > Thanks! > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > Sent: Wednesday, April 04, 2007 10:36 AM > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > Importance: High > > > > > > > > > Why does ARP/ND equate to IP multicast optimization? > > > > > > JR > > > > > > > > > > -----Original Message----- > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > Sent: Wednesday, April 04, 2007 7:34 AM > > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > > > Perlman; rbridge@postel.org > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > alternative proposals) > > > > > > > > JR, > > > > > > > > I agree. However, I believe we (as a working > group) have > > > > already > > > > agreed that the IP multicast optimization is essential. > > > > Also, it is my > > > > point (and it is certainly arguable) that perhaps TRILL > > > should not be > > > > targetting the general applications of L2 where other forms > > > > of L2 bcast > > > > are likely to be a significant factor - but should instead > > > > focus on the > > > > applications of L2 specific to IP only (or IP dominant) > networks. > > > > > > > > -- > > > > Eric Gray > > > > Principal Engineer > > > > Ericsson > > > > > > > > > -----Original Message----- > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > Sent: Wednesday, April 04, 2007 9:58 AM > > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > > > Perlman; rbridge@postel.org > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > alternative proposals) > > > > > Importance: High > > > > > > > > > > > > > > > It seems that if ARP is the bulk of your > > > > broadcast/multicast, then you > > > > > don't really need a very efficient broadcast/multicast > > > > > mechanism. Some > > > > > networks can be characterized as you've stated; > > however, there are > > > > > others that use L2/IP multicast in a substantial fashion. > > > > > > > > > > JR > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > > > Sent: Wednesday, April 04, 2007 6:14 AM > > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > > > > > Perlman; rbridge@postel.org > > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > alternative proposals) > > > > > > > > > > > > Silvano, > > > > > > > > > > > > Where IP (v4 or v6) is the exclusive higher > > > layer in a specific > > > > > > network deployment, it is likely that ARP is one of the > > > > most common > > > > > > forms of broadcast traffic that may occur. As we've > > > > > > previously agreed > > > > > > that broadcast traffic is of particular concern in > TRILL, the > > > > > > potential > > > > > > to drastically reduce (or possibly eliminate) common > > > > > broadcast traffic > > > > > > should be considered a worth-while objective. > > > > > > > > > > > > -- > > > > > > Eric Gray > > > > > > Principal Engineer > > > > > > Ericsson > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray > > (LO/EUS); Radia > > > > > > > Perlman; rbridge@postel.org > > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > > alternative proposals) > > > > > > > Importance: High > > > > > > > > > > > > > > > > > > > > > Do we have any quantitatively data about the need of > > > > ARP/ND proxy? > > > > > > > > > > > > > > With an ARP cache of 30 minutes, typical in hosts > > today, even > > > > > > > with a 100 > > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. > Since not > > > > > > > all the hosts > > > > > > > talk with each other, it is more typically like 5 ARP/sec. > > > > > > > > > > > > > > The ARP/ND cache on the RBridge must be significantly > > > > > > shorter than 30 > > > > > > > minutes to not increase the amount of obsolete > information. > > > > > > > > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for > 100 K hosts > > > > > > per VLAN? > > > > > > > > > > > > > > Is this the big optimization for which we care to create > > > > > > corner cases > > > > > > > and potential incompatibilities? > > > > > > > > > > > > > > -- Silvano > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > > > > > Radia Perlman; > > > > > > > > rbridge@postel.org > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray > > > (LO/EUS); Radia > > > > > > > > > Perlman; rbridge@postel.org > > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all > > > > RBridges have the > > > > > > > > > > information that would enable them to > efficiently and > > > > > > > > > reliably act as > > > > > > > > > > an ARP/ND proxy. > > > > > > > > > > > > > > > > > > It depends on how you define the requirements > of ARP/ND > > > > > > > > > proxy. I have seen this general mechanism > used in many > > > > > > > > > contexts... only one of which is covered by > an IETF RFC > > > > > > > > > (AFAIK). Bridges in their basic definition don't > > > > have ARP/ND > > > > > > > > > proxy. Only bridges that subsume some type of > > IP related > > > > > > > > > functionality contain these. > > > > > > > > > > > > > > > > > > If an RBridge "looks and smells" like a bridge, > > > > then there is > > > > > > > > > natural traffic separation between VLANs, and > > this allows > > > > > > > > > systems companies to view RBridges as "better > bridges". > > > > > > > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > > > > > deal with the issues of large subnets far better than > > > > > > > > bridges do. > > > > > > > > > > > > > > > > Efficient distribution of ARP/ND information is also > > > > > > > > an issue where a "better bridge" is needed to scale > > > > > > > > to larger subnets efficiently. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 l34FQQFY027607 for <rbridge@postel.org>; Wed, 4 Apr 2007 08:26:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 08:26:12 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014BB3B3@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACB8CC@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6gAAAPqTAAAZl3AA== References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8CC@eusrcmw721.eamcs.ericsson.se> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> 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 l34FQQFY027607 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 15:26:49 -0000 Status: RO Content-Length: 7416 Sorry I must have mis-stated my point. It seems that if ARP is the bulk of your multicast traffic, then optimizing it doesn't seem like much return-on-investment. If other multicast comprises the bulk, then optimizing ARP doesn't seem to provide much return-on-investment. JR > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 04, 2007 7:38 AM > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > > It doesn't. However, you mentioned IP multicast as another area of > concern... > > Thanks! > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > Sent: Wednesday, April 04, 2007 10:36 AM > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > Importance: High > > > > > > Why does ARP/ND equate to IP multicast optimization? > > > > JR > > > > > > > -----Original Message----- > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > Sent: Wednesday, April 04, 2007 7:34 AM > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > > > > JR, > > > > > > I agree. However, I believe we (as a working group) have > > > already > > > agreed that the IP multicast optimization is essential. > > > Also, it is my > > > point (and it is certainly arguable) that perhaps TRILL > > should not be > > > targetting the general applications of L2 where other forms > > > of L2 bcast > > > are likely to be a significant factor - but should instead > > > focus on the > > > applications of L2 specific to IP only (or IP dominant) networks. > > > > > > -- > > > Eric Gray > > > Principal Engineer > > > Ericsson > > > > > > > -----Original Message----- > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > Sent: Wednesday, April 04, 2007 9:58 AM > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > > Perlman; rbridge@postel.org > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > alternative proposals) > > > > Importance: High > > > > > > > > > > > > It seems that if ARP is the bulk of your > > > broadcast/multicast, then you > > > > don't really need a very efficient broadcast/multicast > > > > mechanism. Some > > > > networks can be characterized as you've stated; > however, there are > > > > others that use L2/IP multicast in a substantial fashion. > > > > > > > > JR > > > > > > > > > > > > > -----Original Message----- > > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > > Sent: Wednesday, April 04, 2007 6:14 AM > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > > > > Perlman; rbridge@postel.org > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > alternative proposals) > > > > > > > > > > Silvano, > > > > > > > > > > Where IP (v4 or v6) is the exclusive higher > > layer in a specific > > > > > network deployment, it is likely that ARP is one of the > > > most common > > > > > forms of broadcast traffic that may occur. As we've > > > > > previously agreed > > > > > that broadcast traffic is of particular concern in TRILL, the > > > > > potential > > > > > to drastically reduce (or possibly eliminate) common > > > > broadcast traffic > > > > > should be considered a worth-while objective. > > > > > > > > > > -- > > > > > Eric Gray > > > > > Principal Engineer > > > > > Ericsson > > > > > > > > > > > -----Original Message----- > > > > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray > (LO/EUS); Radia > > > > > > Perlman; rbridge@postel.org > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > > alternative proposals) > > > > > > Importance: High > > > > > > > > > > > > > > > > > > Do we have any quantitatively data about the need of > > > ARP/ND proxy? > > > > > > > > > > > > With an ARP cache of 30 minutes, typical in hosts > today, even > > > > > > with a 100 > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not > > > > > > all the hosts > > > > > > talk with each other, it is more typically like 5 ARP/sec. > > > > > > > > > > > > The ARP/ND cache on the RBridge must be significantly > > > > > shorter than 30 > > > > > > minutes to not increase the amount of obsolete information. > > > > > > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts > > > > > per VLAN? > > > > > > > > > > > > Is this the big optimization for which we care to create > > > > > corner cases > > > > > > and potential incompatibilities? > > > > > > > > > > > > -- Silvano > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > > > > Radia Perlman; > > > > > > > rbridge@postel.org > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray > > (LO/EUS); Radia > > > > > > > > Perlman; rbridge@postel.org > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all > > > RBridges have the > > > > > > > > > information that would enable them to efficiently and > > > > > > > > reliably act as > > > > > > > > > an ARP/ND proxy. > > > > > > > > > > > > > > > > It depends on how you define the requirements of ARP/ND > > > > > > > > proxy. I have seen this general mechanism used in many > > > > > > > > contexts... only one of which is covered by an IETF RFC > > > > > > > > (AFAIK). Bridges in their basic definition don't > > > have ARP/ND > > > > > > > > proxy. Only bridges that subsume some type of > IP related > > > > > > > > functionality contain these. > > > > > > > > > > > > > > > > If an RBridge "looks and smells" like a bridge, > > > then there is > > > > > > > > natural traffic separation between VLANs, and > this allows > > > > > > > > systems companies to view RBridges as "better bridges". > > > > > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > > > > deal with the issues of large subnets far better than > > > > > > > bridges do. > > > > > > > > > > > > > > Efficient distribution of ARP/ND information is also > > > > > > > an issue where a "better bridge" is needed to scale > > > > > > > to larger subnets efficiently. > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 l34EcVV6013775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 07:38:31 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l34EcTkG010178; Wed, 4 Apr 2007 09:38:29 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:38:29 -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, 4 Apr 2007 09:38:17 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB8CC@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6gAAAPqTA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 14:38:29.0147 (UTC) FILETIME=[E9344EB0:01C776C6] 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 l34EcVV6013775 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 14:39:09 -0000 Status: RO Content-Length: 6428 It doesn't. However, you mentioned IP multicast as another area of concern... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Wednesday, April 04, 2007 10:36 AM > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > Importance: High > > > Why does ARP/ND equate to IP multicast optimization? > > JR > > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > Sent: Wednesday, April 04, 2007 7:34 AM > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > > > JR, > > > > I agree. However, I believe we (as a working group) have > > already > > agreed that the IP multicast optimization is essential. > > Also, it is my > > point (and it is certainly arguable) that perhaps TRILL > should not be > > targetting the general applications of L2 where other forms > > of L2 bcast > > are likely to be a significant factor - but should instead > > focus on the > > applications of L2 specific to IP only (or IP dominant) networks. > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > Sent: Wednesday, April 04, 2007 9:58 AM > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > Importance: High > > > > > > > > > It seems that if ARP is the bulk of your > > broadcast/multicast, then you > > > don't really need a very efficient broadcast/multicast > > > mechanism. Some > > > networks can be characterized as you've stated; however, there are > > > others that use L2/IP multicast in a substantial fashion. > > > > > > JR > > > > > > > > > > -----Original Message----- > > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > > Sent: Wednesday, April 04, 2007 6:14 AM > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > > > Perlman; rbridge@postel.org > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > alternative proposals) > > > > > > > > Silvano, > > > > > > > > Where IP (v4 or v6) is the exclusive higher > layer in a specific > > > > network deployment, it is likely that ARP is one of the > > most common > > > > forms of broadcast traffic that may occur. As we've > > > > previously agreed > > > > that broadcast traffic is of particular concern in TRILL, the > > > > potential > > > > to drastically reduce (or possibly eliminate) common > > > broadcast traffic > > > > should be considered a worth-while objective. > > > > > > > > -- > > > > Eric Gray > > > > Principal Engineer > > > > Ericsson > > > > > > > > > -----Original Message----- > > > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > > > > > Perlman; rbridge@postel.org > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > > alternative proposals) > > > > > Importance: High > > > > > > > > > > > > > > > Do we have any quantitatively data about the need of > > ARP/ND proxy? > > > > > > > > > > With an ARP cache of 30 minutes, typical in hosts today, even > > > > > with a 100 > > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not > > > > > all the hosts > > > > > talk with each other, it is more typically like 5 ARP/sec. > > > > > > > > > > The ARP/ND cache on the RBridge must be significantly > > > > shorter than 30 > > > > > minutes to not increase the amount of obsolete information. > > > > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts > > > > per VLAN? > > > > > > > > > > Is this the big optimization for which we care to create > > > > corner cases > > > > > and potential incompatibilities? > > > > > > > > > > -- Silvano > > > > > > > > > > > -----Original Message----- > > > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > > > Radia Perlman; > > > > > > rbridge@postel.org > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > alternative proposals > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray > (LO/EUS); Radia > > > > > > > Perlman; rbridge@postel.org > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > > alternative proposals > > > > > > > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all > > RBridges have the > > > > > > > > information that would enable them to efficiently and > > > > > > > reliably act as > > > > > > > > an ARP/ND proxy. > > > > > > > > > > > > > > It depends on how you define the requirements of ARP/ND > > > > > > > proxy. I have seen this general mechanism used in many > > > > > > > contexts... only one of which is covered by an IETF RFC > > > > > > > (AFAIK). Bridges in their basic definition don't > > have ARP/ND > > > > > > > proxy. Only bridges that subsume some type of IP related > > > > > > > functionality contain these. > > > > > > > > > > > > > > If an RBridge "looks and smells" like a bridge, > > then there is > > > > > > > natural traffic separation between VLANs, and this allows > > > > > > > systems companies to view RBridges as "better bridges". > > > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > > > deal with the issues of large subnets far better than > > > > > > bridges do. > > > > > > > > > > > > Efficient distribution of ARP/ND information is also > > > > > > an issue where a "better bridge" is needed to scale > > > > > > to larger subnets efficiently. > > > > > > > > > > > > > > > > > > > > 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 l34EaFlq013290 for <rbridge@postel.org>; Wed, 4 Apr 2007 07:36: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: Wed, 4 Apr 2007 07:36:01 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014BB3A5@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQAAAMH6g References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> 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 l34EaFlq013290 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 14:36:39 -0000 Status: RO Content-Length: 5616 Why does ARP/ND equate to IP multicast optimization? JR > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 04, 2007 7:34 AM > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > > JR, > > I agree. However, I believe we (as a working group) have > already > agreed that the IP multicast optimization is essential. > Also, it is my > point (and it is certainly arguable) that perhaps TRILL should not be > targetting the general applications of L2 where other forms > of L2 bcast > are likely to be a significant factor - but should instead > focus on the > applications of L2 specific to IP only (or IP dominant) networks. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > Sent: Wednesday, April 04, 2007 9:58 AM > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > Importance: High > > > > > > It seems that if ARP is the bulk of your > broadcast/multicast, then you > > don't really need a very efficient broadcast/multicast > > mechanism. Some > > networks can be characterized as you've stated; however, there are > > others that use L2/IP multicast in a substantial fashion. > > > > JR > > > > > > > -----Original Message----- > > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > > Sent: Wednesday, April 04, 2007 6:14 AM > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > > > > Silvano, > > > > > > Where IP (v4 or v6) is the exclusive higher layer in a specific > > > network deployment, it is likely that ARP is one of the > most common > > > forms of broadcast traffic that may occur. As we've > > > previously agreed > > > that broadcast traffic is of particular concern in TRILL, the > > > potential > > > to drastically reduce (or possibly eliminate) common > > broadcast traffic > > > should be considered a worth-while objective. > > > > > > -- > > > Eric Gray > > > Principal Engineer > > > Ericsson > > > > > > > -----Original Message----- > > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > > > > Perlman; rbridge@postel.org > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > > alternative proposals) > > > > Importance: High > > > > > > > > > > > > Do we have any quantitatively data about the need of > ARP/ND proxy? > > > > > > > > With an ARP cache of 30 minutes, typical in hosts today, even > > > > with a 100 > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not > > > > all the hosts > > > > talk with each other, it is more typically like 5 ARP/sec. > > > > > > > > The ARP/ND cache on the RBridge must be significantly > > > shorter than 30 > > > > minutes to not increase the amount of obsolete information. > > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts > > > per VLAN? > > > > > > > > Is this the big optimization for which we care to create > > > corner cases > > > > and potential incompatibilities? > > > > > > > > -- Silvano > > > > > > > > > -----Original Message----- > > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > > Radia Perlman; > > > > > rbridge@postel.org > > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > > > > > Perlman; rbridge@postel.org > > > > > > Subject: RE: [rbridge] Two "shared VLAN" > alternative proposals > > > > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all > RBridges have the > > > > > > > information that would enable them to efficiently and > > > > > > reliably act as > > > > > > > an ARP/ND proxy. > > > > > > > > > > > > It depends on how you define the requirements of ARP/ND > > > > > > proxy. I have seen this general mechanism used in many > > > > > > contexts... only one of which is covered by an IETF RFC > > > > > > (AFAIK). Bridges in their basic definition don't > have ARP/ND > > > > > > proxy. Only bridges that subsume some type of IP related > > > > > > functionality contain these. > > > > > > > > > > > > If an RBridge "looks and smells" like a bridge, > then there is > > > > > > natural traffic separation between VLANs, and this allows > > > > > > systems companies to view RBridges as "better bridges". > > > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > > deal with the issues of large subnets far better than > > > > > bridges do. > > > > > > > > > > Efficient distribution of ARP/ND information is also > > > > > an issue where a "better bridge" is needed to scale > > > > > to larger subnets efficiently. > > > > > > > > > > > > > > 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 l34EY1ie012426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 07:34:01 -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 l34ExffA008536; Wed, 4 Apr 2007 09:59:42 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:33:57 -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, 4 Apr 2007 09:33:46 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB8BE@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUAAATFVQA== References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 14:33:57.0868 (UTC) FILETIME=[47826AC0:01C776C6] 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 l34EY1ie012426 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 14:34:43 -0000 Status: RO Content-Length: 4932 JR, I agree. However, I believe we (as a working group) have already agreed that the IP multicast optimization is essential. Also, it is my point (and it is certainly arguable) that perhaps TRILL should not be targetting the general applications of L2 where other forms of L2 bcast are likely to be a significant factor - but should instead focus on the applications of L2 specific to IP only (or IP dominant) networks. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Wednesday, April 04, 2007 9:58 AM > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > Importance: High > > > It seems that if ARP is the bulk of your broadcast/multicast, then you > don't really need a very efficient broadcast/multicast > mechanism. Some > networks can be characterized as you've stated; however, there are > others that use L2/IP multicast in a substantial fashion. > > JR > > > > -----Original Message----- > > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > > Sent: Wednesday, April 04, 2007 6:14 AM > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > > Perlman; rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > > > Silvano, > > > > Where IP (v4 or v6) is the exclusive higher layer in a specific > > network deployment, it is likely that ARP is one of the most common > > forms of broadcast traffic that may occur. As we've > > previously agreed > > that broadcast traffic is of particular concern in TRILL, the > > potential > > to drastically reduce (or possibly eliminate) common > broadcast traffic > > should be considered a worth-while objective. > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > Sent: Tuesday, April 03, 2007 7:22 PM > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > > > Perlman; rbridge@postel.org > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > Importance: High > > > > > > > > > Do we have any quantitatively data about the need of ARP/ND proxy? > > > > > > With an ARP cache of 30 minutes, typical in hosts today, even > > > with a 100 > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not > > > all the hosts > > > talk with each other, it is more typically like 5 ARP/sec. > > > > > > The ARP/ND cache on the RBridge must be significantly > > shorter than 30 > > > minutes to not increase the amount of obsolete information. > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts > > per VLAN? > > > > > > Is this the big optimization for which we care to create > > corner cases > > > and potential incompatibilities? > > > > > > -- Silvano > > > > > > > -----Original Message----- > > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); > Radia Perlman; > > > > rbridge@postel.org > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > > > > Perlman; rbridge@postel.org > > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > > > > At the minimum we need to ensure that all RBridges have the > > > > > > information that would enable them to efficiently and > > > > > reliably act as > > > > > > an ARP/ND proxy. > > > > > > > > > > It depends on how you define the requirements of ARP/ND > > > > > proxy. I have seen this general mechanism used in many > > > > > contexts... only one of which is covered by an IETF RFC > > > > > (AFAIK). Bridges in their basic definition don't have ARP/ND > > > > > proxy. Only bridges that subsume some type of IP related > > > > > functionality contain these. > > > > > > > > > > If an RBridge "looks and smells" like a bridge, then there is > > > > > natural traffic separation between VLANs, and this allows > > > > > systems companies to view RBridges as "better bridges". > > > > > > > > > > JR > > > > > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > > deal with the issues of large subnets far better than > > > > bridges do. > > > > > > > > Efficient distribution of ARP/ND information is also > > > > an issue where a "better bridge" is needed to scale > > > > to larger subnets efficiently. > > > > > > > > > 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 l34Dw2BE002549 for <rbridge@postel.org>; Wed, 4 Apr 2007 06:58:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 06:57:48 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014BB39A@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaAAAGwMUA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> 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 l34Dw2BE002549 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 13:58:32 -0000 Status: RO Content-Length: 3895 It seems that if ARP is the bulk of your broadcast/multicast, then you don't really need a very efficient broadcast/multicast mechanism. Some networks can be characterized as you've stated; however, there are others that use L2/IP multicast in a substantial fashion. JR > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@ericsson.com] > Sent: Wednesday, April 04, 2007 6:14 AM > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > > Silvano, > > Where IP (v4 or v6) is the exclusive higher layer in a specific > network deployment, it is likely that ARP is one of the most common > forms of broadcast traffic that may occur. As we've > previously agreed > that broadcast traffic is of particular concern in TRILL, the > potential > to drastically reduce (or possibly eliminate) common broadcast traffic > should be considered a worth-while objective. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > Sent: Tuesday, April 03, 2007 7:22 PM > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > > Perlman; rbridge@postel.org > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > Importance: High > > > > > > Do we have any quantitatively data about the need of ARP/ND proxy? > > > > With an ARP cache of 30 minutes, typical in hosts today, even > > with a 100 > > K hosts in a VLAN we get at most 55 ARP seconds. Since not > > all the hosts > > talk with each other, it is more typically like 5 ARP/sec. > > > > The ARP/ND cache on the RBridge must be significantly > shorter than 30 > > minutes to not increase the amount of obsolete information. > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts > per VLAN? > > > > Is this the big optimization for which we care to create > corner cases > > and potential incompatibilities? > > > > -- Silvano > > > > > -----Original Message----- > > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > > Sent: Tuesday, April 03, 2007 3:38 PM > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman; > > > rbridge@postel.org > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > > > > > -----Original Message----- > > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > > > Perlman; rbridge@postel.org > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > > > > snip... > > > > > > > > > > > > > > > At the minimum we need to ensure that all RBridges have the > > > > > information that would enable them to efficiently and > > > > reliably act as > > > > > an ARP/ND proxy. > > > > > > > > It depends on how you define the requirements of ARP/ND > > > > proxy. I have seen this general mechanism used in many > > > > contexts... only one of which is covered by an IETF RFC > > > > (AFAIK). Bridges in their basic definition don't have ARP/ND > > > > proxy. Only bridges that subsume some type of IP related > > > > functionality contain these. > > > > > > > > If an RBridge "looks and smells" like a bridge, then there is > > > > natural traffic separation between VLANs, and this allows > > > > systems companies to view RBridges as "better bridges". > > > > > > > > JR > > > > > > > > > > > > > > The reason RBridges are "better bridges" is that they > > > deal with the issues of large subnets far better than > > > bridges do. > > > > > > Efficient distribution of ARP/ND information is also > > > an issue where a "better bridge" is needed to scale > > > to larger subnets efficiently. > > > > > 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 l34DDmmX019823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 06:13:48 -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 l34DdU66028803; Wed, 4 Apr 2007 08:39:30 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 08:13:46 -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, 4 Apr 2007 08:13:37 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB794@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAdIqaA References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "J. R. Rivers" <jrrivers@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 13:13:46.0742 (UTC) FILETIME=[13DAD960:01C776BB] 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 l34DDmmX019823 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 13:14:06 -0000 Status: RO Content-Length: 3114 Silvano, Where IP (v4 or v6) is the exclusive higher layer in a specific network deployment, it is likely that ARP is one of the most common forms of broadcast traffic that may occur. As we've previously agreed that broadcast traffic is of particular concern in TRILL, the potential to drastically reduce (or possibly eliminate) common broadcast traffic should be considered a worth-while objective. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Tuesday, April 03, 2007 7:22 PM > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > Importance: High > > > Do we have any quantitatively data about the need of ARP/ND proxy? > > With an ARP cache of 30 minutes, typical in hosts today, even > with a 100 > K hosts in a VLAN we get at most 55 ARP seconds. Since not > all the hosts > talk with each other, it is more typically like 5 ARP/sec. > > The ARP/ND cache on the RBridge must be significantly shorter than 30 > minutes to not increase the amount of obsolete information. > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN? > > Is this the big optimization for which we care to create corner cases > and potential incompatibilities? > > -- Silvano > > > -----Original Message----- > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > Sent: Tuesday, April 03, 2007 3:38 PM > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman; > > rbridge@postel.org > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > -----Original Message----- > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > snip... > > > > > > > > > > > > At the minimum we need to ensure that all RBridges have the > > > > information that would enable them to efficiently and > > > reliably act as > > > > an ARP/ND proxy. > > > > > > It depends on how you define the requirements of ARP/ND > > > proxy. I have seen this general mechanism used in many > > > contexts... only one of which is covered by an IETF RFC > > > (AFAIK). Bridges in their basic definition don't have ARP/ND > > > proxy. Only bridges that subsume some type of IP related > > > functionality contain these. > > > > > > If an RBridge "looks and smells" like a bridge, then there is > > > natural traffic separation between VLANs, and this allows > > > systems companies to view RBridges as "better bridges". > > > > > > JR > > > > > > > > > > The reason RBridges are "better bridges" is that they > > deal with the issues of large subnets far better than > > bridges do. > > > > Efficient distribution of ARP/ND information is also > > an issue where a "better bridge" is needed to scale > > to larger subnets efficiently. > > 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 l34D6Pn7018151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 06:06:26 -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 l34D6O4B023065; Wed, 4 Apr 2007 08:06:24 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 08:06:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 08:06:14 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB779@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467B67@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAAoljQAAB3AuAAG+CZkA== References: <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BAC47@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467B67@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "J. R. Rivers" <jrrivers@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 13:06:24.0276 (UTC) FILETIME=[0C1FE540:01C776BA] 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 l34D6Pn7018151 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 04 Apr 2007 13:07:02 -0000 Status: RO Content-Length: 2663 Silvano, It's possible that Caitlin made a mis-statement. The impact of a larger propagation radius is in the number of branches that usually is implied by such an increase. More branches, more risks of looping broadcast and/or multicast traffic, hence more impetus to reduce both. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Tuesday, April 03, 2007 7:48 PM > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > Importance: High > > > I am surprised, > in ARP the dominant time is the software processing on the two nodes > that goes through a classical interrupt moderation technique > and exceed > multiple milliseconds. The Rbridge latency is probably 1 to 10 > microseconds, so even if you have 100 hops, it is still negligible. > > -- Silvano > > > -----Original Message----- > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > Sent: Tuesday, April 03, 2007 4:37 PM > > To: Silvano Gai; J. R. Rivers; Eric Gray (LO/EUS); Radia Perlman; > > rbridge@postel.org > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative > > proposals) > > > > > > > > > -----Original Message----- > > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > > Sent: Tuesday, April 03, 2007 4:22 PM > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > > > Perlman; rbridge@postel.org > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > > alternative proposals) > > > > > > > > > Do we have any quantitatively data about the need of ARP/ND proxy? > > > > > > With an ARP cache of 30 minutes, typical in hosts today, even > > > with a 100 K hosts in a VLAN we get at most 55 ARP seconds. > > > Since not all the hosts talk with each other, it is more > > > typically like 5 ARP/sec. > > > > > > The ARP/ND cache on the RBridge must be significantly shorter > > > than 30 minutes to not increase the amount of obsolete > information. > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per > VLAN? > > > > > > Is this the big optimization for which we care to create > > > corner cases and potential incompatibilities? > > > > > > > The ARP/ND transaction rate is not the critical issue. > > > > The more critical issue is the end-to-end latency of a transaction > > that requires doing an ARP/ND first. As the subnet gets larger, > > and the number of "L2 Hops" increases, that answer gets worse > > unless you implement a distributed ARP/ND proxy service. > > > > > > > > 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 l34CGI0s005492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 05:16:18 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l34CGFqE014875; Wed, 4 Apr 2007 07:16:15 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 07:16:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 07:16:05 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB6EB@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467AF0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAFDs4AAcY0wA References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467AF0@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 12:16:15.0577 (UTC) FILETIME=[0ACCDC90:01C776B3] 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 l34CGI0s005492 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 04 Apr 2007 12:16:30 -0000 Status: RO Content-Length: 2366 And you would be correct. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Tuesday, April 03, 2007 6:47 PM > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > Importance: High > > > I would have thought that RBridges are "better bridges" because they > allow multi-pathing at layer 2 creating significantly more available > bandwidth and with a deployment cost/complexity relatively close to > 802.1 bridges. > > JR > > > -----Original Message----- > > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > > Sent: Tuesday, April 03, 2007 3:38 PM > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia > > Perlman; rbridge@postel.org > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > -----Original Message----- > > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > > Sent: Tuesday, April 03, 2007 3:31 PM > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > > Perlman; rbridge@postel.org > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > > > > snip... > > > > > > > > > > > > At the minimum we need to ensure that all RBridges have the > > > > information that would enable them to efficiently and > > > reliably act as > > > > an ARP/ND proxy. > > > > > > It depends on how you define the requirements of ARP/ND > > > proxy. I have seen this general mechanism used in many > > > contexts... only one of which is covered by an IETF RFC > > > (AFAIK). Bridges in their basic definition don't have ARP/ND > > > proxy. Only bridges that subsume some type of IP related > > > functionality contain these. > > > > > > If an RBridge "looks and smells" like a bridge, then there is > > > natural traffic separation between VLANs, and this allows > > > systems companies to view RBridges as "better bridges". > > > > > > JR > > > > > > > > > > The reason RBridges are "better bridges" is that they > > deal with the issues of large subnets far better than > > bridges do. > > > > Efficient distribution of ARP/ND information is also > > an issue where a "better bridge" is needed to scale > > to larger subnets efficiently. > > > > > 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 l34CFA4h005210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 05:15:11 -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 l34CeqOB021791; Wed, 4 Apr 2007 07:40:52 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 07:15:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2007 07:14:59 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB6E9@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwABzhsWA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467875@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABC2@NT-IRVA-0750.brcm.ad.broadcom.com> <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 12:15:09.0186 (UTC) FILETIME=[E33A6620:01C776B2] 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 l34CFA4h005210 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 04 Apr 2007 12:15:39 -0000 Status: RO Content-Length: 2762 JR, I agree that "natural traffic separation between VLANs" is a requirement. This, however, does not mean that an ARP/ND optimization within the separate VLANs is in any way unnatural. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Tuesday, April 03, 2007 6:31 PM > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > Importance: High > > > snip... > > > > > > At the minimum we need to ensure that all RBridges have > > the information that would enable them to efficiently > > and reliably act as an ARP/ND proxy. > > It depends on how you define the requirements of ARP/ND proxy. I have > seen this general mechanism used in many contexts... only one of which > is covered by an IETF RFC (AFAIK). Bridges in their basic definition > don't have ARP/ND proxy. Only bridges that subsume some type of IP > related functionality contain these. > > If an RBridge "looks and smells" like a bridge, then there is natural > traffic separation between VLANs, and this allows systems companies to > view RBridges as "better bridges". > > JR > > > > > > By the very nature of a proxy it is hard to state that > > it MUST do anything. Any proxy will have a limit on the > > information that it can cache, and can therefore fail > > to act as a proxy on some occassions. So anything that > > is a proxy function strikes me as inherently a SHOULD > > at most. > > > > That said, all of the arguments on why an RBridge is > > valuable also imply that proxying ARP/ND is a vital > > part of the RBridge's functionality. > > > > In particular, I believe that the trends towards > > server virtualization and physically more compact > > servers both will lead to an increase in the logical > > size of IP subnets. That makes the role of ARP/ND > > proxying more important, and makes it all the more > > desirable not to routinely run these queries from > > one end of the CRED to the other important. > > > > In a virtualization context I also think it makes > > for more sense for each Virtual Machine to be able > > to obtain the ARP/ND info for host X when it needs > > it without having *each* of them having to do an > > end-to-end query or forcing each of them to hear > > every ARP response so that each virtual machine > > can maintain its own ARP table in parallel. > > The RBridge is simply in the ideal position to > > perform a highly optimized ARP/ND proxy role. > > > > > > > > _______________________________________________ > > 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 l34CBxGF004019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 4 Apr 2007 05:12:00 -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 l34CBvaS014145; Wed, 4 Apr 2007 07:11:57 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 07:11:57 -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, 4 Apr 2007 07:11:46 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB6E6@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BABC2@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAAdeUWQ References: <34BDD2A93E5FD84594BB230DD6C18EA201467875@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABC2@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: <rbridge@postel.org> X-OriginalArrivalTime: 04 Apr 2007 12:11:57.0735 (UTC) FILETIME=[711D4B70:01C776B2] 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 l34CBxGF004019 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 04 Apr 2007 12:12:47 -0000 Status: RO Content-Length: 4109 I agree with all of the reasons Caitlin states below and would add two more reasons for including ARP/ND as at least a capability: 1) One particular attribute of this work is the use of TTL as a loop mitigation technique; an obvious aspect of this approach is its total inadequacy in addressing loops in pt-2-mp traffic - hence it is imperative that anything that can be done to reduce both the absolute quantity, and the number of paths involved, in pt-2-mp traffic is considered to be very important. 2) The TRILL solution - coming as it does from the IETF community - needs to be specific to applications of IP (v4 or v6) and therefore needs to consider optimization for such applications of primary concern. I would further clarify one of Caitlin's points by saying that it is pointless to consider defining ARP/ND for later inclusion if we have not included the basic capabilities in the protocol. Specifically, if we have not included the data structures and behaviors necessary to ensure the distribution of information required to support ARP/ND, then subsequent work to add these basic capabilities will introduce potential compatibility issues and limitations. What all of this seems to mean is that we should define how ARP/ND information could be distributed aqnd what information we know has to be included. Then we may leave the specification of what to do with that information to a later date. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Tuesday, April 03, 2007 6:06 PM > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman; rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > Importance: High > > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > > Sent: Tuesday, April 03, 2007 8:16 AM > > To: Eric Gray (LO/EUS); Radia Perlman; rbridge@postel.org > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > > > > Eric, > > > > I will go one step further and say that the basic TRILL > > protocol should not specify an ARP/ND proxy function. > > > > As the discussion as pointed out, ARP/ND proxy is more a > > product feature that depends on how the box are packaged. > > IMHO RBridges will be packaged with additional router, NAT, > > firewall functionalities. If and where proxy ARP will be > > implemented will vary. > > > > After the last call on the base protocol, we can always > > resume the work and deal with Proxy ARP/ND in a separate document. > > > > -- Silvano > > > > At the minimum we need to ensure that all RBridges have > the information that would enable them to efficiently > and reliably act as an ARP/ND proxy. > > By the very nature of a proxy it is hard to state that > it MUST do anything. Any proxy will have a limit on the > information that it can cache, and can therefore fail > to act as a proxy on some occassions. So anything that > is a proxy function strikes me as inherently a SHOULD > at most. > > That said, all of the arguments on why an RBridge is > valuable also imply that proxying ARP/ND is a vital > part of the RBridge's functionality. > > In particular, I believe that the trends towards > server virtualization and physically more compact > servers both will lead to an increase in the logical > size of IP subnets. That makes the role of ARP/ND > proxying more important, and makes it all the more > desirable not to routinely run these queries from > one end of the CRED to the other important. > > In a virtualization context I also think it makes > for more sense for each Virtual Machine to be able > to obtain the ARP/ND info for host X when it needs > it without having *each* of them having to do an > end-to-end query or forcing each of them to hear > every ARP response so that each virtual machine > can maintain its own ARP table in parallel. > The RBridge is simply in the ideal position to > perform a highly optimized ARP/ND proxy role. > > > 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 l33NmSNU005275 for <rbridge@postel.org>; Tue, 3 Apr 2007 16:48:28 -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, 3 Apr 2007 16:48:16 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467B67@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BAC47@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAAoljQAAB3AuA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BAC47@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "J. R. Rivers" <jrrivers@nuovasystems.com>, "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.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 l33NmSNU005275 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 03 Apr 2007 23:49:21 -0000 Status: RO Content-Length: 1890 I am surprised, in ARP the dominant time is the software processing on the two nodes that goes through a classical interrupt moderation technique and exceed multiple milliseconds. The Rbridge latency is probably 1 to 10 microseconds, so even if you have 100 hops, it is still negligible. -- Silvano > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Tuesday, April 03, 2007 4:37 PM > To: Silvano Gai; J. R. Rivers; Eric Gray (LO/EUS); Radia Perlman; > rbridge@postel.org > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative > proposals) > > > > > -----Original Message----- > > From: Silvano Gai [mailto:sgai@nuovasystems.com] > > Sent: Tuesday, April 03, 2007 4:22 PM > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > > Perlman; rbridge@postel.org > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > > alternative proposals) > > > > > > Do we have any quantitatively data about the need of ARP/ND proxy? > > > > With an ARP cache of 30 minutes, typical in hosts today, even > > with a 100 K hosts in a VLAN we get at most 55 ARP seconds. > > Since not all the hosts talk with each other, it is more > > typically like 5 ARP/sec. > > > > The ARP/ND cache on the RBridge must be significantly shorter > > than 30 minutes to not increase the amount of obsolete information. > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN? > > > > Is this the big optimization for which we care to create > > corner cases and potential incompatibilities? > > > > The ARP/ND transaction rate is not the critical issue. > > The more critical issue is the end-to-end latency of a transaction > that requires doing an ARP/ND first. As the subnet gets larger, > and the number of "L2 Hops" increases, that answer gets worse > unless you implement a distributed ARP/ND proxy service. > > > 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 l33Nb3bS002718 for <rbridge@postel.org>; Tue, 3 Apr 2007 16:37:03 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 03 Apr 2007 16:36:54 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1BEEB2AE; Tue, 3 Apr 2007 16:36: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 0312D2B0; Tue, 3 Apr 2007 16:36: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 FDO42163; Tue, 3 Apr 2007 16:36:49 -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 DC25D69CA3; Tue, 3 Apr 2007 16:36:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Apr 2007 16:36:47 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BAC47@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesAAAoljQ From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "J. R. Rivers" <jrrivers@nuovasystems.com>, "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A0C3A9C38G12305808-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 l33Nb3bS002718 Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 03 Apr 2007 23:37:21 -0000 Status: RO Content-Length: 1232 > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Tuesday, April 03, 2007 4:22 PM > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" > alternative proposals) > > > Do we have any quantitatively data about the need of ARP/ND proxy? > > With an ARP cache of 30 minutes, typical in hosts today, even > with a 100 K hosts in a VLAN we get at most 55 ARP seconds. > Since not all the hosts talk with each other, it is more > typically like 5 ARP/sec. > > The ARP/ND cache on the RBridge must be significantly shorter > than 30 minutes to not increase the amount of obsolete information. > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN? > > Is this the big optimization for which we care to create > corner cases and potential incompatibilities? > The ARP/ND transaction rate is not the critical issue. The more critical issue is the end-to-end latency of a transaction that requires doing an ARP/ND first. As the subnet gets larger, and the number of "L2 Hops" increases, that answer gets worse unless you implement a distributed ARP/ND proxy service. 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 l33NMZW8029211 for <rbridge@postel.org>; Tue, 3 Apr 2007 16:22:35 -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, 3 Apr 2007 16:22:23 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467B2D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative proposals) thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAWBesA== References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "J. R. Rivers" <jrrivers@nuovasystems.com>, "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.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 l33NMZW8029211 Subject: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals) 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, 03 Apr 2007 23:22:58 -0000 Status: RO Content-Length: 2207 Do we have any quantitatively data about the need of ARP/ND proxy? With an ARP cache of 30 minutes, typical in hosts today, even with a 100 K hosts in a VLAN we get at most 55 ARP seconds. Since not all the hosts talk with each other, it is more typically like 5 ARP/sec. The ARP/ND cache on the RBridge must be significantly shorter than 30 minutes to not increase the amount of obsolete information. Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN? Is this the big optimization for which we care to create corner cases and potential incompatibilities? -- Silvano > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Tuesday, April 03, 2007 3:38 PM > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman; > rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > -----Original Message----- > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > Sent: Tuesday, April 03, 2007 3:31 PM > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > Perlman; rbridge@postel.org > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > snip... > > > > > > > > > At the minimum we need to ensure that all RBridges have the > > > information that would enable them to efficiently and > > reliably act as > > > an ARP/ND proxy. > > > > It depends on how you define the requirements of ARP/ND > > proxy. I have seen this general mechanism used in many > > contexts... only one of which is covered by an IETF RFC > > (AFAIK). Bridges in their basic definition don't have ARP/ND > > proxy. Only bridges that subsume some type of IP related > > functionality contain these. > > > > If an RBridge "looks and smells" like a bridge, then there is > > natural traffic separation between VLANs, and this allows > > systems companies to view RBridges as "better bridges". > > > > JR > > > > > > The reason RBridges are "better bridges" is that they > deal with the issues of large subnets far better than > bridges do. > > Efficient distribution of ARP/ND information is also > an issue where a "better bridge" is needed to scale > to larger subnets efficiently. 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 l33Mkt8P019424 for <rbridge@postel.org>; Tue, 3 Apr 2007 15:46:55 -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, 3 Apr 2007 15:46:42 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467AF0@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBAAAFDs4A== References: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> 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 l33Mkt8P019424 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 22:47:32 -0000 Status: RO Content-Length: 1872 I would have thought that RBridges are "better bridges" because they allow multi-pathing at layer 2 creating significantly more available bandwidth and with a deployment cost/complexity relatively close to 802.1 bridges. JR > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Tuesday, April 03, 2007 3:38 PM > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > -----Original Message----- > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > Sent: Tuesday, April 03, 2007 3:31 PM > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > > Perlman; rbridge@postel.org > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > > > > snip... > > > > > > > > > At the minimum we need to ensure that all RBridges have the > > > information that would enable them to efficiently and > > reliably act as > > > an ARP/ND proxy. > > > > It depends on how you define the requirements of ARP/ND > > proxy. I have seen this general mechanism used in many > > contexts... only one of which is covered by an IETF RFC > > (AFAIK). Bridges in their basic definition don't have ARP/ND > > proxy. Only bridges that subsume some type of IP related > > functionality contain these. > > > > If an RBridge "looks and smells" like a bridge, then there is > > natural traffic separation between VLANs, and this allows > > systems companies to view RBridges as "better bridges". > > > > JR > > > > > > The reason RBridges are "better bridges" is that they > deal with the issues of large subnets far better than > bridges do. > > Efficient distribution of ARP/ND information is also > an issue where a "better bridge" is needed to scale > to larger subnets efficiently. > > 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 l33McDxL016972 for <rbridge@postel.org>; Tue, 3 Apr 2007 15:38:13 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 03 Apr 2007 15:38:02 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 078152AF; Tue, 3 Apr 2007 15:38:02 -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 E5BB92AE; Tue, 3 Apr 2007 15:38:01 -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 FDO30727; Tue, 3 Apr 2007 15:38:01 -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 78A8569CA3; Tue, 3 Apr 2007 15:38:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Apr 2007 15:38:00 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BABEA@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDwAABItBA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A0C08C03A412214015-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 l33McDxL016972 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 22:38:29 -0000 Status: RO Content-Length: 1277 > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Tuesday, April 03, 2007 3:31 PM > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia > Perlman; rbridge@postel.org > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals > > > snip... > > > > > > At the minimum we need to ensure that all RBridges have the > > information that would enable them to efficiently and > reliably act as > > an ARP/ND proxy. > > It depends on how you define the requirements of ARP/ND > proxy. I have seen this general mechanism used in many > contexts... only one of which is covered by an IETF RFC > (AFAIK). Bridges in their basic definition don't have ARP/ND > proxy. Only bridges that subsume some type of IP related > functionality contain these. > > If an RBridge "looks and smells" like a bridge, then there is > natural traffic separation between VLANs, and this allows > systems companies to view RBridges as "better bridges". > > JR > > The reason RBridges are "better bridges" is that they deal with the issues of large subnets far better than bridges do. Efficient distribution of ARP/ND information is also an issue where a "better bridge" is needed to scale to larger subnets efficiently. 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 l33MVVO1015313 for <rbridge@postel.org>; Tue, 3 Apr 2007 15:31:31 -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, 3 Apr 2007 15:31:18 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467AD8@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BABC2@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQAABJuDw References: <34BDD2A93E5FD84594BB230DD6C18EA201467875@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BABC2@NT-IRVA-0750.brcm.ad.broadcom.com> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> 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 l33MVVO1015313 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 22:31:49 -0000 Status: RO Content-Length: 2101 snip... > > > At the minimum we need to ensure that all RBridges have > the information that would enable them to efficiently > and reliably act as an ARP/ND proxy. It depends on how you define the requirements of ARP/ND proxy. I have seen this general mechanism used in many contexts... only one of which is covered by an IETF RFC (AFAIK). Bridges in their basic definition don't have ARP/ND proxy. Only bridges that subsume some type of IP related functionality contain these. If an RBridge "looks and smells" like a bridge, then there is natural traffic separation between VLANs, and this allows systems companies to view RBridges as "better bridges". JR > > By the very nature of a proxy it is hard to state that > it MUST do anything. Any proxy will have a limit on the > information that it can cache, and can therefore fail > to act as a proxy on some occassions. So anything that > is a proxy function strikes me as inherently a SHOULD > at most. > > That said, all of the arguments on why an RBridge is > valuable also imply that proxying ARP/ND is a vital > part of the RBridge's functionality. > > In particular, I believe that the trends towards > server virtualization and physically more compact > servers both will lead to an increase in the logical > size of IP subnets. That makes the role of ARP/ND > proxying more important, and makes it all the more > desirable not to routinely run these queries from > one end of the CRED to the other important. > > In a virtualization context I also think it makes > for more sense for each Virtual Machine to be able > to obtain the ARP/ND info for host X when it needs > it without having *each* of them having to do an > end-to-end query or forcing each of them to hear > every ARP response so that each virtual machine > can maintain its own ARP table in parallel. > The RBridge is simply in the ideal position to > perform a highly optimized ARP/ND proxy role. > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > 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 l33M6UhV008281 for <rbridge@postel.org>; Tue, 3 Apr 2007 15:06:30 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 03 Apr 2007 15:06:21 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C2CDB2AF; Tue, 3 Apr 2007 15:06: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 AAF142AE; Tue, 3 Apr 2007 15:06: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 FDO22472; Tue, 3 Apr 2007 15:06:20 -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 D937369CA4; Tue, 3 Apr 2007 15:06:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Apr 2007 15:06:19 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BABC2@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467875@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioAADjVAQA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A0C10573A412207245-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 l33M6UhV008281 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 22:06:52 -0000 Status: RO Content-Length: 2213 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > Sent: Tuesday, April 03, 2007 8:16 AM > To: Eric Gray (LO/EUS); Radia Perlman; rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > Eric, > > I will go one step further and say that the basic TRILL > protocol should not specify an ARP/ND proxy function. > > As the discussion as pointed out, ARP/ND proxy is more a > product feature that depends on how the box are packaged. > IMHO RBridges will be packaged with additional router, NAT, > firewall functionalities. If and where proxy ARP will be > implemented will vary. > > After the last call on the base protocol, we can always > resume the work and deal with Proxy ARP/ND in a separate document. > > -- Silvano > At the minimum we need to ensure that all RBridges have the information that would enable them to efficiently and reliably act as an ARP/ND proxy. By the very nature of a proxy it is hard to state that it MUST do anything. Any proxy will have a limit on the information that it can cache, and can therefore fail to act as a proxy on some occassions. So anything that is a proxy function strikes me as inherently a SHOULD at most. That said, all of the arguments on why an RBridge is valuable also imply that proxying ARP/ND is a vital part of the RBridge's functionality. In particular, I believe that the trends towards server virtualization and physically more compact servers both will lead to an increase in the logical size of IP subnets. That makes the role of ARP/ND proxying more important, and makes it all the more desirable not to routinely run these queries from one end of the CRED to the other important. In a virtualization context I also think it makes for more sense for each Virtual Machine to be able to obtain the ARP/ND info for host X when it needs it without having *each* of them having to do an end-to-end query or forcing each of them to hear every ARP response so that each virtual machine can maintain its own ARP table in parallel. The RBridge is simply in the ideal position to perform a highly optimized ARP/ND proxy role. 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 l33LHJKW026205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 14:17:19 -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 l33LHIMN009042; Tue, 3 Apr 2007 16:17:18 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 16:17:18 -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, 3 Apr 2007 16:17:11 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB5D0@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4612A97A.7010509@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Back to "what is the problem" for SVL/private VLAN/proxyARP stuff Thread-Index: Acd2JxxArlBGMpjGR12NqV+bHl1udQADYa5A References: <4612A97A.7010509@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 03 Apr 2007 21:17:18.0516 (UTC) FILETIME=[75CE7F40:01C77635] 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 l33LHJKW026205 Cc: rbridge@postel.org Subject: Re: [rbridge] Back to "what is the problem" for SVL/private VLAN/proxyARP stuff 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, 03 Apr 2007 21:17:54 -0000 Status: RO Content-Length: 3342 Radia, I don't understand why you're asking this question. It is - believe it or not - sufficient to say "we're doing it that way because we like to, and we can." Trying to analyze the specific problem that might, or might not, be solved by using a specific technology is a mistake when the technology is being used and nobody is especially interested in hearing how their problems might be solved a different way. I understand your frustration, but I don't see how getting a grip on the problem is going to make any difference in what we end up doing - so why waste our time on that particular subject? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, April 03, 2007 3:23 PM > To: rbridge@postel.org > Subject: [rbridge] Back to "what is the problem" for > SVL/private VLAN/proxyARP stuff > > I think the reason we are all so confused is that we > (especially me) do > not understand what problem > we are solving. I wrote up in a previous note what I interpreted the > problem to be. Let's be > really tangible about it. I'll start. Correct me if you disagree. But > don't use reference to other solutions > or specs. It *can't* be that hard to actually describe it, > rather than > reference a spec, and without > being explicit people won't realize when they are thinking of > different > things. > > So...is this the problem? > > a) IP address block that has to be subdivided willy-nilly > (not in clean > sub-prefixes) among 4 customers > > b) desire separation of the customers. I'd like this > expanded. Why? Is > it because of not wanting > to bother customer B with A's traffic, or that A doesn't want > B to see > A's traffic? Or both maybe. > Do we know what these applications are? > > c) we want these communities to share some service node, say a DHCP > server or an IP router > > d) we don't want modify the IP router to do anything special > (I suspect > this is not really true, and that > the solutions people have in mind do require the IP router to > know about > this), or not much special > > e) (I'm throwing this one in). We don't want to have to configure > anything (RBridges or IP routers) to know > static mapping of IP addresses or MAC addresses to VLANs. The only > configuration will be that an > RBridge (or bridge) will be configured to say "this set of > ports of mine > are VLAN A, this set are VLAN B, ..." > and it's by the tagging of packets transmitted from the port > that other > nodes learn which MAC addresses > (or which IP addresses) are in which VLAN > > f) we want an IP endnode E_a in VLAN A to talk to an IP node > E_b in VLAN > B by being forwarded through the IP router. E_a and E_b are > vanilla IP > nodes and think they should be talking directly since they > are in the same > IP address block. > > g) maybe there are applications other than IP that want to have some > sort of service node see all > the traffic from all the VLANs, and be able to talk to all the VLANs, > but not have the VLANs talk to each > other. Is this true? > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33L3cH9021987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 14:03:38 -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 l33LTIv7020591; Tue, 3 Apr 2007 16:29:18 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 16:03:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Apr 2007 16:03:29 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB5B4@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BAAA3@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd2HXzY0oMK1aSUSqGrIspzSdIOjwAAB5UwAAVEFWA= References: <46129C15.50006@sun.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BAAA3@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 03 Apr 2007 21:03:36.0771 (UTC) FILETIME=[8C022930:01C77633] 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 l33L3cH9021987 Cc: rbridge@postel.org Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 21:03:52 -0000 Status: RO Content-Length: 2149 Caitlin, I think this is incorrect. There is little reason to have VLAN separation if you are planning to share all information irrespective of VLAN membership. Plus, the example you seem to be referring to does not necessarily require the level of information sharing you assume. There is nothing intrinsic in the fact that a IP address is discovered on VLAN B when it was earlier discovered on VLAN A that would indicate that the host has necessarily moved from one to the other. This could only happen in the shared IP address space case, but it could happen either because a host moves, or because it has presence in both VLANs (as might be the case if it was a server, for example). Hence I fail to see how it is helpful to share that information. Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler > Sent: Tuesday, April 03, 2007 2:30 PM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > > > -----Original Message----- > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > Sent: Tuesday, April 03, 2007 11:25 AM > > To: Caitlin Bestler > > Cc: Joel M. Halpern; rbridge@postel.org > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > > It that's all that's needed (letting RBridges in Z know about > > membership of A, B, C, and D), then that would work by having > > RBridge RB1, which is only attached to, say, Z, advertise in > > its core IS-IS instance that it actually is also attached to > > A, B, C, and D. That way > > RB1 will receive the endnode > > advertisements of A, B, C, and D as well as Z. > > > > Radia > > > > If you are in {Z,A} you need to know about endnodes in B > because of the shared address space problem, but you do > not want B's traffic. It is *only* the endnode advertisements > that you want added. > > > > _______________________________________________ > 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 l33JMKEr021553 for <rbridge@postel.org>; Tue, 3 Apr 2007 12:22:20 -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 <0JFX00208SH7FL00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 03 Apr 2007 12:22:19 -0700 (PDT) Received: from sun.com ([129.150.64.23]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFX00BJMSH5S020@mail.sunlabs.com> for rbridge@postel.org; Tue, 03 Apr 2007 12:22:19 -0700 (PDT) Date: Tue, 03 Apr 2007 12:22:34 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <4612A97A.7010509@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] Back to "what is the problem" for SVL/private VLAN/proxy ARP stuff 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, 03 Apr 2007 19:22:39 -0000 Status: RO Content-Length: 2100 I think the reason we are all so confused is that we (especially me) do not understand what problem we are solving. I wrote up in a previous note what I interpreted the problem to be. Let's be really tangible about it. I'll start. Correct me if you disagree. But don't use reference to other solutions or specs. It *can't* be that hard to actually describe it, rather than reference a spec, and without being explicit people won't realize when they are thinking of different things. So...is this the problem? a) IP address block that has to be subdivided willy-nilly (not in clean sub-prefixes) among 4 customers b) desire separation of the customers. I'd like this expanded. Why? Is it because of not wanting to bother customer B with A's traffic, or that A doesn't want B to see A's traffic? Or both maybe. Do we know what these applications are? c) we want these communities to share some service node, say a DHCP server or an IP router d) we don't want modify the IP router to do anything special (I suspect this is not really true, and that the solutions people have in mind do require the IP router to know about this), or not much special e) (I'm throwing this one in). We don't want to have to configure anything (RBridges or IP routers) to know static mapping of IP addresses or MAC addresses to VLANs. The only configuration will be that an RBridge (or bridge) will be configured to say "this set of ports of mine are VLAN A, this set are VLAN B, ..." and it's by the tagging of packets transmitted from the port that other nodes learn which MAC addresses (or which IP addresses) are in which VLAN f) we want an IP endnode E_a in VLAN A to talk to an IP node E_b in VLAN B by being forwarded through the IP router. E_a and E_b are vanilla IP nodes and think they should be talking directly since they are in the same IP address block. g) maybe there are applications other than IP that want to have some sort of service node see all the traffic from all the VLANs, and be able to talk to all the VLANs, but not have the VLANs talk to each other. Is this true? 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 l33Ij90M010754 for <rbridge@postel.org>; Tue, 3 Apr 2007 11:45:10 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JFX00NAXQR90U10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 03 Apr 2007 11:45:09 -0700 (PDT) Received: from sun.com ([129.150.64.23]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFX00BDEQR7S020@mail.sunlabs.com> for rbridge@postel.org; Tue, 03 Apr 2007 11:45:09 -0700 (PDT) Date: Tue, 03 Apr 2007 11:45:23 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D034BAAA3@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <4612A0C3.7090406@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: <1EF1E44200D82B47BD5BA61171E8CE9D034BAAA3@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] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 18:45:37 -0000 Status: RO Content-Length: 922 Re: Caitlin's comment below Really? The problem, as explained to me by some subset of the people, was that the IP router R would be on the primary VLAN (in this case, Z), and so R needs to receive at least some broadcasts from the secondaries -- the ARP/ND queries, for example. It seemed to me that VLAN Z traffic (unicast or multicast) has to be legally accepted by all links in Z, A, B, C, and D. And that VLAN A traffic (unicast or multicast) has to be legally accepted by all links in A and Z. There might be some applications that only want to stay within VLAN A. But how are RBridges to know which are supposed to go to Z and which aren't supposed to go to Z? Radia Caitlin Bestler wrote: > >If you are in {Z,A} you need to know about endnodes in B >because of the shared address space problem, but you do >not want B's traffic. It is *only* the endnode advertisements >that you want added. > > > > Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33Ii0n4010125 for <rbridge@postel.org>; Tue, 3 Apr 2007 11:44:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id F0C087DFF for <rbridge@postel.org>; Tue, 3 Apr 2007 11:43:59 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (pool-71-161-34-119.clppva.east.verizon.net [71.161.34.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id B76767DA5 for <rbridge@postel.org>; Tue, 3 Apr 2007 11:43:57 -0700 (PDT) Message-Id: <7.0.1.0.0.20070403143617.036891e8@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 03 Apr 2007 14:43:53 -0400 To: rbridge@postel.org From: "Joel M. Halpern" <jmh@joelhalpern.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BAA0F@NT-IRVA-0750.brcm .ad.broadcom.com> References: <7.0.1.0.0.20070403130059.0369a358@joelhalpern.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BAA0F@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED X-Spam-Level: X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jmh@joelhalpern.com Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 18:44:08 -0000 Status: RO Content-Length: 3294 I don't follow the connection. At 01:28 PM 4/3/2007, Caitlin Bestler wrote: > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Joel M. Halpern > > Sent: Tuesday, April 03, 2007 10:04 AM > > To: rbridge@postel.org > > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > > > I think we can take the description a step further. > > > > As long as we do not insist that all special cases must be > > solved optimally, it seems that this particular case, as > > described, can be solved with no modification to the protocol > > just by special behavior of the RBridge at the router. Given > > that it is a special case, and that it can be solved > > externally to the protocol, it would seem to make sense for > > the protocol not to solve this problem. > > > > We do not normally specify what additional features, outside > > of the spec, an implementation may or may not perform. > > Hence, the most we might consider doing for this is an > > infromational appendix that describes how this particular > > case is solved. (And remember, we can not describe how to > > solve all the possible special cases.) > > > >What started this whole line of discussion was that the protocol >specification at the time explicitly stated that end node discovery >was only shared with the VLAN. That leads to problems when RBridges >that are not part of VLAN A need to know of a discovery in VLAN A >because it implies removal of conflicting key addresses (IP or MAC) >in their own data structures. Discover that MAC address X is on VLAN B should not always imply removal of MAC address X from VLAN A. A device may use the same address on multiple VLANs. I understand that there are cases where such sharing of information may be necessary. But those cases have nothing to do with the situation of a router unknowingly serving several VLANs all within the same subnet. In fact, as far as I can tell, that scenario is best dealt with if the routers MAC address is permitted to appear in several different VLANs simultaneously. >So, the specification could merely state that RBridges MAY >communicate endnode discovery with other RBridges for whatever >reasons. It could even cite shared IP subnets as an example >of a special feature that specific RBridges MAY chose to >support. The problem of proper removal of stale information (either because of exclusive VLAN usage where the end station is not permitted to be on several VLANs, or because of physical movement, is generally best addressed by explicit and direct support, if it is desired. Trying to have unspecified behavior produce consistent result just doesn't work. However, it also does not seem to be related to the scenario as described in Radia's email and the IEEE spec. There is no change in what VLAN can be used to reach any given MAC address in those situations. >That might make sense if we adopt the "it's not a general problem >that should be handled by the default zereo configuration solution" >approach. the grouping of VLANs (whether for an end-RBridge support or for Radia's proposal 1 advertisement, or any other approach) is clearly not going to supported by the zero-configuration case. It can't be. Yours, Joel 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 l33ITruP005941 for <rbridge@postel.org>; Tue, 3 Apr 2007 11:29:53 -0700 (PDT) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 03 Apr 2007 11:29:42 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8EDBB2AF; Tue, 3 Apr 2007 11:29:42 -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 7A7672AE; Tue, 3 Apr 2007 11:29:42 -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 FDN75895; Tue, 3 Apr 2007 11:29: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 F189469CA5; Tue, 3 Apr 2007 11:29:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Apr 2007 11:29:36 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BAAA3@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <46129C15.50006@sun.com> Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd2HXzY0oMK1aSUSqGrIspzSdIOjwAAB5Uw From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A0C429C38G12234552-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 l33ITruP005941 Cc: rbridge@postel.org Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 18:30:07 -0000 Status: RO Content-Length: 838 > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Tuesday, April 03, 2007 11:25 AM > To: Caitlin Bestler > Cc: Joel M. Halpern; rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > It that's all that's needed (letting RBridges in Z know about > membership of A, B, C, and D), then that would work by having > RBridge RB1, which is only attached to, say, Z, advertise in > its core IS-IS instance that it actually is also attached to > A, B, C, and D. That way > RB1 will receive the endnode > advertisements of A, B, C, and D as well as Z. > > Radia > If you are in {Z,A} you need to know about endnodes in B because of the shared address space problem, but you do not want B's traffic. It is *only* the endnode advertisements that you want added. 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 l33IPSHp005198 for <rbridge@postel.org>; Tue, 3 Apr 2007 11:25: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 <0JFX00N8NPU20U10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 03 Apr 2007 11:25:14 -0700 (PDT) Received: from sun.com ([129.150.64.23]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JFX00B8VPTYS020@mail.sunlabs.com> for rbridge@postel.org; Tue, 03 Apr 2007 11:25:14 -0700 (PDT) Date: Tue, 03 Apr 2007 11:25:25 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D034BAA0F@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <46129C15.50006@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: <1EF1E44200D82B47BD5BA61171E8CE9D034BAA0F@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] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 18:25:45 -0000 Status: RO Content-Length: 2423 It that's all that's needed (letting RBridges in Z know about membership of A, B, C, and D), then that would work by having RBridge RB1, which is only attached to, say, Z, advertise in its core IS-IS instance that it actually is also attached to A, B, C, and D. That way RB1 will receive the endnode advertisements of A, B, C, and D as well as Z. Radia Caitlin Bestler wrote: > > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >>[mailto:rbridge-bounces@postel.org] On Behalf Of Joel M. Halpern >>Sent: Tuesday, April 03, 2007 10:04 AM >>To: rbridge@postel.org >>Subject: Re: [rbridge] Two "shared VLAN" alternative proposals >> >>I think we can take the description a step further. >> >>As long as we do not insist that all special cases must be >>solved optimally, it seems that this particular case, as >>described, can be solved with no modification to the protocol >>just by special behavior of the RBridge at the router. Given >>that it is a special case, and that it can be solved >>externally to the protocol, it would seem to make sense for >>the protocol not to solve this problem. >> >>We do not normally specify what additional features, outside >>of the spec, an implementation may or may not perform. >>Hence, the most we might consider doing for this is an >>infromational appendix that describes how this particular >>case is solved. (And remember, we can not describe how to >>solve all the possible special cases.) >> >> >> > >What started this whole line of discussion was that the protocol >specification at the time explicitly stated that end node discovery >was only shared with the VLAN. That leads to problems when RBridges >that are not part of VLAN A need to know of a discovery in VLAN A >because it implies removal of conflicting key addresses (IP or MAC) >in their own data structures. > >So, the specification could merely state that RBridges MAY >communicate endnode discovery with other RBridges for whatever >reasons. It could even cite shared IP subnets as an example >of a special feature that specific RBridges MAY chose to >support. > >That might make sense if we adopt the "it's not a general problem >that should be handled by the default zereo configuration solution" >approach. > > >_______________________________________________ >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 l33HSQp3018088 for <rbridge@postel.org>; Tue, 3 Apr 2007 10:28:26 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 03 Apr 2007 10:28:12 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0112D2B0; Tue, 3 Apr 2007 10:28:11 -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 E13482AE; Tue, 3 Apr 2007 10:28: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 FDN60170; Tue, 3 Apr 2007 10:28:07 -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 4485F69CA5; Tue, 3 Apr 2007 10:28:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Apr 2007 10:28:06 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BAA0F@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <7.0.1.0.0.20070403130059.0369a358@joelhalpern.com> Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd2FAFOaMCo9VseTDyQ9hIIbzCC5wAAKbfg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, rbridge@postel.org X-WSS-ID: 6A0C512637012226966-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 l33HSQp3018088 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 17:28:34 -0000 Status: RO Content-Length: 1852 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, April 03, 2007 10:04 AM > To: rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > I think we can take the description a step further. > > As long as we do not insist that all special cases must be > solved optimally, it seems that this particular case, as > described, can be solved with no modification to the protocol > just by special behavior of the RBridge at the router. Given > that it is a special case, and that it can be solved > externally to the protocol, it would seem to make sense for > the protocol not to solve this problem. > > We do not normally specify what additional features, outside > of the spec, an implementation may or may not perform. > Hence, the most we might consider doing for this is an > infromational appendix that describes how this particular > case is solved. (And remember, we can not describe how to > solve all the possible special cases.) > What started this whole line of discussion was that the protocol specification at the time explicitly stated that end node discovery was only shared with the VLAN. That leads to problems when RBridges that are not part of VLAN A need to know of a discovery in VLAN A because it implies removal of conflicting key addresses (IP or MAC) in their own data structures. So, the specification could merely state that RBridges MAY communicate endnode discovery with other RBridges for whatever reasons. It could even cite shared IP subnets as an example of a special feature that specific RBridges MAY chose to support. That might make sense if we adopt the "it's not a general problem that should be handled by the default zereo configuration solution" approach. Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33H4PrY011011 for <rbridge@postel.org>; Tue, 3 Apr 2007 10:04:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 7E2367E17 for <rbridge@postel.org>; Tue, 3 Apr 2007 10:04:24 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (pool-71-161-34-119.clppva.east.verizon.net [71.161.34.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 626847E0C for <rbridge@postel.org>; Tue, 3 Apr 2007 10:04:20 -0700 (PDT) Message-Id: <7.0.1.0.0.20070403130059.0369a358@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 03 Apr 2007 13:04:15 -0400 To: rbridge@postel.org From: "Joel M. Halpern" <jmh@joelhalpern.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BA94C@NT-IRVA-0750.brcm .ad.broadcom.com> References: <941D5DCD8C42014FAF70FB7424686DCFACB056@eusrcmw721.eamcs.ericsson.se> <1EF1E44200D82B47BD5BA61171E8CE9D034BA94C@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED X-Spam-Level: X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jmh@joelhalpern.com Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 17:05:02 -0000 Status: RO Content-Length: 2152 I think we can take the description a step further. As long as we do not insist that all special cases must be solved optimally, it seems that this particular case, as described, can be solved with no modification to the protocol just by special behavior of the RBridge at the router. Given that it is a special case, and that it can be solved externally to the protocol, it would seem to make sense for the protocol not to solve this problem. We do not normally specify what additional features, outside of the spec, an implementation may or may not perform. Hence, the most we might consider doing for this is an infromational appendix that describes how this particular case is solved. (And remember, we can not describe how to solve all the possible special cases.) Yours, Joel M. Halpern At 11:46 AM 4/3/2007, Caitlin Bestler wrote: >But I do agree with Radia that there are two essential ways >to solve this: > > Extend the information collected during RBridge discovery > so that this problem will be taken care of automatically. > > or, require the RBridges that have this special problem > to solve it amongs themselves and leave everyone else > out of it. > >With the first method you retain zero configuration for >this feature by advertising VLAN groupings that require >what would otherwise be excessive distribution of endnode >discovery announcements. What Radia proposed works, but >alternate approaches are possible if there is something >inherently wrong about explicitly exporing FID info. > >With the second method you would be explicitly configuring >each RBridge within the group with the additional export >rules. Zero configuration is lost for those RBridges, but >kept simpler for most RBridges. > >But unless I'm missing something, the only special action >required is to ensure that when a group of VLANs share an >IP subnet that all Proxy ARP tables that reference the >shared IP subnet will be told of new discoveries. > > >_______________________________________________ >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 l33FkcGl018216 for <rbridge@postel.org>; Tue, 3 Apr 2007 08:46:38 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 03 Apr 2007 08:46:31 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 56CC62AE; Tue, 3 Apr 2007 08:46:31 -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 3779D2AF; Tue, 3 Apr 2007 08:46:31 -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 FDN21293; Tue, 3 Apr 2007 08:46:15 -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 99D4569CA8; Tue, 3 Apr 2007 08:46:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Apr 2007 08:46:13 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA94C@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACB056@eusrcmw721.eamcs.ericsson.se> Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAAWCX5A= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, rbridge@postel.org X-WSS-ID: 6A0CA95D37012182482-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 l33FkcGl018216 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 15:47:03 -0000 Status: RO Content-Length: 2195 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eric Gray (LO/EUS) > Sent: Tuesday, April 03, 2007 6:08 AM > To: Radia Perlman; rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > Radia, > > I imagine there are many more ways to answer this > question than the three alternatives you've offered as examples. > > I would answer this way: > > . neither approach is required to solve the problem, hence I > suggest we concentrate on not breaking solutions that work > now; > > And: > > . Here is a better option - we specify that an RBridge may be > configured to provide an inter-VLAN proxy ARP service in a > manner that is compatible with similar services offered at > present and the mechanisms and potential protocols needed > to accomplish this are out of scope for TRILL. > I think this may be a good approach. The only RBridge related problem with inter-VLAN quasi-routing that has been identified is an artifact of the ARP Proxy functionality. It makes sense to fix it there. But I do agree with Radia that there are two essential ways to solve this: Extend the information collected during RBridge discovery so that this problem will be taken care of automatically. or, require the RBridges that have this special problem to solve it amongs themselves and leave everyone else out of it. With the first method you retain zero configuration for this feature by advertising VLAN groupings that require what would otherwise be excessive distribution of endnode discovery announcements. What Radia proposed works, but alternate approaches are possible if there is something inherently wrong about explicitly exporing FID info. With the second method you would be explicitly configuring each RBridge within the group with the additional export rules. Zero configuration is lost for those RBridges, but kept simpler for most RBridges. But unless I'm missing something, the only special action required is to ensure that when a group of VLANs share an IP subnet that all Proxy ARP tables that reference the shared IP subnet will be told of new discoveries. 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 l33FQTBM012374 for <rbridge@postel.org>; Tue, 3 Apr 2007 08:26:29 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 03 Apr 2007 08:26:28 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l33FQSFU014340; Tue, 3 Apr 2007 08:26:28 -0700 Received: from [10.21.145.180] (sjc-vpn7-436.cisco.com [10.21.145.180]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l33FQRwn002395; Tue, 3 Apr 2007 15:26:28 GMT Message-ID: <46127268.2050208@cisco.com> Date: Tue, 03 Apr 2007 08:27:36 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0pre (X11/20070224) MIME-Version: 1.0 To: "J. R. Rivers" <jrrivers@nuovasystems.com> References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA201467706@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467706@nuova-ex1.hq.nuovaimpresa.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=17599; t=1175613988; x=1176477988; c=relaxed/simple; s=sjdkim8002; 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]=20Shared=20VLAN=20learning=3A=20What=20is=2 0it=20and=20why=20should=09wecare? |Sender:=20; bh=ZoMhiquf+xh38InZD022GEBjkpOzlKEvkKR2awgd1n4=; b=srU5oWutYY385m83nZWDtKm1U//zZLBj/+Rn3+YhifxzaR6p+xPW6hQpx1J/xo+S2KwO9aFf 4RRCZx26nG4nzg8+bsNgAFWibAIj/ps9FyrF4Emp9XUMqAzTfL7sp+7g; Authentication-Results: sj-dkim-8; header.From=ddutt@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 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] Shared VLAN learning: What is it and why should wecare? 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, 03 Apr 2007 15:27:04 -0000 Status: RO Content-Length: 17060 I can't agree more. The entire ARP/ND optimization defocusses from the main strengths of TRILL: equal cost multipathing and shortest path forwarding at L2. I had suggested that we move the ARP/ND optimization section out of the base protocol spec into a separate document that can be addressed separately. I'd like to reiterate that suggestion. BTW, Private VLANs was *only an* example of why shared VLAN learning is needed. During the meeting, we (Silvano and I) raised a list of open items and SVL was one of them. People questioned the need for this functionality and Ali Sajassi and I stated one example of its use. Focussing on how it works and attempting to solve what Private VLAN does outside of supporting SVL is an overkill, at least for the initial versions. Dinesh J. R. Rivers wrote: > > These are issues that are commonly dealt with today when routers (either > stand alone or "merged L3 switches") face this situation today. I > suggest focusing TRILL on retaining compatibility with today's > expectations rather than altering them in any way. > > JR > > > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Eric Gray (LO/EUS) >> Sent: Monday, April 02, 2007 1:50 PM >> To: Radia Perlman >> Cc: rbridge@postel.org >> Subject: Re: [rbridge] Shared VLAN learning: What is it and >> why should wecare? >> >> Radia, >> >> There is an interesting problem that might arise out of >> a router receiving VLAN tagged frames without being aware that >> they are tagged. >> >> A router is a MAC termination point - i.e. - it is an >> end-station at the MAC layer. But it is also a forwarding >> device. Hence the slack that might apply to a host receiving >> a MAC frame with "stuff" in the header it doesn't understand, >> shouldn't be allowed for a router. >> >> Also, many routers do understand that it is possible to >> have the same IP subnet connected to multiple logical interfaces. >> That was where the original "Bridging Router" (or BRouter) came >> from. >> >> -- >> Eric Gray >> Principal Engineer >> Ericsson >> >> >>> -----Original Message----- >>> From: Radia Perlman [mailto:Radia.Perlman@sun.com] >>> Sent: Monday, April 02, 2007 4:10 PM >>> To: Eric Gray (LO/EUS) >>> Cc: rbridge@postel.org >>> Subject: Re: [rbridge] Shared VLAN learning: What is it and >>> why should we care? >>> Importance: High >>> >>> My understanding is that shared VLANs assume >>> IP routers are not aware of VLANs. >>> >>> My understanding is that the way it would work if the IP >>> router R *was* >>> aware of >>> VLANs, is that R would treat the link as 4 separate links (by using >>> VLANs), and then the IP addresses >>> on the 4 different links (VLANs A, B, C, and D) would have to have >>> different IP prefixes. >>> >>> So therefore, I am assuming that the IP router is not >>> supposed to know >>> that the link is subdivided into VLANs. >>> >>> So my understanding of the problem in this case is: >>> >>> a) single IP address block shared by different communities >>> b) desire to isolate these communities from layer 2 >>> >> broadcast traffic >> >>> from each other >>> c) desire to share some services (like DHCP and IP >>> >> routers), without >> >>> those services being aware >>> that the communities are separate >>> >>> As for my question about proxy ARP, to further add >>> to the confusion -- some people are assuming the >>> bridge/RBridge will be >>> doing >>> the proxy ARP, and some others are assuming the router is. >>> >>> And actually, after talking offline with Joel Halpern, I'll >>> send another >>> note with two different proposals >>> (one just a cleanup of what I originally wrote, and the other a >>> different approach) for solving >>> that vaguely stated problem. >>> >>> Radia >>> >>> >>> >>> >>> >>> Eric Gray (LO/EUS) wrote: >>> >>> >>>> Radia, >>>> >>>> Let me try to re-state your explanation to see if I understand >>>> it... >>>> >>>> You believe that the problem that shared VLAN learning is used >>>> to solve is conservation of IP addresses used in a single >>>> >> IP subnet, >> >>>> and that it is necessary to use shared VLAN learning to >>>> >> keep routers >> >>>> (in the subnet) from having to re-learn MAC+IP >>>> >> associations across a >> >>>> set of VLANs in that same IP subnet, is that correct? >>>> >>>> Thanks! >>>> >>>> -- >>>> Eric Gray >>>> Principal Engineer >>>> Ericsson >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces@postel.org >>>>> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >>>>> Sent: Thursday, March 29, 2007 2:56 AM >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>> >> _______________________________________________ >> 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 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 l33FGE0q009234 for <rbridge@postel.org>; Tue, 3 Apr 2007 08:16:14 -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, 3 Apr 2007 08:16:03 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467875@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACB056@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals thread-index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQAARkioA= References: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com><1EF1E44200D82B47BD5BA61171E8CE9D034BA738@NT-IRVA-0750.brcm.ad.broadcom.com><941D5DCD8C42014FAF70FB7424686DCFACAF28@eusrcmw721.eamcs.ericsson.se><46118B04.5000501@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACB056@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.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 l33FGE0q009234 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 15:16:27 -0000 Status: RO Content-Length: 7270 Eric, I will go one step further and say that the basic TRILL protocol should not specify an ARP/ND proxy function. As the discussion as pointed out, ARP/ND proxy is more a product feature that depends on how the box are packaged. IMHO RBridges will be packaged with additional router, NAT, firewall functionalities. If and where proxy ARP will be implemented will vary. After the last call on the base protocol, we can always resume the work and deal with Proxy ARP/ND in a separate document. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eric Gray (LO/EUS) > Sent: Tuesday, April 03, 2007 6:08 AM > To: Radia Perlman; rbridge@postel.org > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals > > Radia, > > I imagine there are many more ways to answer this question > than the three alternatives you've offered as examples. > > I would answer this way: > > . neither approach is required to solve the problem, hence I > suggest we concentrate on not breaking solutions that work > now; > > And: > > . Here is a better option - we specify that an RBridge may be > configured to provide an inter-VLAN proxy ARP service in a > manner that is compatible with similar services offered at > present and the mechanisms and potential protocols needed > to accomplish this are out of scope for TRILL. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Monday, April 02, 2007 7:00 PM > > To: rbridge@postel.org > > Subject: [rbridge] Two "shared VLAN" alternative proposals > > > > Based on the thread, and some off-list communication with > > Joel Halpern > > and others, I now > > would like to propose two concrete solutions. > > > > I'd like people to make comments like > > . "either of them is fine, but I prefer this one because..." > > . "neither of them solve the problem. The problem is ..." > > . "here is a better option .. xxxxxxxxx" > > > > > > Option 1: Making groupings known to all the RBridges > > (slightly revised > > from my original proposal) > > -------------------------------------------------------------- > > ------------------------------------ > > > > a) Make a group of VLANs {Z, A, B, C, D}, where VLAN Z is the > > "primary" and > > {A, B, C, D} are "secondaries". All RBridges learn about > > this grouping > > because > > at least one RBridge RB1 has been configured to know these 5 VLANs > > belong in a group, > > and RB1 announces this grouping in its core IS-IS instance. > > > > A frame tagged with VLAN Z (say an ARP request > > from the IP router) goes to all the links in all the VLANs in > > the group > > (i.e., Z, A, B, C, and D). While > > in the core, the inner VLAN tag is Z. When an RBridge > > decapsulates onto > > a VLAN A link, it changes the > > VLAN tag to A in order to forward it (or removes the VLAN tag). > > > > RBridges in the core do optimal filtering of VLAN-tagged packets, > > so that something tagged VLAN D goes to D and Z, something > > marked Z goes > > to Z, A, B, C, and D, and > > something marked F (not in a group) goes just to F. And the > > distribution > > tree gets filtered as early > > as possible, by some core RBridge that notices no downstream > > link leads > > to any of the VLANs in the > > set it is supposed to be delivering to. > > > > There will still be separate per-VLAN instances of Z, A, B, > > C, and D. > > These are not combined. > > RBridges that only claim to be attached to VLAN Z, will also > > participate > > in the per-VLAN IS-IS > > instances of A, B, C, and D, in that they will recieve and store the > > link state announcements about endnodes > > in those VLANs. > > > > If two different RBridges announce different groupings, say RB1 > > announces {Z, A, B, C, D} and > > RB2 announces {Z, A, E}, then we log an error, but core RBridges > > treat the group as the set union, i.e. {Z, A, B, C, D, E}, for the > > purpose of filtering multicasts tagged with > > any of those VLAN tags. > > > > Option 2: Groupings only known to RBridges at the edge > > involved in these > > groupings > > -------------------------------------------------------------- > > ----------------------- > > > > b) Only RBridges associated with these groupings know > > anything about the > > grouping. So going with > > our original example, an IP router is shared by VLANs A, B, C, and D, > > and is assigned to VLAN Z. > > The IP router is not aware of any of this, and assumes > > everything is one > > IP subnet. RBridges > > attached to IP nodes in any of the VLANs {Z, A, B, C, D} > > *are* aware of > > this grouping. > > > > Suppose the IP router is > > attached to RBridge RB1. The IP router does an ARP request. RB1 knows > > that something from > > the IP router is supposed to go to > > VLANs Z, A, B, C, and D, so RB1 duplicates the packet (in > > this case, the > > ARP request), > > creating 5 packets, and transmits one > > into the cloud tagged as VLAN Z, one as VLAN A, one as VLAN B, one as > > VLAN C, one as VLAN D. > > In the IP router issues a unicast packet to MAC address M, > > RB1 looks in > > its endnode tables > > for VLAN Z, VLAN A, VLAN B, VLAN C, and VLAN D. If RB1 finds > > M, say in > > VLAN B, > > RB1 tags the packet as "VLAN B", and sends it to the egress > > RBridge that > > announced attachment to M > > in VLAN B. I assume that RB1 stops when it finds M, and if M is in > > multiple of these tables, too bad. > > RB1 sends it to the first one it finds. > > > > For an RBridge RB2 attached to a "secondary VLAN", say C, the > > same thing > > happens. > > Multicasts from C get duplicated so RB2 sends two copies, one marked > > "VLAN C", and one marked "VLAN Z". > > For unicast, RB2 sees if it can find the MAC address in its C > > table or Z > > table, and if it does, unicasts it > > to the egress RBridge (marking the VLAN tag according to the table in > > which it found the destination, > > or leaving it as C; I think either one will work). > > > > But if RB2 does *not* find the destination in any of the > > endnode tables, > > RB2 creates two copies of the packet, one > > marked VLAN Z, one marked VLAN B, and multicasts each one. > > > > ******************************************************** > > Pros and cons of these two proposals > > > > Proposal a) is more optimal since packets to the group do not > > need to be > > duplicated, > > and furthermore get filtered in the core. However, it > > requires adding an > > announcement > > into the core IS-IS instance of what the VLAN groupings are, and some > > thought as > > to what to do if different RBridges announce different groupings. > > > > Proposal b) adds less complexity to the basic RBridge spec. Since no > > sharing of > > grouping information is done, misconfiguration will not be detectable. > > > > _______________________________________________ > > 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 l33F5kIc005960 for <rbridge@postel.org>; Tue, 3 Apr 2007 08:05:47 -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, 3 Apr 2007 08:05:36 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20146786A@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAFB7@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why shouldwecare? thread-index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAAR6TwAAGkdP8AAHy0ew References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se><34BDD2A93E5FD84594BB230DD6C18EA201467706@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFACAFB7@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "J. R. Rivers" <jrrivers@nuovasystems.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 l33F5kIc005960 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why shouldwecare? 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, 03 Apr 2007 15:05:58 -0000 Status: RO Content-Length: 17454 I completely agree -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eric Gray (LO/EUS) > Sent: Tuesday, April 03, 2007 4:23 AM > To: J. R. Rivers; Radia Perlman; rbridge@postel.org > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why > shouldwecare? > > JR, > > I agree. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > > Sent: Monday, April 02, 2007 6:52 PM > > To: Eric Gray (LO/EUS); Radia Perlman; rbridge@postel.org > > Cc: rbridge@postel.org > > Subject: RE: [rbridge] Shared VLAN learning: What is it and > > why should wecare? > > Importance: High > > > > > > These are issues that are commonly dealt with today when > > routers (either > > stand alone or "merged L3 switches") face this situation today. I > > suggest focusing TRILL on retaining compatibility with today's > > expectations rather than altering them in any way. > > > > JR > > > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eric Gray (LO/EUS) > > > Sent: Monday, April 02, 2007 1:50 PM > > > To: Radia Perlman > > > Cc: rbridge@postel.org > > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > > why should wecare? > > > > > > Radia, > > > > > > There is an interesting problem that might arise out of > > > a router receiving VLAN tagged frames without being aware that > > > they are tagged. > > > > > > A router is a MAC termination point - i.e. - it is an > > > end-station at the MAC layer. But it is also a forwarding > > > device. Hence the slack that might apply to a host receiving > > > a MAC frame with "stuff" in the header it doesn't understand, > > > shouldn't be allowed for a router. > > > > > > Also, many routers do understand that it is possible to > > > have the same IP subnet connected to multiple logical interfaces. > > > That was where the original "Bridging Router" (or BRouter) came > > > from. > > > > > > -- > > > Eric Gray > > > Principal Engineer > > > Ericsson > > > > > > > -----Original Message----- > > > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > > > Sent: Monday, April 02, 2007 4:10 PM > > > > To: Eric Gray (LO/EUS) > > > > Cc: rbridge@postel.org > > > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > > > why should we care? > > > > Importance: High > > > > > > > > My understanding is that shared VLANs assume > > > > IP routers are not aware of VLANs. > > > > > > > > My understanding is that the way it would work if the IP > > > > router R *was* > > > > aware of > > > > VLANs, is that R would treat the link as 4 separate links > > (by using > > > > VLANs), and then the IP addresses > > > > on the 4 different links (VLANs A, B, C, and D) would > > have to have > > > > different IP prefixes. > > > > > > > > So therefore, I am assuming that the IP router is not > > > > supposed to know > > > > that the link is subdivided into VLANs. > > > > > > > > So my understanding of the problem in this case is: > > > > > > > > a) single IP address block shared by different communities > > > > b) desire to isolate these communities from layer 2 > > > broadcast traffic > > > > from each other > > > > c) desire to share some services (like DHCP and IP > > > routers), without > > > > those services being aware > > > > that the communities are separate > > > > > > > > As for my question about proxy ARP, to further add > > > > to the confusion -- some people are assuming the > > > > bridge/RBridge will be > > > > doing > > > > the proxy ARP, and some others are assuming the router is. > > > > > > > > And actually, after talking offline with Joel Halpern, I'll > > > > send another > > > > note with two different proposals > > > > (one just a cleanup of what I originally wrote, and the other a > > > > different approach) for solving > > > > that vaguely stated problem. > > > > > > > > Radia > > > > > > > > > > > > > > > > > > > > > > > > Eric Gray (LO/EUS) wrote: > > > > > > > > >Radia, > > > > > > > > > > Let me try to re-state your explanation to see if I understand > > > > >it... > > > > > > > > > > You believe that the problem that shared VLAN learning is used > > > > >to solve is conservation of IP addresses used in a single > > > IP subnet, > > > > >and that it is necessary to use shared VLAN learning to > > > keep routers > > > > >(in the subnet) from having to re-learn MAC+IP > > > associations across a > > > > >set of VLANs in that same IP subnet, is that correct? > > > > > > > > > >Thanks! > > > > > > > > > >-- > > > > >Eric Gray > > > > >Principal Engineer > > > > >Ericsson > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > >>From: rbridge-bounces@postel.org > > > > >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > > >>Sent: Thursday, March 29, 2007 2:56 AM > > > > >>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 > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > _______________________________________________ > > > 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 smtp.doit.wisc.edu (up.doit.wisc.edu [144.92.9.73]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33DoMDq011405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 06:50:23 -0700 (PDT) Received: from feta.doit.wisc.edu (feta.doit.wisc.edu [144.92.67.115]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id l33DoGqH010960; Tue, 3 Apr 2007 08:50:16 -0500 Received: by feta.doit.wisc.edu (Postfix, from userid 1318) id 85256465CCA; Tue, 3 Apr 2007 08:50:16 -0500 (CDT) Date: Tue, 3 Apr 2007 08:50:16 -0500 From: "Dale W. Carder" <dwcarder@doit.wisc.edu> To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com> Message-ID: <20070403135016.GA28297@doit.wisc.edu> References: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> <460F590E.5010207@sun.com> <46124F73.80808@cisco.com> <941D5DCD8C42014FAF70FB7424686DCFACB09F@eusrcmw721.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACB09F@eusrcmw721.eamcs.ericsson.se> User-Agent: Mutt/1.5.8i 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 Reply-To: dwcarder@doit.wisc.edu 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, 03 Apr 2007 13:50:53 -0000 Status: RO Content-Length: 568 Thus spake Eric Gray (LO/EUS) (eric.gray@ericsson.com) on Tue, Apr 03, 2007 at 08:25:38AM -0500: > cover several of the issues. Silvano said: > > "Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs. In > figure B-4 assume a router instead of the Server." > > I don't think I am at liberty to disclose publicly how you > can get direct access to that publication, but you can. See > your local IEEE people to find out how... They are now free to download after a 6 month period after initial release: http://standards.ieee.org/getieee802/802.1.html Dale 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 l33DPjfa004906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 06:25:46 -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 l33DpP7o009820; Tue, 3 Apr 2007 08:51:25 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:25:44 -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, 3 Apr 2007 08:25:38 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB09F@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <46124F73.80808@cisco.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: Acd18XNuRICkEA/YSM2+cEqzR4U4RwAAXwEg References: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com><460F590E.5010207@sun.com> <46124F73.80808@cisco.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Russ White" <riw@cisco.com> X-OriginalArrivalTime: 03 Apr 2007 13:25:44.0860 (UTC) FILETIME=[957935C0:01C775F3] 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 l33DPjfa004906 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: Tue, 03 Apr 2007 13:25:58 -0000 Status: RO Content-Length: 1434 Russ, Silvano provided a reference for a diagram that does cover several of the issues. Silvano said: "Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs. In figure B-4 assume a router instead of the Server." I don't think I am at liberty to disclose publicly how you can get direct access to that publication, but you can. See your local IEEE people to find out how... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White > Sent: Tuesday, April 03, 2007 8:58 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 > > > > Argh! I'm really confused. > > Could we have a network diagram posted someplace on a web site? I'm > finding this hard to follow from text descriptions.... ?? > > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGEk9zER27sUhU9OQRAs00AJwLav8FeqJ59QvW9/jGuyaCw9Pn8ACdFqFn > CLWoXE/tUZ9ouCsFEhdTOqU= > =e8Vh > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33DI64x002716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 06:18:06 -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 l33Dhj2V008804; Tue, 3 Apr 2007 08:43:45 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:18:04 -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, 3 Apr 2007 08:17:59 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB07C@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <46124F73.80808@cisco.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: Acd18XNuRICkEA/YSM2+cEqzR4U4RwAAFOhw References: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com><460F590E.5010207@sun.com> <46124F73.80808@cisco.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Russ White" <riw@cisco.com> X-OriginalArrivalTime: 03 Apr 2007 13:18:04.0861 (UTC) FILETIME=[834AEED0:01C775F2] 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 l33DI64x002716 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: Tue, 03 Apr 2007 13:18:21 -0000 Status: RO Content-Length: 1717 Russ, I'm with you on that, but I doubt that a single diagram would suffice to describe the many different things that people are talking about. Trying to come up with a single diagram to include all of the issues would result in a diagram too complex to be useful in most cases. You may have seen the simplistic one I provided to show the potential problems that might arise from using inter-VLAN Proxy ARP with RBridges - if one does not take into account a real-world possibility that this may be done already using the techniques that are deployed today. But does that one serve to illustrate the other problems discussed in this thread? I think not... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White > Sent: Tuesday, April 03, 2007 8:58 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 > > > > Argh! I'm really confused. > > Could we have a network diagram posted someplace on a web site? I'm > finding this hard to follow from text descriptions.... ?? > > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGEk9zER27sUhU9OQRAs00AJwLav8FeqJ59QvW9/jGuyaCw9Pn8ACdFqFn > CLWoXE/tUZ9ouCsFEhdTOqU= > =e8Vh > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33D7o6v029293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 06:07:51 -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 l33DXSPt007485; Tue, 3 Apr 2007 08:33:29 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:07:48 -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, 3 Apr 2007 08:07:42 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACB056@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <46118B04.5000501@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Two "shared VLAN" alternative proposals Thread-Index: Acd1e0RyGeoTSQiJQ0ecfsfFQILnjQAdMHPQ References: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com><1EF1E44200D82B47BD5BA61171E8CE9D034BA738@NT-IRVA-0750.brcm.ad.broadcom.com><941D5DCD8C42014FAF70FB7424686DCFACAF28@eusrcmw721.eamcs.ericsson.se> <46118B04.5000501@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 03 Apr 2007 13:07:48.0148 (UTC) FILETIME=[13B3FF40:01C775F1] 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 l33D7o6v029293 Subject: Re: [rbridge] Two "shared VLAN" alternative proposals 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, 03 Apr 2007 13:08:27 -0000 Status: RO Content-Length: 6056 Radia, I imagine there are many more ways to answer this question than the three alternatives you've offered as examples. I would answer this way: . neither approach is required to solve the problem, hence I suggest we concentrate on not breaking solutions that work now; And: . Here is a better option - we specify that an RBridge may be configured to provide an inter-VLAN proxy ARP service in a manner that is compatible with similar services offered at present and the mechanisms and potential protocols needed to accomplish this are out of scope for TRILL. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Monday, April 02, 2007 7:00 PM > To: rbridge@postel.org > Subject: [rbridge] Two "shared VLAN" alternative proposals > > Based on the thread, and some off-list communication with > Joel Halpern > and others, I now > would like to propose two concrete solutions. > > I'd like people to make comments like > . "either of them is fine, but I prefer this one because..." > . "neither of them solve the problem. The problem is ..." > . "here is a better option .. xxxxxxxxx" > > > Option 1: Making groupings known to all the RBridges > (slightly revised > from my original proposal) > -------------------------------------------------------------- > ------------------------------------ > > a) Make a group of VLANs {Z, A, B, C, D}, where VLAN Z is the > "primary" and > {A, B, C, D} are "secondaries". All RBridges learn about > this grouping > because > at least one RBridge RB1 has been configured to know these 5 VLANs > belong in a group, > and RB1 announces this grouping in its core IS-IS instance. > > A frame tagged with VLAN Z (say an ARP request > from the IP router) goes to all the links in all the VLANs in > the group > (i.e., Z, A, B, C, and D). While > in the core, the inner VLAN tag is Z. When an RBridge > decapsulates onto > a VLAN A link, it changes the > VLAN tag to A in order to forward it (or removes the VLAN tag). > > RBridges in the core do optimal filtering of VLAN-tagged packets, > so that something tagged VLAN D goes to D and Z, something > marked Z goes > to Z, A, B, C, and D, and > something marked F (not in a group) goes just to F. And the > distribution > tree gets filtered as early > as possible, by some core RBridge that notices no downstream > link leads > to any of the VLANs in the > set it is supposed to be delivering to. > > There will still be separate per-VLAN instances of Z, A, B, > C, and D. > These are not combined. > RBridges that only claim to be attached to VLAN Z, will also > participate > in the per-VLAN IS-IS > instances of A, B, C, and D, in that they will recieve and store the > link state announcements about endnodes > in those VLANs. > > If two different RBridges announce different groupings, say RB1 > announces {Z, A, B, C, D} and > RB2 announces {Z, A, E}, then we log an error, but core RBridges > treat the group as the set union, i.e. {Z, A, B, C, D, E}, for the > purpose of filtering multicasts tagged with > any of those VLAN tags. > > Option 2: Groupings only known to RBridges at the edge > involved in these > groupings > -------------------------------------------------------------- > ----------------------- > > b) Only RBridges associated with these groupings know > anything about the > grouping. So going with > our original example, an IP router is shared by VLANs A, B, C, and D, > and is assigned to VLAN Z. > The IP router is not aware of any of this, and assumes > everything is one > IP subnet. RBridges > attached to IP nodes in any of the VLANs {Z, A, B, C, D} > *are* aware of > this grouping. > > Suppose the IP router is > attached to RBridge RB1. The IP router does an ARP request. RB1 knows > that something from > the IP router is supposed to go to > VLANs Z, A, B, C, and D, so RB1 duplicates the packet (in > this case, the > ARP request), > creating 5 packets, and transmits one > into the cloud tagged as VLAN Z, one as VLAN A, one as VLAN B, one as > VLAN C, one as VLAN D. > In the IP router issues a unicast packet to MAC address M, > RB1 looks in > its endnode tables > for VLAN Z, VLAN A, VLAN B, VLAN C, and VLAN D. If RB1 finds > M, say in > VLAN B, > RB1 tags the packet as "VLAN B", and sends it to the egress > RBridge that > announced attachment to M > in VLAN B. I assume that RB1 stops when it finds M, and if M is in > multiple of these tables, too bad. > RB1 sends it to the first one it finds. > > For an RBridge RB2 attached to a "secondary VLAN", say C, the > same thing > happens. > Multicasts from C get duplicated so RB2 sends two copies, one marked > "VLAN C", and one marked "VLAN Z". > For unicast, RB2 sees if it can find the MAC address in its C > table or Z > table, and if it does, unicasts it > to the egress RBridge (marking the VLAN tag according to the table in > which it found the destination, > or leaving it as C; I think either one will work). > > But if RB2 does *not* find the destination in any of the > endnode tables, > RB2 creates two copies of the packet, one > marked VLAN Z, one marked VLAN B, and multicasts each one. > > ******************************************************** > Pros and cons of these two proposals > > Proposal a) is more optimal since packets to the group do not > need to be > duplicated, > and furthermore get filtered in the core. However, it > requires adding an > announcement > into the core IS-IS instance of what the VLAN groupings are, and some > thought as > to what to do if different RBridges announce different groupings. > > Proposal b) adds less complexity to the basic RBridge spec. Since no > sharing of > grouping information is done, misconfiguration will not be detectable. > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > Received: from xmail01.myhosting.com (xmail01.myhosting.com [168.144.250.16]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l33Cxv7m026720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 05:59:58 -0700 (PDT) Received: (qmail 25112 invoked from network); 3 Apr 2007 12:59:46 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender <riw@cisco.com>) by xmail01.myhosting.com (qmail-ldap-1.03) with SMTP for <Radia.Perlman@sun.com>; 3 Apr 2007 12:59:46 -0000 Message-ID: <46124F73.80808@cisco.com> Date: Tue, 03 Apr 2007 08:58:27 -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: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> <460F590E.5010207@sun.com> In-Reply-To: <460F590E.5010207@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] 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: Tue, 03 Apr 2007 13:00:51 -0000 Status: RO Content-Length: 507 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Argh! I'm really confused. Could we have a network diagram posted someplace on a web site? I'm finding this hard to follow from text descriptions.... ?? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEk9zER27sUhU9OQRAs00AJwLav8FeqJ59QvW9/jGuyaCw9Pn8ACdFqFn CLWoXE/tUZ9ouCsFEhdTOqU= =e8Vh -----END PGP SIGNATURE----- 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 l33BMqnJ028571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 3 Apr 2007 04:22:52 -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 l33BMosO003917; Tue, 3 Apr 2007 06:22:51 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 06:22:50 -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, 3 Apr 2007 06:22:45 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAFB7@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467706@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? Thread-Index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAAR6TwAAGkdP8A== References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA201467706@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "J. R. Rivers" <jrrivers@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-OriginalArrivalTime: 03 Apr 2007 11:22:50.0813 (UTC) FILETIME=[6A32EED0:01C775E2] 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 l33BMqnJ028571 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 03 Apr 2007 11:23:37 -0000 Status: RO Content-Length: 16197 JR, I agree. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: J. R. Rivers [mailto:jrrivers@nuovasystems.com] > Sent: Monday, April 02, 2007 6:52 PM > To: Eric Gray (LO/EUS); Radia Perlman; rbridge@postel.org > Cc: rbridge@postel.org > Subject: RE: [rbridge] Shared VLAN learning: What is it and > why should wecare? > Importance: High > > > These are issues that are commonly dealt with today when > routers (either > stand alone or "merged L3 switches") face this situation today. I > suggest focusing TRILL on retaining compatibility with today's > expectations rather than altering them in any way. > > JR > > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Eric Gray (LO/EUS) > > Sent: Monday, April 02, 2007 1:50 PM > > To: Radia Perlman > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > why should wecare? > > > > Radia, > > > > There is an interesting problem that might arise out of > > a router receiving VLAN tagged frames without being aware that > > they are tagged. > > > > A router is a MAC termination point - i.e. - it is an > > end-station at the MAC layer. But it is also a forwarding > > device. Hence the slack that might apply to a host receiving > > a MAC frame with "stuff" in the header it doesn't understand, > > shouldn't be allowed for a router. > > > > Also, many routers do understand that it is possible to > > have the same IP subnet connected to multiple logical interfaces. > > That was where the original "Bridging Router" (or BRouter) came > > from. > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > > Sent: Monday, April 02, 2007 4:10 PM > > > To: Eric Gray (LO/EUS) > > > Cc: rbridge@postel.org > > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > > why should we care? > > > Importance: High > > > > > > My understanding is that shared VLANs assume > > > IP routers are not aware of VLANs. > > > > > > My understanding is that the way it would work if the IP > > > router R *was* > > > aware of > > > VLANs, is that R would treat the link as 4 separate links > (by using > > > VLANs), and then the IP addresses > > > on the 4 different links (VLANs A, B, C, and D) would > have to have > > > different IP prefixes. > > > > > > So therefore, I am assuming that the IP router is not > > > supposed to know > > > that the link is subdivided into VLANs. > > > > > > So my understanding of the problem in this case is: > > > > > > a) single IP address block shared by different communities > > > b) desire to isolate these communities from layer 2 > > broadcast traffic > > > from each other > > > c) desire to share some services (like DHCP and IP > > routers), without > > > those services being aware > > > that the communities are separate > > > > > > As for my question about proxy ARP, to further add > > > to the confusion -- some people are assuming the > > > bridge/RBridge will be > > > doing > > > the proxy ARP, and some others are assuming the router is. > > > > > > And actually, after talking offline with Joel Halpern, I'll > > > send another > > > note with two different proposals > > > (one just a cleanup of what I originally wrote, and the other a > > > different approach) for solving > > > that vaguely stated problem. > > > > > > Radia > > > > > > > > > > > > > > > > > > Eric Gray (LO/EUS) wrote: > > > > > > >Radia, > > > > > > > > Let me try to re-state your explanation to see if I understand > > > >it... > > > > > > > > You believe that the problem that shared VLAN learning is used > > > >to solve is conservation of IP addresses used in a single > > IP subnet, > > > >and that it is necessary to use shared VLAN learning to > > keep routers > > > >(in the subnet) from having to re-learn MAC+IP > > associations across a > > > >set of VLANs in that same IP subnet, is that correct? > > > > > > > >Thanks! > > > > > > > >-- > > > >Eric Gray > > > >Principal Engineer > > > >Ericsson > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: rbridge-bounces@postel.org > > > >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > >>Sent: Thursday, March 29, 2007 2:56 AM > > > >>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 > > > >> > > > >> > > > >> > > > > > > > > > > _______________________________________________ > > 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 l32N06Qf021721 for <rbridge@postel.org>; Mon, 2 Apr 2007 16:00:06 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JFW00N6Z7W40T00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 02 Apr 2007 16:00:04 -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 <0JFW00BNZ7W3S000@mail.sunlabs.com> for rbridge@postel.org; Mon, 02 Apr 2007 16:00:04 -0700 (PDT) Date: Mon, 02 Apr 2007 16:00:20 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <941D5DCD8C42014FAF70FB7424686DCFACAF28@eusrcmw721.eamcs.ericsson.se> To: rbridge@postel.org Message-id: <46118B04.5000501@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: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BA738@NT-IRVA-0750.brcm.ad.broadcom.com> <941D5DCD8C42014FAF70FB7424686DCFACAF28@eusrcmw721.eamcs.ericsson.se> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] Two "shared VLAN" alternative proposals 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, 02 Apr 2007 23:00:46 -0000 Status: RO Content-Length: 4722 Based on the thread, and some off-list communication with Joel Halpern and others, I now would like to propose two concrete solutions. I'd like people to make comments like . "either of them is fine, but I prefer this one because..." . "neither of them solve the problem. The problem is ..." . "here is a better option .. xxxxxxxxx" Option 1: Making groupings known to all the RBridges (slightly revised from my original proposal) -------------------------------------------------------------------------------------------------- a) Make a group of VLANs {Z, A, B, C, D}, where VLAN Z is the "primary" and {A, B, C, D} are "secondaries". All RBridges learn about this grouping because at least one RBridge RB1 has been configured to know these 5 VLANs belong in a group, and RB1 announces this grouping in its core IS-IS instance. A frame tagged with VLAN Z (say an ARP request from the IP router) goes to all the links in all the VLANs in the group (i.e., Z, A, B, C, and D). While in the core, the inner VLAN tag is Z. When an RBridge decapsulates onto a VLAN A link, it changes the VLAN tag to A in order to forward it (or removes the VLAN tag). RBridges in the core do optimal filtering of VLAN-tagged packets, so that something tagged VLAN D goes to D and Z, something marked Z goes to Z, A, B, C, and D, and something marked F (not in a group) goes just to F. And the distribution tree gets filtered as early as possible, by some core RBridge that notices no downstream link leads to any of the VLANs in the set it is supposed to be delivering to. There will still be separate per-VLAN instances of Z, A, B, C, and D. These are not combined. RBridges that only claim to be attached to VLAN Z, will also participate in the per-VLAN IS-IS instances of A, B, C, and D, in that they will recieve and store the link state announcements about endnodes in those VLANs. If two different RBridges announce different groupings, say RB1 announces {Z, A, B, C, D} and RB2 announces {Z, A, E}, then we log an error, but core RBridges treat the group as the set union, i.e. {Z, A, B, C, D, E}, for the purpose of filtering multicasts tagged with any of those VLAN tags. Option 2: Groupings only known to RBridges at the edge involved in these groupings ------------------------------------------------------------------------------------- b) Only RBridges associated with these groupings know anything about the grouping. So going with our original example, an IP router is shared by VLANs A, B, C, and D, and is assigned to VLAN Z. The IP router is not aware of any of this, and assumes everything is one IP subnet. RBridges attached to IP nodes in any of the VLANs {Z, A, B, C, D} *are* aware of this grouping. Suppose the IP router is attached to RBridge RB1. The IP router does an ARP request. RB1 knows that something from the IP router is supposed to go to VLANs Z, A, B, C, and D, so RB1 duplicates the packet (in this case, the ARP request), creating 5 packets, and transmits one into the cloud tagged as VLAN Z, one as VLAN A, one as VLAN B, one as VLAN C, one as VLAN D. In the IP router issues a unicast packet to MAC address M, RB1 looks in its endnode tables for VLAN Z, VLAN A, VLAN B, VLAN C, and VLAN D. If RB1 finds M, say in VLAN B, RB1 tags the packet as "VLAN B", and sends it to the egress RBridge that announced attachment to M in VLAN B. I assume that RB1 stops when it finds M, and if M is in multiple of these tables, too bad. RB1 sends it to the first one it finds. For an RBridge RB2 attached to a "secondary VLAN", say C, the same thing happens. Multicasts from C get duplicated so RB2 sends two copies, one marked "VLAN C", and one marked "VLAN Z". For unicast, RB2 sees if it can find the MAC address in its C table or Z table, and if it does, unicasts it to the egress RBridge (marking the VLAN tag according to the table in which it found the destination, or leaving it as C; I think either one will work). But if RB2 does *not* find the destination in any of the endnode tables, RB2 creates two copies of the packet, one marked VLAN Z, one marked VLAN B, and multicasts each one. ******************************************************** Pros and cons of these two proposals Proposal a) is more optimal since packets to the group do not need to be duplicated, and furthermore get filtered in the core. However, it requires adding an announcement into the core IS-IS instance of what the VLAN groupings are, and some thought as to what to do if different RBridges announce different groupings. Proposal b) adds less complexity to the basic RBridge spec. Since no sharing of grouping information is done, misconfiguration will not be detectable. 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 l32MptoT019371 for <rbridge@postel.org>; Mon, 2 Apr 2007 15:51:55 -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, 2 Apr 2007 15:51:42 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467706@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? thread-index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAAR6TwA= References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> From: "J. R. Rivers" <jrrivers@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> 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 l32MptoT019371 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 22:52:56 -0000 Status: RO Content-Length: 14916 These are issues that are commonly dealt with today when routers (either stand alone or "merged L3 switches") face this situation today. I suggest focusing TRILL on retaining compatibility with today's expectations rather than altering them in any way. JR > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Eric Gray (LO/EUS) > Sent: Monday, April 02, 2007 1:50 PM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should wecare? > > Radia, > > There is an interesting problem that might arise out of > a router receiving VLAN tagged frames without being aware that > they are tagged. > > A router is a MAC termination point - i.e. - it is an > end-station at the MAC layer. But it is also a forwarding > device. Hence the slack that might apply to a host receiving > a MAC frame with "stuff" in the header it doesn't understand, > shouldn't be allowed for a router. > > Also, many routers do understand that it is possible to > have the same IP subnet connected to multiple logical interfaces. > That was where the original "Bridging Router" (or BRouter) came > from. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > Sent: Monday, April 02, 2007 4:10 PM > > To: Eric Gray (LO/EUS) > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > why should we care? > > Importance: High > > > > My understanding is that shared VLANs assume > > IP routers are not aware of VLANs. > > > > My understanding is that the way it would work if the IP > > router R *was* > > aware of > > VLANs, is that R would treat the link as 4 separate links (by using > > VLANs), and then the IP addresses > > on the 4 different links (VLANs A, B, C, and D) would have to have > > different IP prefixes. > > > > So therefore, I am assuming that the IP router is not > > supposed to know > > that the link is subdivided into VLANs. > > > > So my understanding of the problem in this case is: > > > > a) single IP address block shared by different communities > > b) desire to isolate these communities from layer 2 > broadcast traffic > > from each other > > c) desire to share some services (like DHCP and IP > routers), without > > those services being aware > > that the communities are separate > > > > As for my question about proxy ARP, to further add > > to the confusion -- some people are assuming the > > bridge/RBridge will be > > doing > > the proxy ARP, and some others are assuming the router is. > > > > And actually, after talking offline with Joel Halpern, I'll > > send another > > note with two different proposals > > (one just a cleanup of what I originally wrote, and the other a > > different approach) for solving > > that vaguely stated problem. > > > > Radia > > > > > > > > > > > > Eric Gray (LO/EUS) wrote: > > > > >Radia, > > > > > > Let me try to re-state your explanation to see if I understand > > >it... > > > > > > You believe that the problem that shared VLAN learning is used > > >to solve is conservation of IP addresses used in a single > IP subnet, > > >and that it is necessary to use shared VLAN learning to > keep routers > > >(in the subnet) from having to re-learn MAC+IP > associations across a > > >set of VLANs in that same IP subnet, is that correct? > > > > > >Thanks! > > > > > >-- > > >Eric Gray > > >Principal Engineer > > >Ericsson > > > > > > > > > > > >>-----Original Message----- > > >>From: rbridge-bounces@postel.org > > >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > >>Sent: Thursday, March 29, 2007 2:56 AM > > >>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 > > >> > > >> > > >> > > > > > > _______________________________________________ > 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 l32MFESA009519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 2 Apr 2007 15:15:15 -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 l32MFDpT030442; Mon, 2 Apr 2007 17:15:13 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 17:15:12 -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: Mon, 2 Apr 2007 17:15:09 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAF28@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BA738@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 wecare? Thread-Index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAACw8FAAAKZksAABMizg References: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BA738@NT-IRVA-0750.brcm.ad.broadcom.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 02 Apr 2007 22:15:12.0954 (UTC) FILETIME=[6251E9A0:01C77574] 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 l32MFESA009519 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 22:16:14 -0000 Status: RO Content-Length: 5510 Caitlin, I'm not sure who you're addressing this to, but I'll take a crack at answering it. Please see below... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Monday, April 02, 2007 5:37 PM > To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman > Cc: rbridge@postel.org > Subject: RE: [rbridge] Shared VLAN learning: What is it and > why should wecare? > Importance: High > > rbridge-bounces@postel.org wrote: > > Eric, > > > >> -----Original Message----- > >> From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] > >> On Behalf Of Eric Gray (LO/EUS) Sent: Monday, April 02, > 2007 1:50 PM > >> To: Radia Perlman > >> Cc: rbridge@postel.org > >> Subject: Re: [rbridge] Shared VLAN learning: What is it and why > >> should wecare? > >> > >> Radia, > >> > >> There is an interesting problem that might arise out of a router > >> receiving VLAN tagged frames without being aware that they are > >> tagged. > >> > > > > This is not the case, unless there is a misconfiguration. A > > Router has a > > concept of an interface (e.g. eth0, the Ethernet port) and of > > sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to > > sub-interfaces. When a frame arrive the VID (VLAN ID), > either explicit > > or implicit, is used to select a sub-interface. The > > sub-interface has an > > IP address and a netmask. > > > > -- Silvano > > > > > > If you review the email I cited previously, and then do some googling, > you'll see that assigning each VLAN a recognizable IP subnet is merely > the predominant technique -- it is not the only one, and it is not a > requirement. > > Do you agree that when a router connects to multiple VLANs that share > an IP subnet that having the RBridge generate a Proxied ARP response > to the *same* IP address on each VLAN is a problem that needs to > be solved? I agree. However, solving it may be simply requiring that implementations are configurable to avoid the pathological consequences of this situation. Since this would be the case today with existing VLAN aware devices, I am not sure what we (TRILL) needs to say or whether or not it even makes any sense for us to say anything. It is usually not necessary to specify that implementers should not build broken implementations. > > How do you prevent the incorrect Proxied ARP response without sharing > the endnode discovery over the truly relevant span, rather than just > within the VLAN? So, here's my take: o If SVL is in use, then it is usually necessary that all of the bridges have a consistent view of which VLANS are shared (this is independent of a specific FID <-> VID mapping except that the same VIDs SHOULD be mapped to a single locally determined FID in all bridges in a given deployment). o This would typically be a matter of configuration, although it is possible that configration tools may be used to help ensure that a consistent picture is "shared" among bridges. o Existence of VLANs in a deployment typically means configuration is required to make the VLANs work (hence this is not strictly a _new_ requirement to steer us away from the plug-and-play objective). o Whether SVL, or IVL, is used - if IP-MAC binding information is only distributed where appropriate (based on VID) at each RBridge, then it is difficult for me to see how incorrect proxied ARP responses would occur. o Even if all IP-MAC binding information was distributed to all RBridges, as long as this information is scoped by the designated RBridge in any ARP responses it might provide (by relevant VID in the request), then it is still difficult to see how incorrect proxied ARP responses might occur. > > This is a more pressing issue than just Shared vs. Independent Learning. > Mandating that all RBridges use Independent Learning is undesirable to > the extent that specifications should be minimalistic and impose as > few constraints as possible. But realistically I doubt that Shared > Learning is really desirable for RBridges. Okay. Do I get to say "I told you so" when you get aroud to eating that opinion? :-) > > The shared IP subnet issue, however, has nothing to do with RBridges. > Forbidding sharing of IP subnets across VLANs would be considerably > more drastic, and presumably outside the WG's scope. For one thing > it would directly contradict RFC 3069: > > The VLAN [802.1Q] aggregation technique described in this document > provides a mechanism by which hosts that reside within the same > physical switched infrastructure, but separate virtual broadcast > domains, may be addressed from the same IPv4 subnet and may share a > common default gateway IPv4 address. > > ... > > > Essentially, what occurs is that each sub-VLAN (customer) remains > within a separate broadcast domain. One or more sub-VLANs belong > to a super-VLAN, and utilize the default gateway IP address of the > super-VLAN. Hosts within the sub-VLANs are numbered out of IP > subnets associated with the super-VLAN, and their IP subnet masking > information reflects that of the super-VLAN subnet. I think we should avoid the "super-VLAN" concept. What you seem to be talking about is IP subnets, rather than VLAN aggregation. > > If desired, the super-VLAN router performs functions similar to > Proxy ARP to enable communication between hosts that are members > of different sub-VLANs. > > 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 l32LpscR002382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 2 Apr 2007 14:51:55 -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 l32MHWWU025647; Mon, 2 Apr 2007 17:17:32 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:51:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Apr 2007 16:51:50 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAF09@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014676A2@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? Thread-Index: Acdx0OK13S62YKj/Tf+ogH260nq4ZQDiWMjAAAVDreAAAE6k0A== References: <460B6304.3020507@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2014676A2@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 02 Apr 2007 21:51:53.0369 (UTC) FILETIME=[201A3090:01C77571] 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 l32LpscR002382 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 21:52:13 -0000 Status: RO Content-Length: 18372 Silvano, Possibly this was meant as a reply to a different message? If you look at the text below, one of my early paragraphs (the one that starts "In one case, there may be a VLAN aware bridge between the IP router and the 4 VLANs ...") is nearly identical to the illustration you describe. So, I think we can assume we're at least talking about the same thing. Which leaves me wondering what your point is... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Monday, April 02, 2007 5:45 PM > To: Eric Gray (LO/EUS); Radia Perlman > Cc: rbridge@postel.org > Subject: RE: [rbridge] Shared VLAN learning: What is it and > why should wecare? > > > Eric, > > Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs. > In figure B-4 assume a router instead of the Server. > As you can see the link between the router and the Bridge is untagged. > Being the link untagged the router will have a single sub-interface > associated to a single IP subnet. > > Nonetheless it will be on the Red, Blue and Purple Asymmetric > (Private) > VLANs. The frames received by the router will be legal IP frames. > > I don't know if we are in agreement, but this is the most pertinent > example I am able to come out with. > > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Eric Gray (LO/EUS) > > Sent: Monday, April 02, 2007 2:08 PM > > To: Radia Perlman > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should > > wecare? > > > > Radia, > > > > WRT your quiz question: > > > > To expand on Sanjay's earlier reply (assuming I've understood > > your questions correctly), you've assumed an essentially broken IP > > subnet configuration. That doesn't mean that it wouldn't work with > > today's devices, but it does mean that it is not working the way I > > believe you have described it. > > > > Sanjay is correct about ARP as a function of the IP router. A > > "smart bridge" may incorporate enough of the routing > function to help > > out in this scenario, but is not a standards defined implementation > > if it does. There is a fairly long list of caveats that must apply > > in that case, and this is not an area we want to explore - unless it > > turns out to be the case that someone does this incorrectly and we > > find that we need to be compatible with the incorrect > implementation. > > > > In one case, there may be a VLAN aware bridge between the IP > > router and the 4 VLANs you describe. In implementations, this VLAN > > aware bridge may actually be co-located with the IP router. In this > > case, the VLAN aware bridge may very well forward un-tagged > frames to > > and from the (potentially co-located) IP router, across one > (possibly > > logical) link, allowing the router to enjoy simplified ARP learning. > > This VLAN aware bridge then provides the VLAN translation > function to > > allow proper forwarding of data within the subnet. > > > > Note that - in this case - the VLAN aware bridge is translating > > untagged frames into tagged frames (and vice versa), but is > not doing > > the similar translation (one tag to another) between distinct tagged > > VLANs. That function must be done by a router - hence the router is > > supposed to handle ARP responses and associate IP-to-MAC so > that it is > > in the forwarding path (much as Sanjay described). > > > > Because you're assuming over-lapping assignments of IP > > addresses, > > this scenario causes problems for a standards defined IP router > because > > it will see all of the subnet-local IP destinations as > being part of a > > single IP subnet, and will - most likely - try to force the > senders in > > the IP sub-network to send directly to destination MAC > addresses - via > > ARP responses (assuming single subnet) and IP re-directs. > > > > As you probably realize, that situation would be pathological. > > > > This situation arises in real networks, and has been addressed > > in real implementations. One approach blurs the distinction between > > the VLAN aware bridging and standard routing functions. > > > > For the co-located case, this is not hard: the router sees more > > than one VLAN on a single physical interface, but is configured (or > > learns) that these multiple logical interfaces are all part of the > same > > IP subnet. In this case, the router is required to bridge > between the > > multiple logical interfaces that are part of a single logical IP > subnet. > > > > An implementation may instantiate a VLAN-aware bridging instance > > > > to handle this role. In this case, the boundary between > bridging and > > routing becomes blurred because the same physical device is involved > > in both - making the handling of ARP and appropriate VLAN forwarding > > work because the router can carefully choose which role it > assumes in > > dealing with ARP and forwarding of traffic. If this takes > place in a > > single device, it is possible to avoid many of the caveats > that would > > apply if this particular form of cheating was distributed. > > > > In the non-colocated case, a bit more work is required to make > > the scenario functional and a number of caveats cannot be completely > > avoided. For example, if there is exactly one VLAN aware bridge in > > the local IP-subnet, it is possible for that bridge to "proxy" ARP > > responses (as if it were a router) and forward frames between VLANs. > > If there are multiple VLAN aware bridges, then it should be possible > > to configure them so that only one of them performs this function. > > A more complex configuration is possible, but such a > configuration is > > workable only if there is no potential forwarding path > (including any > > possible failure mode) which results in multiple VLAN ID > translations > > - and forwarding - between multiple VLAN aware bridges, in a loop. > > > > For RBridges, the situation we need to avoid is as shown below: > > > > Host Group-P > > A > > | > > _____VLAN-A______ > > | | > > V V > > R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host > > Group Q > > > > If both the RBridges and the VLAN aware Bridge (VAB) are doing > > Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is > > possible for frames to be forwarded consistently back and forth > between > > the RBridge CRED/Campus and VAB. Moreover, it is possible > for a host > > in group P in this diagram, to get a copy of each frame each time it > > goes around. > > > > Still another alternative is that IP addresses are not assigned > > as you suggest, and VLAN tags are used simply to share physical link > > resources - while maintaining IP address space separation. Many of > > the router vendors today (I believe) would claim that the > alternative > > is pathological... > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: rbridge-bounces@postel.org > > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > Sent: Thursday, March 29, 2007 2:56 AM > > > 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 > > > > > > > _______________________________________________ > > 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 l32LiuMq029784 for <rbridge@postel.org>; Mon, 2 Apr 2007 14:44:56 -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, 2 Apr 2007 14:44:41 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014676A2@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? thread-index: Acdx0OK13S62YKj/Tf+ogH260nq4ZQDiWMjAAAVDreA= References: <460B6304.3020507@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.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 l32LiuMq029784 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 21:46:11 -0000 Status: RO Content-Length: 16645 Eric, Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs. In figure B-4 assume a router instead of the Server. As you can see the link between the router and the Bridge is untagged. Being the link untagged the router will have a single sub-interface associated to a single IP subnet. Nonetheless it will be on the Red, Blue and Purple Asymmetric (Private) VLANs. The frames received by the router will be legal IP frames. I don't know if we are in agreement, but this is the most pertinent example I am able to come out with. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eric Gray (LO/EUS) > Sent: Monday, April 02, 2007 2:08 PM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > Radia, > > WRT your quiz question: > > To expand on Sanjay's earlier reply (assuming I've understood > your questions correctly), you've assumed an essentially broken IP > subnet configuration. That doesn't mean that it wouldn't work with > today's devices, but it does mean that it is not working the way I > believe you have described it. > > Sanjay is correct about ARP as a function of the IP router. A > "smart bridge" may incorporate enough of the routing function to help > out in this scenario, but is not a standards defined implementation > if it does. There is a fairly long list of caveats that must apply > in that case, and this is not an area we want to explore - unless it > turns out to be the case that someone does this incorrectly and we > find that we need to be compatible with the incorrect implementation. > > In one case, there may be a VLAN aware bridge between the IP > router and the 4 VLANs you describe. In implementations, this VLAN > aware bridge may actually be co-located with the IP router. In this > case, the VLAN aware bridge may very well forward un-tagged frames to > and from the (potentially co-located) IP router, across one (possibly > logical) link, allowing the router to enjoy simplified ARP learning. > This VLAN aware bridge then provides the VLAN translation function to > allow proper forwarding of data within the subnet. > > Note that - in this case - the VLAN aware bridge is translating > untagged frames into tagged frames (and vice versa), but is not doing > the similar translation (one tag to another) between distinct tagged > VLANs. That function must be done by a router - hence the router is > supposed to handle ARP responses and associate IP-to-MAC so that it is > in the forwarding path (much as Sanjay described). > > Because you're assuming over-lapping assignments of IP > addresses, > this scenario causes problems for a standards defined IP router because > it will see all of the subnet-local IP destinations as being part of a > single IP subnet, and will - most likely - try to force the senders in > the IP sub-network to send directly to destination MAC addresses - via > ARP responses (assuming single subnet) and IP re-directs. > > As you probably realize, that situation would be pathological. > > This situation arises in real networks, and has been addressed > in real implementations. One approach blurs the distinction between > the VLAN aware bridging and standard routing functions. > > For the co-located case, this is not hard: the router sees more > than one VLAN on a single physical interface, but is configured (or > learns) that these multiple logical interfaces are all part of the same > IP subnet. In this case, the router is required to bridge between the > multiple logical interfaces that are part of a single logical IP subnet. > > An implementation may instantiate a VLAN-aware bridging instance > > to handle this role. In this case, the boundary between bridging and > routing becomes blurred because the same physical device is involved > in both - making the handling of ARP and appropriate VLAN forwarding > work because the router can carefully choose which role it assumes in > dealing with ARP and forwarding of traffic. If this takes place in a > single device, it is possible to avoid many of the caveats that would > apply if this particular form of cheating was distributed. > > In the non-colocated case, a bit more work is required to make > the scenario functional and a number of caveats cannot be completely > avoided. For example, if there is exactly one VLAN aware bridge in > the local IP-subnet, it is possible for that bridge to "proxy" ARP > responses (as if it were a router) and forward frames between VLANs. > If there are multiple VLAN aware bridges, then it should be possible > to configure them so that only one of them performs this function. > A more complex configuration is possible, but such a configuration is > workable only if there is no potential forwarding path (including any > possible failure mode) which results in multiple VLAN ID translations > - and forwarding - between multiple VLAN aware bridges, in a loop. > > For RBridges, the situation we need to avoid is as shown below: > > Host Group-P > A > | > _____VLAN-A______ > | | > V V > R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host > Group Q > > If both the RBridges and the VLAN aware Bridge (VAB) are doing > Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is > possible for frames to be forwarded consistently back and forth between > the RBridge CRED/Campus and VAB. Moreover, it is possible for a host > in group P in this diagram, to get a copy of each frame each time it > goes around. > > Still another alternative is that IP addresses are not assigned > as you suggest, and VLAN tags are used simply to share physical link > resources - while maintaining IP address space separation. Many of > the router vendors today (I believe) would claim that the alternative > is pathological... > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@postel.org > > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > Sent: Thursday, March 29, 2007 2:56 AM > > 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 > > > > _______________________________________________ > 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 l32LbgdJ027765 for <rbridge@postel.org>; Mon, 2 Apr 2007 14:37:42 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 02 Apr 2007 14:37:31 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 361EC2AF; Mon, 2 Apr 2007 14:37:31 -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 20B082AE; Mon, 2 Apr 2007 14:37:31 -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 FDK42078; Mon, 2 Apr 2007 14:37:30 -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 9EFCD69CA3; Mon, 2 Apr 2007 14:37:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Apr 2007 14:37:29 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA738@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? Thread-Index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAACw8FAAAKZksA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A0FA81137011801776-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 l32LbgdJ027765 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 21:38:07 -0000 Status: RO Content-Length: 2988 rbridge-bounces@postel.org wrote: > Eric, > >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >> On Behalf Of Eric Gray (LO/EUS) Sent: Monday, April 02, 2007 1:50 PM >> To: Radia Perlman >> Cc: rbridge@postel.org >> Subject: Re: [rbridge] Shared VLAN learning: What is it and why >> should wecare? >> >> Radia, >> >> There is an interesting problem that might arise out of a router >> receiving VLAN tagged frames without being aware that they are >> tagged. >> > > This is not the case, unless there is a misconfiguration. A > Router has a > concept of an interface (e.g. eth0, the Ethernet port) and of > sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to > sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit > or implicit, is used to select a sub-interface. The > sub-interface has an > IP address and a netmask. > > -- Silvano > > If you review the email I cited previously, and then do some googling, you'll see that assigning each VLAN a recognizable IP subnet is merely the predominant technique -- it is not the only one, and it is not a requirement. Do you agree that when a router connects to multiple VLANs that share an IP subnet that having the RBridge generate a Proxied ARP response to the *same* IP address on each VLAN is a problem that needs to be solved? How do you prevent the incorrect Proxied ARP response without sharing the endnode discovery over the truly relevant span, rather than just within the VLAN? This is a more pressing issue than just Shared vs. Independent Learning. Mandating that all RBridges use Independent Learning is undesirable to the extent that specifications should be minimalistic and impose as few constraints as possible. But realistically I doubt that Shared Learning is really desirable for RBridges. The shared IP subnet issue, however, has nothing to do with RBridges. Forbidding sharing of IP subnets across VLANs would be considerably more drastic, and presumably outside the WG's scope. For one thing it would directly contradict RFC 3069: The VLAN [802.1Q] aggregation technique described in this document provides a mechanism by which hosts that reside within the same physical switched infrastructure, but separate virtual broadcast domains, may be addressed from the same IPv4 subnet and may share a common default gateway IPv4 address. ... Essentially, what occurs is that each sub-VLAN (customer) remains within a separate broadcast domain. One or more sub-VLANs belong to a super-VLAN, and utilize the default gateway IP address of the super-VLAN. Hosts within the sub-VLANs are numbered out of IP subnets associated with the super-VLAN, and their IP subnet masking information reflects that of the super-VLAN subnet. If desired, the super-VLAN router performs functions similar to Proxy ARP to enable communication between hosts that are members of different sub-VLANs. 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 l32LFfQF021314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 2 Apr 2007 14:15:41 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l32LfHSA021317; Mon, 2 Apr 2007 16:41:18 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:15:38 -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: Mon, 2 Apr 2007 16:15:35 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAED4@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? Thread-Index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAACw8FAAAFDUgA== References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 02 Apr 2007 21:15:38.0957 (UTC) FILETIME=[100D3FD0:01C7756C] 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 l32LFfQF021314 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 21:16:14 -0000 Status: RO Content-Length: 16638 Silvano, Uhhhh, yes, but that makes the router aware of VLANs - doesn't it? Getting back to Radia's statement (below) - "So therefore, I (Radia) am assuming that the IP router is not supposed to know that the link is subdivided into VLANs." I think you need to review the order of the dialog. I was pointing out that Radia's assumption of router ignorance of VIDs would be a problem. You apparently would argue that routers are not ignorant of VIDs. So, unless I am misunderstanding you, I believe we are in agreement. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Silvano Gai [mailto:sgai@nuovasystems.com] > Sent: Monday, April 02, 2007 5:06 PM > To: Eric Gray (LO/EUS); Radia Perlman > Cc: rbridge@postel.org > Subject: RE: [rbridge] Shared VLAN learning: What is it and > why should wecare? > Importance: High > > Eric, > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Eric Gray (LO/EUS) > > Sent: Monday, April 02, 2007 1:50 PM > > To: Radia Perlman > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should > > wecare? > > > > Radia, > > > > There is an interesting problem that might arise out of > > a router receiving VLAN tagged frames without being aware that > > they are tagged. > > > > This is not the case, unless there is a misconfiguration. A > Router has a > concept of an interface (e.g. eth0, the Ethernet port) and of > sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to > sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit > or implicit, is used to select a sub-interface. The > sub-interface has an > IP address and a netmask. > > -- Silvano > > > > A router is a MAC termination point - i.e. - it is an > > end-station at the MAC layer. But it is also a forwarding > > device. Hence the slack that might apply to a host receiving > > a MAC frame with "stuff" in the header it doesn't understand, > > shouldn't be allowed for a router. > > > > Also, many routers do understand that it is possible to > > have the same IP subnet connected to multiple logical interfaces. > > That was where the original "Bridging Router" (or BRouter) came > > from. > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > > > -----Original Message----- > > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > > Sent: Monday, April 02, 2007 4:10 PM > > > To: Eric Gray (LO/EUS) > > > Cc: rbridge@postel.org > > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > > why should we care? > > > Importance: High > > > > > > My understanding is that shared VLANs assume > > > IP routers are not aware of VLANs. > > > > > > My understanding is that the way it would work if the IP > > > router R *was* > > > aware of > > > VLANs, is that R would treat the link as 4 separate links > (by using > > > VLANs), and then the IP addresses > > > on the 4 different links (VLANs A, B, C, and D) would have to have > > > different IP prefixes. > > > > > > So therefore, I am assuming that the IP router is not > > > supposed to know > > > that the link is subdivided into VLANs. > > > > > > So my understanding of the problem in this case is: > > > > > > a) single IP address block shared by different communities > > > b) desire to isolate these communities from layer 2 broadcast > traffic > > > from each other > > > c) desire to share some services (like DHCP and IP > routers), without > > > those services being aware > > > that the communities are separate > > > > > > As for my question about proxy ARP, to further add > > > to the confusion -- some people are assuming the > > > bridge/RBridge will be > > > doing > > > the proxy ARP, and some others are assuming the router is. > > > > > > And actually, after talking offline with Joel Halpern, I'll > > > send another > > > note with two different proposals > > > (one just a cleanup of what I originally wrote, and the other a > > > different approach) for solving > > > that vaguely stated problem. > > > > > > Radia > > > > > > > > > > > > > > > > > > Eric Gray (LO/EUS) wrote: > > > > > > >Radia, > > > > > > > > Let me try to re-state your explanation to see if I understand > > > >it... > > > > > > > > You believe that the problem that shared VLAN learning is used > > > >to solve is conservation of IP addresses used in a single IP > subnet, > > > >and that it is necessary to use shared VLAN learning to keep > routers > > > >(in the subnet) from having to re-learn MAC+IP > associations across > a > > > >set of VLANs in that same IP subnet, is that correct? > > > > > > > >Thanks! > > > > > > > >-- > > > >Eric Gray > > > >Principal Engineer > > > >Ericsson > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: rbridge-bounces@postel.org > > > >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > > >>Sent: Thursday, March 29, 2007 2:56 AM > > > >>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 > > > >> > > > >> > > > >> > > > > > > > > > > _______________________________________________ > > 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 l32L8R7S019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 2 Apr 2007 14:08:27 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l32L8Q0G019353; Mon, 2 Apr 2007 16:08:26 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:08:26 -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: Mon, 2 Apr 2007 16:08:23 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> 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: Acdx0OK13S62YKj/Tf+ogH260nq4ZQDiWMjA References: <460B6304.3020507@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 02 Apr 2007 21:08:26.0367 (UTC) FILETIME=[0E3540F0:01C7756B] 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 l32L8R7S019332 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: Mon, 02 Apr 2007 21:08:38 -0000 Status: RO Content-Length: 15029 Radia, WRT your quiz question: To expand on Sanjay's earlier reply (assuming I've understood your questions correctly), you've assumed an essentially broken IP subnet configuration. That doesn't mean that it wouldn't work with today's devices, but it does mean that it is not working the way I believe you have described it. Sanjay is correct about ARP as a function of the IP router. A "smart bridge" may incorporate enough of the routing function to help out in this scenario, but is not a standards defined implementation if it does. There is a fairly long list of caveats that must apply in that case, and this is not an area we want to explore - unless it turns out to be the case that someone does this incorrectly and we find that we need to be compatible with the incorrect implementation. In one case, there may be a VLAN aware bridge between the IP router and the 4 VLANs you describe. In implementations, this VLAN aware bridge may actually be co-located with the IP router. In this case, the VLAN aware bridge may very well forward un-tagged frames to and from the (potentially co-located) IP router, across one (possibly logical) link, allowing the router to enjoy simplified ARP learning. This VLAN aware bridge then provides the VLAN translation function to allow proper forwarding of data within the subnet. Note that - in this case - the VLAN aware bridge is translating untagged frames into tagged frames (and vice versa), but is not doing the similar translation (one tag to another) between distinct tagged VLANs. That function must be done by a router - hence the router is supposed to handle ARP responses and associate IP-to-MAC so that it is in the forwarding path (much as Sanjay described). Because you're assuming over-lapping assignments of IP addresses, this scenario causes problems for a standards defined IP router because it will see all of the subnet-local IP destinations as being part of a single IP subnet, and will - most likely - try to force the senders in the IP sub-network to send directly to destination MAC addresses - via ARP responses (assuming single subnet) and IP re-directs. As you probably realize, that situation would be pathological. This situation arises in real networks, and has been addressed in real implementations. One approach blurs the distinction between the VLAN aware bridging and standard routing functions. For the co-located case, this is not hard: the router sees more than one VLAN on a single physical interface, but is configured (or learns) that these multiple logical interfaces are all part of the same IP subnet. In this case, the router is required to bridge between the multiple logical interfaces that are part of a single logical IP subnet. An implementation may instantiate a VLAN-aware bridging instance to handle this role. In this case, the boundary between bridging and routing becomes blurred because the same physical device is involved in both - making the handling of ARP and appropriate VLAN forwarding work because the router can carefully choose which role it assumes in dealing with ARP and forwarding of traffic. If this takes place in a single device, it is possible to avoid many of the caveats that would apply if this particular form of cheating was distributed. In the non-colocated case, a bit more work is required to make the scenario functional and a number of caveats cannot be completely avoided. For example, if there is exactly one VLAN aware bridge in the local IP-subnet, it is possible for that bridge to "proxy" ARP responses (as if it were a router) and forward frames between VLANs. If there are multiple VLAN aware bridges, then it should be possible to configure them so that only one of them performs this function. A more complex configuration is possible, but such a configuration is workable only if there is no potential forwarding path (including any possible failure mode) which results in multiple VLAN ID translations - and forwarding - between multiple VLAN aware bridges, in a loop. For RBridges, the situation we need to avoid is as shown below: Host Group-P A | _____VLAN-A______ | | V V R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host Group Q If both the RBridges and the VLAN aware Bridge (VAB) are doing Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is possible for frames to be forwarded consistently back and forth between the RBridge CRED/Campus and VAB. Moreover, it is possible for a host in group P in this diagram, to get a copy of each frame each time it goes around. Still another alternative is that IP addresses are not assigned as you suggest, and VLAN tags are used simply to share physical link resources - while maintaining IP address space separation. Many of the router vendors today (I believe) would claim that the alternative is pathological... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, March 29, 2007 2:56 AM > 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 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 l32L66Zl018853 for <rbridge@postel.org>; Mon, 2 Apr 2007 14:06:06 -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, 2 Apr 2007 14:05:47 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should wecare? thread-index: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5AwAACw8FA= References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.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 l32L66Zl018853 Cc: rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare? 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, 02 Apr 2007 21:06:38 -0000 Status: RO Content-Length: 14852 Eric, > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Eric Gray (LO/EUS) > Sent: Monday, April 02, 2007 1:50 PM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > Radia, > > There is an interesting problem that might arise out of > a router receiving VLAN tagged frames without being aware that > they are tagged. > This is not the case, unless there is a misconfiguration. A Router has a concept of an interface (e.g. eth0, the Ethernet port) and of sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit or implicit, is used to select a sub-interface. The sub-interface has an IP address and a netmask. -- Silvano > A router is a MAC termination point - i.e. - it is an > end-station at the MAC layer. But it is also a forwarding > device. Hence the slack that might apply to a host receiving > a MAC frame with "stuff" in the header it doesn't understand, > shouldn't be allowed for a router. > > Also, many routers do understand that it is possible to > have the same IP subnet connected to multiple logical interfaces. > That was where the original "Bridging Router" (or BRouter) came > from. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > > Sent: Monday, April 02, 2007 4:10 PM > > To: Eric Gray (LO/EUS) > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > > why should we care? > > Importance: High > > > > My understanding is that shared VLANs assume > > IP routers are not aware of VLANs. > > > > My understanding is that the way it would work if the IP > > router R *was* > > aware of > > VLANs, is that R would treat the link as 4 separate links (by using > > VLANs), and then the IP addresses > > on the 4 different links (VLANs A, B, C, and D) would have to have > > different IP prefixes. > > > > So therefore, I am assuming that the IP router is not > > supposed to know > > that the link is subdivided into VLANs. > > > > So my understanding of the problem in this case is: > > > > a) single IP address block shared by different communities > > b) desire to isolate these communities from layer 2 broadcast traffic > > from each other > > c) desire to share some services (like DHCP and IP routers), without > > those services being aware > > that the communities are separate > > > > As for my question about proxy ARP, to further add > > to the confusion -- some people are assuming the > > bridge/RBridge will be > > doing > > the proxy ARP, and some others are assuming the router is. > > > > And actually, after talking offline with Joel Halpern, I'll > > send another > > note with two different proposals > > (one just a cleanup of what I originally wrote, and the other a > > different approach) for solving > > that vaguely stated problem. > > > > Radia > > > > > > > > > > > > Eric Gray (LO/EUS) wrote: > > > > >Radia, > > > > > > Let me try to re-state your explanation to see if I understand > > >it... > > > > > > You believe that the problem that shared VLAN learning is used > > >to solve is conservation of IP addresses used in a single IP subnet, > > >and that it is necessary to use shared VLAN learning to keep routers > > >(in the subnet) from having to re-learn MAC+IP associations across a > > >set of VLANs in that same IP subnet, is that correct? > > > > > >Thanks! > > > > > >-- > > >Eric Gray > > >Principal Engineer > > >Ericsson > > > > > > > > > > > >>-----Original Message----- > > >>From: rbridge-bounces@postel.org > > >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > > >>Sent: Thursday, March 29, 2007 2:56 AM > > >>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 > > >> > > >> > > >> > > > > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l32Ko95d014229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 2 Apr 2007 13:50:10 -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 l32LFlv6017993; Mon, 2 Apr 2007 16:15:47 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 15:50:08 -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: Mon, 2 Apr 2007 15:50:05 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4611631C.4090500@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: Acd1YuiYodt7ZKrwTbi3mW4EO+zQMwABF5Aw References: <460B6304.3020507@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> <4611631C.4090500@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 02 Apr 2007 20:50:08.0624 (UTC) FILETIME=[7FE6F700:01C77568] 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 l32Ko95d014229 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: Mon, 02 Apr 2007 20:51:16 -0000 Status: RO Content-Length: 13361 Radia, There is an interesting problem that might arise out of a router receiving VLAN tagged frames without being aware that they are tagged. A router is a MAC termination point - i.e. - it is an end-station at the MAC layer. But it is also a forwarding device. Hence the slack that might apply to a host receiving a MAC frame with "stuff" in the header it doesn't understand, shouldn't be allowed for a router. Also, many routers do understand that it is possible to have the same IP subnet connected to multiple logical interfaces. That was where the original "Bridging Router" (or BRouter) came from. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Monday, April 02, 2007 4:10 PM > To: Eric Gray (LO/EUS) > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should we care? > Importance: High > > My understanding is that shared VLANs assume > IP routers are not aware of VLANs. > > My understanding is that the way it would work if the IP > router R *was* > aware of > VLANs, is that R would treat the link as 4 separate links (by using > VLANs), and then the IP addresses > on the 4 different links (VLANs A, B, C, and D) would have to have > different IP prefixes. > > So therefore, I am assuming that the IP router is not > supposed to know > that the link is subdivided into VLANs. > > So my understanding of the problem in this case is: > > a) single IP address block shared by different communities > b) desire to isolate these communities from layer 2 broadcast traffic > from each other > c) desire to share some services (like DHCP and IP routers), without > those services being aware > that the communities are separate > > As for my question about proxy ARP, to further add > to the confusion -- some people are assuming the > bridge/RBridge will be > doing > the proxy ARP, and some others are assuming the router is. > > And actually, after talking offline with Joel Halpern, I'll > send another > note with two different proposals > (one just a cleanup of what I originally wrote, and the other a > different approach) for solving > that vaguely stated problem. > > Radia > > > > > > Eric Gray (LO/EUS) wrote: > > >Radia, > > > > Let me try to re-state your explanation to see if I understand > >it... > > > > You believe that the problem that shared VLAN learning is used > >to solve is conservation of IP addresses used in a single IP subnet, > >and that it is necessary to use shared VLAN learning to keep routers > >(in the subnet) from having to re-learn MAC+IP associations across a > >set of VLANs in that same IP subnet, is that correct? > > > >Thanks! > > > >-- > >Eric Gray > >Principal Engineer > >Ericsson > > > > > > > >>-----Original Message----- > >>From: rbridge-bounces@postel.org > >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > >>Sent: Thursday, March 29, 2007 2:56 AM > >>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 mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l32KBBwQ003820 for <rbridge@postel.org>; Mon, 2 Apr 2007 13:11:11 -0700 (PDT) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 02 Apr 2007 13:11:06 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 07C532AF; Mon, 2 Apr 2007 13:11:06 -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 E70A92AE; Mon, 2 Apr 2007 13:11:05 -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 FDK12957; Mon, 2 Apr 2007 13:11:05 -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 875AA69CA3; Mon, 2 Apr 2007 13:11:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Apr 2007 13:11:05 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA688@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acdx0OK13S62YKj/Tf+ogH260nq4ZQDh971gAAGwXBA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A0FBCD03A411671895-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 l32KBBwQ003820 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: Mon, 02 Apr 2007 20:11:34 -0000 Status: RO Content-Length: 3770 Eric Gray wrote: > Radia, > > Let me try to re-state your explanation to see if I understand it... > > You believe that the problem that shared VLAN learning > is used to solve is conservation of IP addresses used in a > single IP subnet, and that it is necessary to use shared VLAN > learning to keep routers (in the subnet) from having to > re-learn MAC+IP associations across a set of VLANs in that > same IP subnet, is that correct? > It's a more fundamental problem that re-learning, and the goal could more properly be stated as avoiding the neccesity of creating distinct subnets. Sharing the IP subnet does conserve IP Addresses, but more importantly it conserves the effort of dividing the IP addresses up into VLAN specific portions, and of updating DNS entries when a host migrates to a new VLAN, etc. There was actually a very good summary of the usage of such a feature on a BSD list in 2005: http://lists.freebsd.org/pipermail/freebsd-net/2005-November/009064.html Different switches having different VID/FID mappings is confusing, but ultimately it isn't that bad, especially since global MAC addresses do tend to be unique within a campus even when they are being assigned by decidedly non-global techniques. But the associated ARP Proxy has a totally different problem. Specifically, the scenario is where the *same* IP subnet is used for two or more VLANs. Or to be more precise, what is to *appear* to be one IP subnet to the outside world is actually two or more VLAN divided subnets, and the assignment of specific IP addresses to specific VLANs is dynamically learned rather than administered. So if RBridges scope the MAC/IP learning to a VID specific instance then two RBridges can have contradictory information about the meaning of an IP address. In fact, a single RBridge could have contradictory information in two VID-specific instances about the same IP address. This creates a severe problem for the router (existing router, mind you) that is the ingress point to this shared IP subnet. When it has a received IP datagram to x.y.z.1, and no entry in its ARP table, it will have no idea which VLAN the datagram belongs to. Therefore it will ARP on all VLANs to see where it goes, and it expects to get at most one reply because an IP address is only supposed to be assigned to a single host. Not that the router will get upset or have a fault. It will more likely assume to all replies are redundant and therefore it can always just use the most recent one without bothering to remember any prior ARP responses. So, when a host migrates from VLAN A to VLAN B, we have a problem if the RBridge on VLAN B does not share its discovery with the RBridge on VLAN A (and the two are part of a group / share the same IP subnet). If the discovery is shared, then the RBridge on VLAN A will delete its entry for the IP address, and when the Router next ARPs it will only get a response from VLAN B. So while the groups that Radia describes will solve the problem, the fundamental justification for the solution arises when the semantics of an IP subnet span multiple VIDs. When the IP Address retained for Proxy ARP purposes has a wider scope that the VLAN dissemination of discovery cannot be confined to the VLAN. And while I could see actually making the determination based on IP Addressing, I don't see any real advantage to doing so. While we've been refining the examples, the underlying problem remains as originally stated. Since RBridges provide a distributed Proxy ARP service they simply must avoid having contradictory information held by different RBridges (they can and should have different subsets of the entire picutre, but no RBridge should ever have data that contradicts the data that other RBridgess have). 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 l32K9pqs003160 for <rbridge@postel.org>; Mon, 2 Apr 2007 13:09:51 -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 <0JFW00N1N00C0U00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 02 Apr 2007 13:09:48 -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 <0JFW00B4V00BS000@mail.sunlabs.com> for rbridge@postel.org; Mon, 02 Apr 2007 13:09:48 -0700 (PDT) Date: Mon, 02 Apr 2007 13:10:04 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> To: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com> Message-id: <4611631C.4090500@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> <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com 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: Mon, 02 Apr 2007 20:10:19 -0000 Status: RO Content-Length: 11669 My understanding is that shared VLANs assume IP routers are not aware of VLANs. My understanding is that the way it would work if the IP router R *was* aware of VLANs, is that R would treat the link as 4 separate links (by using VLANs), and then the IP addresses on the 4 different links (VLANs A, B, C, and D) would have to have different IP prefixes. So therefore, I am assuming that the IP router is not supposed to know that the link is subdivided into VLANs. So my understanding of the problem in this case is: a) single IP address block shared by different communities b) desire to isolate these communities from layer 2 broadcast traffic from each other c) desire to share some services (like DHCP and IP routers), without those services being aware that the communities are separate As for my question about proxy ARP, to further add to the confusion -- some people are assuming the bridge/RBridge will be doing the proxy ARP, and some others are assuming the router is. And actually, after talking offline with Joel Halpern, I'll send another note with two different proposals (one just a cleanup of what I originally wrote, and the other a different approach) for solving that vaguely stated problem. Radia Eric Gray (LO/EUS) wrote: >Radia, > > Let me try to re-state your explanation to see if I understand >it... > > You believe that the problem that shared VLAN learning is used >to solve is conservation of IP addresses used in a single IP subnet, >and that it is necessary to use shared VLAN learning to keep routers >(in the subnet) from having to re-learn MAC+IP associations across a >set of VLANs in that same IP subnet, is that correct? > >Thanks! > >-- >Eric Gray >Principal Engineer >Ericsson > > > >>-----Original Message----- >>From: rbridge-bounces@postel.org >>[mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman >>Sent: Thursday, March 29, 2007 2:56 AM >>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 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 l32JG2cX017990 for <rbridge@postel.org>; Mon, 2 Apr 2007 12:16:02 -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, 2 Apr 2007 12:15:49 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014675DA@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BA613@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: Acd0K7qDxX57XYx3QO+st/05415O8ABJymWwAAH8tQA= References: <460F590E.5010207@sun.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BA613@NT-IRVA-0750.brcm.ad.broadcom.com> From: "J. R. Rivers" <jrrivers@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: jrrivers@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l32JG2cX017990 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: Mon, 02 Apr 2007 19:16:47 -0000 Status: RO Content-Length: 1880 More importantly is that sometimes R does reply to local ARPs and sometimes it doesn't... as part of system vendor feature definitions. Generally, I've always thought of ARP as a router/host function. As the lines blur between routers and switches, there have been many features introduced into "switches" based on router functionality. I'd argue that this is one great reason to leave ARP out of TRILL so that any of these extensions can continue to work based on their expectations of the underlying L2 network. JR > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler > Sent: Monday, April 02, 2007 11:21 AM > To: Radia Perlman > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should we care? > > Radia Perlman wrote: > > > > > My question was -- how does R know *not* to respond to the > > ARP? Or does sometimes R wind up forwarding between endnodes > > in the same VLAN unnecessarily and we don't care because it's > > not *incorrect*, it's just suboptimal? > > > > I'm not sure what the relevant specs are, but my understanding > has always been that a Proxy ARP only answers an ARP request > if it is somehow between the requester and the machine it > is proxying for. > > My direct experience with this all relates to Cable Modems, > so I haven't thought about corner cases where the "between" > status might not be blatantly obvious. And in that case > flooding irrelevant packets from every home network upstream > was not "suboptimal", it would have been a network killer. > So luckily the distinction between the home network and > the cable network was easily made. > > > > > _______________________________________________ > 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 l32J5e4R014576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 2 Apr 2007 12:05:40 -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 l32J5Zpo025918; Mon, 2 Apr 2007 14:05:35 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 14:05:35 -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: Mon, 2 Apr 2007 14:05:30 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> 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: Acdx0OK13S62YKj/Tf+ogH260nq4ZQDh971g References: <460B6304.3020507@sun.com> From: "Eric Gray \(LO/EUS\)" <eric.gray@ericsson.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 02 Apr 2007 19:05:35.0490 (UTC) FILETIME=[E4D2AE20:01C77559] 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 l32J5e4R014576 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: Mon, 02 Apr 2007 19:06:10 -0000 Status: RO Content-Length: 10370 Radia, Let me try to re-state your explanation to see if I understand it... You believe that the problem that shared VLAN learning is used to solve is conservation of IP addresses used in a single IP subnet, and that it is necessary to use shared VLAN learning to keep routers (in the subnet) from having to re-learn MAC+IP associations across a set of VLANs in that same IP subnet, is that correct? Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > Sent: Thursday, March 29, 2007 2:56 AM > 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 mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l32ILtQQ000142 for <rbridge@postel.org>; Mon, 2 Apr 2007 11:21:55 -0700 (PDT) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 02 Apr 2007 11:21:39 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A656A2B9; Mon, 2 Apr 2007 11:21:38 -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 3F8B42B2; Mon, 2 Apr 2007 11:21:37 -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 FDJ86058; Mon, 2 Apr 2007 11:21:30 -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 A867069CA4; Mon, 2 Apr 2007 11:21:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Apr 2007 11:21:28 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA613@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <460F590E.5010207@sun.com> Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care? Thread-Index: Acd0K7qDxX57XYx3QO+st/05415O8ABJymWw From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 6A0F963937011720029-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 l32ILtQQ000142 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: Mon, 02 Apr 2007 18:22:02 -0000 Status: RO Content-Length: 850 Radia Perlman wrote: > > My question was -- how does R know *not* to respond to the > ARP? Or does sometimes R wind up forwarding between endnodes > in the same VLAN unnecessarily and we don't care because it's > not *incorrect*, it's just suboptimal? > I'm not sure what the relevant specs are, but my understanding has always been that a Proxy ARP only answers an ARP request if it is somehow between the requester and the machine it is proxying for. My direct experience with this all relates to Cable Modems, so I haven't thought about corner cases where the "between" status might not be blatantly obvious. And in that case flooding irrelevant packets from every home network upstream was not "suboptimal", it would have been a network killer. So luckily the distinction between the home network and the cable network was easily made. Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l31NsJb4017114 for <rbridge@postel.org>; Sun, 1 Apr 2007 16:54:19 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2007 16:54:20 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l31NsIO0021262; Sun, 1 Apr 2007 16:54:18 -0700 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 l31NsAAA029387; Sun, 1 Apr 2007 23:54:10 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); Sun, 1 Apr 2007 16:54:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Apr 2007 16:54:08 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D8702C763D1@xmb-sjc-213.amer.cisco.com> In-Reply-To: <460F590E.5010207@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: Acd0K7ZxRAwkz/K3TYqAri0m6RoDOgAivI4g From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-OriginalArrivalTime: 01 Apr 2007 23:54:10.0142 (UTC) FILETIME=[0ABF27E0:01C774B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4404; t=1175471658; x=1176335658; c=relaxed/simple; s=sjdkim7002; 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=7yI9TwwA7q1A3mp5WNvnpXULCSmqzYi0bRt57Nk8Jf8=; b=C9HJw/irQ+B49xWCk2SZa1+nKPs9BjQuxXL8tkOawWgaTZ0dt7U+BKytvj/b8IrrO4SqW/57 rdONpXPTdUPHLDlqwMbu+nOyc8zbe1evzImESyt13zws+YpCaA9CoWKa; Authentication-Results: sj-dkim-7; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 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 l31NsJb4017114 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 23:54:34 -0000 Status: RO Content-Length: 4245 Yep, there are cases of such sub-optimal routing with private vlan. Host can sometimes receive 2 arp responses, and then there is a chance of host caching the arp response from the router. In private vlan, there are isolated secondary vlans and community secondary vlans. Any port with isolated secondary vlan cannot tal to any other port with same isolated secondary vlan. However, ports within the same community secondary vlan can talk to each other. Of course, in addition, these ports can talk to port of primary vlan (typically going towards the router). So, in case ip-A1 and ip-A2 are sitting behind community vlans, hosts may receive 2 arp responses. -Sanjay -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@sun.com] Sent: Sunday, April 01, 2007 12:03 AM To: Caitlin Bestler Cc: Sanjay Sane (sanjays); rbridge@postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? Argh! I'm really confused. We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D), it would be forwarded by the IP router R. And that the RBridge is not doing this. Though someone could build a project that was a combined router/RBridge. But Sanjay -- I think you misunderstood my question. So let me restate it. Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D, all in the same IP subnet. The router R is in VLAN Z. The VLAN grouping is {primary=Z, secondaries = A, B, C, D}. Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a secondary in the group goes to all links in *that* secondary, plus Z. Do we all understand and agree so far? So now my question. a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged with VLAN A. The RBridges forward it to all links in A, as well as Z (the VLAN tag of the primary in the group {Z, A, B, C, D}. R, with MAC address r, responds to the ARP with a reply saying "ip-D has MAC address r". So ip-A1 and ip-D talk through R. b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which is tagged with VLAN A. The RBridges forward it to all links in A as well as Z. But now both the real target, ip-A2, as well as the router R see the ARP. If R replies, then ip-A1 and ip-A2 will be talking through R. My question was -- how does R know *not* to respond to the ARP? Or does sometimes R wind up forwarding between endnodes in the same VLAN unnecessarily and we don't care because it's not *incorrect*, it's just suboptimal? Even if R sees an ARP reply from ip-A2, I don't think R can tell what VLAN ip-A2 is in. Because the packet, once it gets to R, either doesn't have a VLAN tag on it, or the VLAN tag says Z. So...I'd really like to understand this... Radia Caitlin Bestler wrote: >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 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 l31FqmbX027679 for <rbridge@postel.org>; Sun, 1 Apr 2007 08:52:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Apr 2007 08:52:37 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014673AC@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014673A8@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning:What is it and why should wecare?) thread-index: Acd0LldevXL22S7KRS+Li2vwU49KLQAPh44gAAIwoIA= References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com><460F53B1.6080103@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2014673A8@nuova-ex1.hq.nuovaimpresa.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Russ White" <riw@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 l31FqmbX027679 Cc: rbridge@postel.org Subject: Re: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning:What is it and why should wecare?) 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 15:54:17 -0000 Status: RO Content-Length: 6577 I said it wrong, sorry, retrying: "It is not possible to configure an RBridge to NOT act as a transit node for a particular VLAN". In other words: "an RBridge that does not have any port/node in VLAN A MUST act as a transit for VLAN A if other RBridges require so". This is different from IEEE 802.1Q in which you can decide which switch act as transit for which VLAN. There is only one topology in RBridges, i.e. the core topology. In Spanning Tree potentially there are many active topologies. In RBridge the per VLAN instance only acts as "VLAN Pruning". -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Silvano Gai > Sent: Sunday, April 01, 2007 7:54 AM > To: Radia Perlman; Russ White > Cc: rbridge@postel.org > Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN > learning:What is it and why should wecare?) > > > I changed the subject because I want us to clarify one of the > confusions: > > "It is not possible to configure an RBridge to act as a transit node for > a particular VLAN". > > In other words: "an RBridge that does not have any port/node in VLAN A > MUST act as a transit for VLAN A if other RBridges require so". > > This is different from IEEE 802.1Q in which you can decide which switch > act as transit for which VLAN. > > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Radia Perlman > > Sent: Saturday, March 31, 2007 11:40 PM > > To: Russ White > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > > wecare? > > > > 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----- > > > > > > > > > > _______________________________________________ > > 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 l31F7kuo017107 for <rbridge@postel.org>; Sun, 1 Apr 2007 08:07: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: Sun, 1 Apr 2007 08:07:37 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014673A9@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <460F53B1.6080103@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Other reason for Confusion (RE: [rbridge] Shared VLAN learning: What is it and why should wecare?) thread-index: Acd0LldevXL22S7KRS+Li2vwU49KLQAP0CEg References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com> <460F53B1.6080103@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Russ White" <riw@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 l31F7kuo017107 Cc: rbridge@postel.org Subject: [rbridge] Other reason for Confusion (RE: Shared VLAN learning: What is it and why should wecare?) 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 15:08:27 -0000 Status: RO Content-Length: 5419 The other reason for confusion is that SVL exists also without Private VLANs. IVL and SVL are internal switch operation mode. Se IEEE 802.1Q-2005 Section 7.4 and the begging of Appendix B. IMHO they don't pose any particular requirement on the IP routers. Each VLAN maps to a router sub-interface, that maps to an IP subnet. SVL is used by Private VLANs, but there is much more to Private VLANs that just SVL. IEEE 802.1Q has the similar concept of Asymmetric VLANs, see EEE 802.1Q-2005 B.1.3 Asymmetric VLANs. In future posting, please clarify if what you are stating applies in general to SVL or it is specific of Private VLANs. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Saturday, March 31, 2007 11:40 PM > To: Russ White > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > 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----- > > > > > > _______________________________________________ > 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 l31ErvEV013708 for <rbridge@postel.org>; Sun, 1 Apr 2007 07:53:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Apr 2007 07:53:47 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014673A8@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <460F53B1.6080103@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Disable transit for a VLAN was (RE: [rbridge] Shared VLAN learning: What is it and why should wecare?) thread-index: Acd0LldevXL22S7KRS+Li2vwU49KLQAPh44g References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com> <460F53B1.6080103@sun.com> From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Russ White" <riw@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 l31ErvEV013708 Cc: rbridge@postel.org Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning: What is it and why should wecare?) 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 14:54:21 -0000 Status: RO Content-Length: 5194 I changed the subject because I want us to clarify one of the confusions: "It is not possible to configure an RBridge to act as a transit node for a particular VLAN". In other words: "an RBridge that does not have any port/node in VLAN A MUST act as a transit for VLAN A if other RBridges require so". This is different from IEEE 802.1Q in which you can decide which switch act as transit for which VLAN. -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Saturday, March 31, 2007 11:40 PM > To: Russ White > Cc: rbridge@postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > 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----- > > > > > > _______________________________________________ > 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 l3172Ohm005279 for <rbridge@postel.org>; Sun, 1 Apr 2007 00:02:24 -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 <0JFT00JBX4W0Z900@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sun, 01 Apr 2007 00:02:24 -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 <0JFT008844VXJ700@mail.sunlabs.com> for rbridge@postel.org; Sun, 01 Apr 2007 00:02:22 -0700 (PDT) Date: Sun, 01 Apr 2007 00:02:38 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <460F590E.5010207@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: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@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] 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 07:02:33 -0000 Status: RO Content-Length: 3309 Argh! I'm really confused. We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D), it would be forwarded by the IP router R. And that the RBridge is not doing this. Though someone could build a project that was a combined router/RBridge. But Sanjay -- I think you misunderstood my question. So let me restate it. Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D, all in the same IP subnet. The router R is in VLAN Z. The VLAN grouping is {primary=Z, secondaries = A, B, C, D}. Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a secondary in the group goes to all links in *that* secondary, plus Z. Do we all understand and agree so far? So now my question. a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged with VLAN A. The RBridges forward it to all links in A, as well as Z (the VLAN tag of the primary in the group {Z, A, B, C, D}. R, with MAC address r, responds to the ARP with a reply saying "ip-D has MAC address r". So ip-A1 and ip-D talk through R. b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which is tagged with VLAN A. The RBridges forward it to all links in A as well as Z. But now both the real target, ip-A2, as well as the router R see the ARP. If R replies, then ip-A1 and ip-A2 will be talking through R. My question was -- how does R know *not* to respond to the ARP? Or does sometimes R wind up forwarding between endnodes in the same VLAN unnecessarily and we don't care because it's not *incorrect*, it's just suboptimal? Even if R sees an ARP reply from ip-A2, I don't think R can tell what VLAN ip-A2 is in. Because the packet, once it gets to R, either doesn't have a VLAN tag on it, or the VLAN tag says Z. So...I'd really like to understand this... Radia Caitlin Bestler wrote: >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. > > > >
- [rbridge] TRILL Header Format Silvano Gai
- [rbridge] TRILL Header Format Dinesh G Dutt
- [rbridge] TRILL Header Format Silvano Gai
- [rbridge] TRILL Header Format Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format - Version 2 Silvano Gai
- [rbridge] TRILL Header Format - Version 2 Caitlin Bestler
- [rbridge] TRILL Header Format Joe Touch
- [rbridge] TRILL Header Format Silvano Gai
- [rbridge] TRILL Header Format Joe Touch
- [rbridge] TRILL Header Format Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format - Version 2 Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format Joe Touch
- [rbridge] TRILL Header Format - Version 2 Joe Touch
- [rbridge] TRILL Header Format Eric Gray LO/EUS
- [rbridge] TRILL Header Format - Version 2 Eric Gray LO/EUS
- [rbridge] TRILL Header Format Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format Eric Gray LO/EUS
- [rbridge] TRILL Header Format Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format - Version 2 Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format Joe Touch
- [rbridge] TRILL Header Format Silvano Gai
- [rbridge] TRILL Header Format Eastlake III Donald-LDE008
- [rbridge] TRILL Header Format Joe Touch
- [rbridge] TRILL Header Format J. R. Rivers
- [rbridge] TRILL Header Format Eastlake III Donald-LDE008