From l2vpn-bounces@ietf.org Mon Jan 3 04:41:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09957 for ; Mon, 3 Jan 2005 04:41:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClOu7-0007oT-PS for l2vpn-web-archive@ietf.org; Mon, 03 Jan 2005 04:53:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClOY7-0001gw-Pd; Mon, 03 Jan 2005 04:30:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClOUF-0000ba-4H for l2vpn@megatron.ietf.org; Mon, 03 Jan 2005 04:26:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09017 for ; Mon, 3 Jan 2005 04:26:49 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClOgF-0007YU-PV for l2vpn@ietf.org; Mon, 03 Jan 2005 04:39:23 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9Q00K40I75ML@szxga01-in.huawei.com> for l2vpn@ietf.org; Mon, 03 Jan 2005 17:25:53 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9Q0028AI75D9@szxga01-in.huawei.com> for l2vpn@ietf.org; Mon, 03 Jan 2005 17:25:53 +0800 (CST) Received: from h22280B ([10.110.49.238]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0I9Q00K5BI7VZ3@szxml02-in.huawei.com>; Mon, 03 Jan 2005 17:26:19 +0800 (CST) Date: Mon, 03 Jan 2005 17:27:24 +0800 From: Huke Hu Chun Zhe To: Mustapha Aissaoui , l2vpn@ietf.org Message-id: <012b01c4f176$6f297780$ee316e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4188F023.BF4346C2@alcatel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7BIT Subject: Two issues regarding BGP VPLS X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7BIT Dear All, regarding draft " draft-ietf-l2vpn-vpls-bgp-02 " there are two issues : Issue 1: Problem description in Multi Homing What is multi homing? Multi-home a VPLS site is to connect it to multiple PEs, perhaps even in different ASes. In the case where the PEs connected to the same site are assigned the same VE ID, a loop-free topology is constructed by routing mechanisms, in particular, by BGP path selection. When a BGP speaker receives two equivalent NLRIs, it applies standard path selection criteria such as Local Preference and AS Path Length to determine which NLRI to choose; it MUST pick only one. If the chosen NLRI is subsequently withdrawn, the BGP speaker applies path selection to the remaining equivalent VPLS NLRIs to pick another; if none remain, the forwarding information associated with that NLRI is removed. Two VPLS NLRIs are considered equivalent from a path selection point of view if the Route Distinguisher, the VE ID and the VE Block Offset are the same. If two PE are assigned the same VE ID in a given VPLS, they MUST use the same Route Distinguisher, and they MUST announce the same VE Block Size for a given VE Offset. Problem VSI configured at PE1 and PE2 with same RD, site ID and offset, like: ce1-------------------------pe1--------------------------pe3------ce2 |------------------------pe2---------------------------| In this scenario CE1 is connected to 2 different PE and thus is multi-homed. PE1 and PE2 both advertise the NLRIs, in PE3 BGP received 2 set of label blocks from PE1 and PE2 and PE3 in turn must have broadcast his NLRI to both PE1 and PE2. BGP here runs the best route selection algorithm and say select the label block from PE2 as best and thus notify this label block to VPLS VSI. A PW is thus formed between PE2 and PE3. In this whole time PE1 does not know that his label block has not been selected in the best route selection and thus unaware of the fact that VSI PE3 does not even know that PE1 exist. PE1 form a PW because he has received a reach NLRI from PE3; downloads and make VSI state up. PE1 and PE2 both think they have a PW to PE3. PE3 has PW only to PE2 and does not even know about the existence of PE1. Use of Un-Reach NLRI cannot solve the problem as BGP is broadcast and we cannot send UN Reach to only one BGP peer. Adding CSV bits as well may not solve it. This is an open issue with the multi homing based on draft - draft-ietf-l2vpn-vpls-bgp-02. One Alternative means may use same mechanism in BGP VPLS address family to send VSI status thru new BGP message like LDP notification MSG to notify VC status. Please give your valuable comments regarding this. Issue 2: CSV problem VPLS Phase - II Tunnel Handling proposal for BGP Current Design The sending of Reach and Un Reach NLRI is based only on the availability of the AC. The availability of tunnel is not taken into consideration. The PW status is based on the tunnel. So a case when the tunnel goes down at a PE, we would make the PW down and download accordingly but cannot send UN Reach or any other notification to the peers and thus the state of PW in remote side would be UP. The reason for enable to send UN Reach NLRI is that BGP label block is advertised to all the BGP peers we do not have separate notification to a corresponding peer. Thus UN Reach cannot be send when tunnel to a particular BGP peer goes down. So we end up having a condition such that at one peer PW state down and other UP when tunnel up / down happens. Proposal In case of L2VPN we had CSV bits. These bits denoted weather a particular connection local state is up or down which was based on the interface and tunnel state. Based on the draft-ietf-l2vpn-vpls-bgp-02 the NLRI for VPLS do not have any CSV bits. We can use CSV in VPLS to denote the state of tunnel. Since CSV is not a part of draft we may add a CLI to distinguish weather we should use it or not. We can allow PW establishment even when CSV bits are not part of Reach NLRI. Proposed design is such that when site ID is configured we set the all CSV bits as 0 indicating the local state is UP. In this case initially we receive all the remote label blocks and discover the peers in the VPLS. When we try to form a PW we search for a tunnel to the remote peer, if tunnel exist we continue our processing normal. If tunnel does not exist we create PW but the state of PW is down at this moment we send Reach NLRI again with CSV bit unset (1) for this particular peer. On receiving of Reach NLRI we check the CSV bits now the CSV bits indicate the remote state of the PW; if the remote state is 1; we make the PW state down. When tunnel available we again send a reach NLRI with bit as 0 and on receiving the NLRI we can make the PW state up as local and remote state depending on the tunnel is available. +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | VE Block Offset (2 octets) | +------------------------------------+ | VE Block Size (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ | Variable TLVs (0 to N octets) | | ... | +------------------------------------+ Circuit Status Vector A new sub-TLV is introduced to carry the status of a VPLS PW between a pair of PEs. A PE should monitor the status of the tunnel towards the remote PE; it can inform the remote PE about tunnel events. Similarly, the remote PE can inform the status of its tunnel to the first PE. Combining the local and the remote information, a PE can determine the status of a PW. The basic unit of advertisement in VPLS for a given PE is a label-block. Each label within a label-block corresponds to a PW on the Site. So we can advertise the local status information (i.e. the tunnel information) for all PWs corresponding to a label-block along with the label-block's NLRI. This can be done by introducing the circuit status vector TLV. The value field of this TLV is a bit-vector, each bit of which indicates the status of the PW associated with the corresponding label in the label-block. Bit value 0 indicates that the tunnel to the remote PE is up, while a value of 1 indicates that tunnel is down. PE A, while selecting a label from a label-block (advertised by PE B, for remote Site m, and VPLS X) for its local Site n (in VPLS X) can also determine the status of the corresponding PW (between Site n and Site m) by looking at the appropriate bit in the circuit status vector. The length field of the TLV specifies the length of the value field in bits. The value field is padded to the nearest octet boundary. Thank you. Huke. From l2vpn-bounces@ietf.org Tue Jan 4 01:20:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29429 for ; Tue, 4 Jan 2005 01:20:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CliFw-0005UQ-QK for l2vpn-web-archive@ietf.org; Tue, 04 Jan 2005 01:33:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cli0m-00072p-Ul; Tue, 04 Jan 2005 01:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClhwO-00057J-Tc for l2vpn@megatron.ietf.org; Tue, 04 Jan 2005 01:13:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28856 for ; Tue, 4 Jan 2005 01:13:12 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cli8X-0005JO-OT for l2vpn@ietf.org; Tue, 04 Jan 2005 01:25:56 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9S00DFG3WYXW@szxga01-in.huawei.com> for l2vpn@ietf.org; Tue, 04 Jan 2005 14:12:35 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9S00EWT3WYVC@szxga01-in.huawei.com> for l2vpn@ietf.org; Tue, 04 Jan 2005 14:12:34 +0800 (CST) Received: from h22280B ([10.110.49.238]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0I9S0042O4236D@szxml01-in.huawei.com>; Tue, 04 Jan 2005 14:15:39 +0800 (CST) Date: Tue, 04 Jan 2005 14:14:06 +0800 From: Huke Hu Chun Zhe To: Hector Avalos Message-id: <001401c4f224$98c72930$ee316e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: 7BIT Cc: l2vpn@ietf.org Subject: Re: L2vpn Digest, Vol 9, Issue 1 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Content-Transfer-Encoding: 7BIT Dear Hector, Thanks for your reply but I still think we face the same problem. Case I: Where there exist BGP session between PE1 and PE2. PE1 may receive a NLRI from PE2 with the same VE-ID, this would only tell PE1 that PE2 is multi-homed that is it has a same RD and VE-ID. The best route selection would run at PE3 and he would select one of the PEs PE1 or PE2. What is the best route at PE3 cannot be informed at PE1 and PE2. Also please note that according to L2VPN Kompella we should reject the NLRI if the remote CE-ID matches with the local CE-ID. Case II: Where there exist no (VPLS enabled) BGP session between PE1 and PE2 Multi-homing should work in this scenario as well. As far as forwarding is concerned, since PE1 and PE2 are un-aware of the best route and both have received a NLRI from PE3, both would form a Pseudo-wire and make the VSI status up and download the forwarding entries. At PE3, since BGP notifies only the best route PW exists only for one of the PEs. Forwarding at PE1 which is not the best route would continue; he would send traffic to PE3 continuously. The same would be dropt at PE3 though because no entries exist for the same. PE1 would not be aware of this situation at any time. Thank You, Huchunzhe / Dhruv ----- Original Message ----- From: "Hector Avalos" To: Sent: Tuesday, January 04, 2005 1:43 AM Subject: RE: L2vpn Digest, Vol 9, Issue 1 Hi, Regarding the issue number 1 that you mention, you need to consider that PE1 will also get PE2 NLRI advertisement. It will do std BGP path selection and will know that he is not the 'active' PE for CE1. PE1 can set up a PW with PE3, but it will not forward any traffic to it (and any other PE for the same VPLS domain). PE3 will have both PE1 and PE2 NLRI but only one being active. When PE2 NLRI is withdrawn, PE3 does path selection and uses PE1 LNRI. cheers, Hector -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: 03 January 2005 18:15 To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 9, Issue 1 Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Two issues regarding BGP VPLS (Huke Hu Chun Zhe) ---------------------------------------------------------------------- Message: 1 Date: Mon, 03 Jan 2005 17:27:24 +0800 From: Huke Hu Chun Zhe Subject: Two issues regarding BGP VPLS To: Mustapha Aissaoui , l2vpn@ietf.org Message-ID: <012b01c4f176$6f297780$ee316e0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-1 Dear All, regarding draft " draft-ietf-l2vpn-vpls-bgp-02 " there are two issues : Issue 1: Problem description in Multi Homing What is multi homing? Multi-home a VPLS site is to connect it to multiple PEs, perhaps even in different ASes. In the case where the PEs connected to the same site are assigned the same VE ID, a loop-free topology is constructed by routing mechanisms, in particular, by BGP path selection. When a BGP speaker receives two equivalent NLRIs, it applies standard path selection criteria such as Local Preference and AS Path Length to determine which NLRI to choose; it MUST pick only one. If the chosen NLRI is subsequently withdrawn, the BGP speaker applies path selection to the remaining equivalent VPLS NLRIs to pick another; if none remain, the forwarding information associated with that NLRI is removed. Two VPLS NLRIs are considered equivalent from a path selection point of view if the Route Distinguisher, the VE ID and the VE Block Offset are the same. If two PE are assigned the same VE ID in a given VPLS, they MUST use the same Route Distinguisher, and they MUST announce the same VE Block Size for a given VE Offset. Problem VSI configured at PE1 and PE2 with same RD, site ID and offset, like: ce1-------------------------pe1--------------------------pe3------ce2 |------------------------pe2---------------------------| In this scenario CE1 is connected to 2 different PE and thus is multi-homed. PE1 and PE2 both advertise the NLRIs, in PE3 BGP received 2 set of label blocks from PE1 and PE2 and PE3 in turn must have broadcast his NLRI to both PE1 and PE2. BGP here runs the best route selection algorithm and say select the label block from PE2 as best and thus notify this label block to VPLS VSI. A PW is thus formed between PE2 and PE3. In this whole time PE1 does not know that his label block has not been selected in the best route selection and thus unaware of the fact that VSI PE3 does not even know that PE1 exist. PE1 form a PW because he has received a reach NLRI from PE3; downloads and make VSI state up. PE1 and PE2 both think they have a PW to PE3. PE3 has PW only to PE2 and does not even know about the existence of PE1. Use of Un-Reach NLRI cannot solve the problem as BGP is broadcast and we cannot send UN Reach to only one BGP peer. Adding CSV bits as well may not solve it. This is an open issue with the multi homing based on draft - draft-ietf-l2vpn-vpls-bgp-02. One Alternative means may use same mechanism in BGP VPLS address family to send VSI status thru new BGP message like LDP notification MSG to notify VC status. Please give your valuable comments regarding this. Issue 2: CSV problem VPLS Phase - II Tunnel Handling proposal for BGP Current Design The sending of Reach and Un Reach NLRI is based only on the availability of the AC. The availability of tunnel is not taken into consideration. The PW status is based on the tunnel. So a case when the tunnel goes down at a PE, we would make the PW down and download accordingly but cannot send UN Reach or any other notification to the peers and thus the state of PW in remote side would be UP. The reason for enable to send UN Reach NLRI is that BGP label block is advertised to all the BGP peers we do not have separate notification to a corresponding peer. Thus UN Reach cannot be send when tunnel to a particular BGP peer goes down. So we end up having a condition such that at one peer PW state down and other UP when tunnel up / down happens. Proposal In case of L2VPN we had CSV bits. These bits denoted weather a particular connection local state is up or down which was based on the interface and tunnel state. Based on the draft-ietf-l2vpn-vpls-bgp-02 the NLRI for VPLS do not have any CSV bits. We can use CSV in VPLS to denote the state of tunnel. Since CSV is not a part of draft we may add a CLI to distinguish weather we should use it or not. We can allow PW establishment even when CSV bits are not part of Reach NLRI. Proposed design is such that when site ID is configured we set the all CSV bits as 0 indicating the local state is UP. In this case initially we receive all the remote label blocks and discover the peers in the VPLS. When we try to form a PW we search for a tunnel to the remote peer, if tunnel exist we continue our processing normal. If tunnel does not exist we create PW but the state of PW is down at this moment we send Reach NLRI again with CSV bit unset (1) for this particular peer. On receiving of Reach NLRI we check the CSV bits now the CSV bits indicate the remote state of the PW; if the remote state is 1; we make the PW state down. When tunnel available we again send a reach NLRI with bit as 0 and on receiving the NLRI we can make the PW state up as local and remote state depending on the tunnel is available. +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | VE Block Offset (2 octets) | +------------------------------------+ | VE Block Size (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ | Variable TLVs (0 to N octets) | | ... | +------------------------------------+ Circuit Status Vector A new sub-TLV is introduced to carry the status of a VPLS PW between a pair of PEs. A PE should monitor the status of the tunnel towards the remote PE; it can inform the remote PE about tunnel events. Similarly, the remote PE can inform the status of its tunnel to the first PE. Combining the local and the remote information, a PE can determine the status of a PW. The basic unit of advertisement in VPLS for a given PE is a label-block. Each label within a label-block corresponds to a PW on the Site. So we can advertise the local status information (i.e. the tunnel information) for all PWs corresponding to a label-block along with the label-block's NLRI. This can be done by introducing the circuit status vector TLV. The value field of this TLV is a bit-vector, each bit of which indicates the status of the PW associated with the corresponding label in the label-block. Bit value 0 indicates that the tunnel to the remote PE is up, while a value of 1 indicates that tunnel is down. PE A, while selecting a label from a label-block (advertised by PE B, for remote Site m, and VPLS X) for its local Site n (in VPLS X) can also determine the status of the corresponding PW (between Site n and Site m) by looking at the appropriate bit in the circuit status vector. The length field of the TLV specifies the length of the value field in bits. The value field is padded to the nearest octet boundary. Thank you. Huke. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www1.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 9, Issue 1 *********************************** From l2vpn-bounces@ietf.org Tue Jan 4 16:10:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20654 for ; Tue, 4 Jan 2005 16:10:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clw96-0008Af-CK for l2vpn-web-archive@ietf.org; Tue, 04 Jan 2005 16:23:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClvTt-00032f-RM; Tue, 04 Jan 2005 15:40:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClvLK-0005Gl-5O; Tue, 04 Jan 2005 15:31:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15850; Tue, 4 Jan 2005 15:31:48 -0500 (EST) Message-Id: <200501042031.PAA15850@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 04 Jan 2005 15:31:47 -0500 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-bgp-03.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Virtual Private LAN Service Author(s) : K. Kompella, et al. Filename : draft-ietf-l2vpn-vpls-bgp-03.txt Pages : 19 Date : 2005-1-4 Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 VPN; however, in the case of VPLS, the customers in the VPN are connected by a multipoint network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, and proposes a mechanism for signaling a VPLS, as well as for forwarding VPLS frames across a packet switched network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-bgp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-bgp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-4153204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-bgp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bgp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-4153204.I-D@ietf.org> --OtherAccess-- --NextPart-- From WSNFBBYEXNNGR@yahoo.com Wed Jan 5 06:35:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23836; Wed, 5 Jan 2005 06:35:04 -0500 (EST) Received: from roc-69-202-144-6.rochester.rr.com ([69.202.144.6]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cm9do-0001av-10; Wed, 05 Jan 2005 06:48:04 -0500 Received: from [20.80.106.212] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 675LFL-0048PT-89 Message-ID: <57920093144732.R37431@.noc..gr> Sender: freeradius-devel-WSNFBBYEXNNGR@yahoo.com X-Mailman-Version: 2.0.1 Date: Wed, 05 Jan 2005 16:25:12 +0500 From: "Marva Sullivan" To: l2tpext@ietf.org Subject: House of Viicodin L2tpext X-Spam-Score: 2.7 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year OzVERTwZZqrZNyVck0x1VibAZppyrp From l2vpn-bounces@ietf.org Wed Jan 5 12:50:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25549 for ; Wed, 5 Jan 2005 12:50:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFVV-0005aJ-Bu for l2vpn-web-archive@ietf.org; Wed, 05 Jan 2005 13:03:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFGd-00074N-Hx; Wed, 05 Jan 2005 12:48:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFDU-0006Rt-LJ for l2vpn@megatron.ietf.org; Wed, 05 Jan 2005 12:45:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25173 for ; Wed, 5 Jan 2005 12:45:01 -0500 (EST) Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFQ5-000589-Ol for l2vpn@ietf.org; Wed, 05 Jan 2005 12:58:07 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j05Hi3Xg046597; Wed, 5 Jan 2005 09:44:03 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j05Hi24k046594; Wed, 5 Jan 2005 09:44:02 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 5 Jan 2005 09:44:02 -0800 (PST) From: Kireeti Kompella To: Huke Hu Chun Zhe In-Reply-To: <012b01c4f176$6f297780$ee316e0a@china.huawei.com> Message-ID: <20050105085349.C46535@kummer.juniper.net> References: <4188F023.BF4346C2@alcatel.com> <012b01c4f176$6f297780$ee316e0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: l2vpn@ietf.org, Mustapha Aissaoui Subject: Re: Two issues regarding BGP VPLS X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi Huke, On Mon, 3 Jan 2005, Huke Hu Chun Zhe wrote: > Dear All, > regarding draft " draft-ietf-l2vpn-vpls-bgp-02 " > there are two issues : Thanks for your comments. > Issue 1: > > Problem description in Multi Homing > In this scenario CE1 is connected to 2 different PE and thus is > multi-homed. PE1 and PE2 both advertise the NLRIs, in PE3 BGP > received 2 set of label blocks from PE1 and PE2 and PE3 in turn must > have broadcast his NLRI to both PE1 and PE2. BGP here runs the best > route selection algorithm and say select the label block from PE2 as > best and thus notify this label block to VPLS VSI. A PW is thus > formed between PE2 and PE3. > > In this whole time PE1 does not know that his label block has not > been selected in the best route selection and thus unaware of the > fact that VSI PE3 does not even know that PE1 exist. PE1 form a PW > because he has received a reach NLRI from PE3; downloads and make > VSI state up. Actually, since iBGP requires (logical) full mesh connectivity in the control plane, PE1 will see PE2's NLRI. So, PE1 can know whether it wins the path selection or not, and based on that, can decide whether or not to establish PWs to other PEs. Similarly for PE2. Note that path selection for VPLS MUST yield the same result for all PEs (i.e., if PE1 and PE2 are dual-homed to site 1 in VPLS foo, all PEs in VPLS foo MUST pick the same PE to reach site 1.) I'll clarify this in the next version of the draft. > Issue 2: CSV problem > The sending of Reach and Un Reach NLRI is based only on the > availability of the AC. The availability of tunnel is not taken into > consideration. It is a requirement that PEs in a VPLS must be full-meshed in the data plane. Suppose PE1, PE2, PE5, PE7 and PE9 are in VPLS foo. In this case, there must be data connectivity among all these PEs, that is, tunnels and PWs. If even one tunnel goes down (say between PE1 and PE9), then either PE1 or PE9 must withdraw from the VPLS. This can be accomplished by having the head-end of the tunnel LSP withdraw its NLRI when it realizes that the tunnel is down. Hope that helps, Kireeti. ------- From ALHDMFZNYGJZY@hotmail.com Wed Jan 12 02:08:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22508; Wed, 12 Jan 2005 02:08:10 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cocpp-00058X-NB; Wed, 12 Jan 2005 02:22:35 -0500 Received: from pool-68-239-152-94.nwrk.east.verizon.net ([68.239.152.94]) by mx2.foretec.com with smtp (Exim 4.24) id 1CocbS-0002q9-5R; Wed, 12 Jan 2005 02:07:39 -0500 Received: from [240.89.192.134] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 911LFL-0084PT-65 Message-ID: <17949683144732.R37404@.noc..gr> Sender: freeradius-devel-ALHDMFZNYGJZY@hotmail.com X-Mailman-Version: 2.0.1 Date: Wed, 12 Jan 2005 10:07:01 +0300 From: "Deirdre Broussard" To: l2vpn-admin@ietf.org Cc: l2vpn-web-archive@ietf.org, l3vpn@ietf.org, l3vpn-admin@ietf.org, l3vpn-web-archive@ietf.org, ldap-dir@ietf.org, ldap-dir-admin@ietf.org, ldap-dir-web-archive@ietf.org, ldapext@ietf.org, ldapext-admin@ietf.org, ldapext-archive@ietf.org, lemonade@ietf.org Subject: Everyone Need This L2vpn-admin X-Spam-Score: 3.5 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year HlBZQ8uT8Apuv0MjdtmQmWLdCficdiIqVJEPywSQgT6b From l2vpn-bounces@ietf.org Wed Jan 12 02:27:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12615 for ; Wed, 12 Jan 2005 02:27:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cod8f-0005gl-PY for l2vpn-web-archive@ietf.org; Wed, 12 Jan 2005 02:41:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CocqP-000523-5i; Wed, 12 Jan 2005 02:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CocoM-00045S-59 for l2vpn@megatron.ietf.org; Wed, 12 Jan 2005 02:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05778 for ; Wed, 12 Jan 2005 02:20:57 -0500 (EST) From: Lionel.Silman@ecitele.com Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cod2J-0005Wb-UH for l2vpn@ietf.org; Wed, 12 Jan 2005 02:35:24 -0500 To: l2vpn@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 12 Jan 2005 09:20:50 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Lionel Silman/ECI Telecom(Release 5.0.2b (Intl)|16 December 1999) at 12/01/2005 09:21:35, Serialize by Notes Client on Lionel Silman/ECI Telecom(Release 5.0.2b (Intl)|16 December 1999) at 12/01/2005 09:21:35, Serialize complete at 12/01/2005 09:21:35, S/MIME Sign failed at 12/01/2005 09:21:35: The cryptographic key was not found, Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 01/12/2005 09:25:20, Serialize complete at 01/12/2005 09:25:20 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00286DA2C2256F87_=" X-Spam-Score: 0.3 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Subject: RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf This is a multipart message in MIME format. --=_alternative 00286DA2C2256F87_= Content-Type: text/plain; charset="us-ascii" Hi Ali, This response mentions diagrams on page 7 of your IETF presentation. The presentation does not appear to have been posted. Where can it be found? I found Section 9.2 of draft-ietf-l2vpn-vpls-ldp-05 to be so telegraphically written that I could not follow the details (and I think many other readers are in the same position). Your responses to Peter and Interoperability Draft fill in some of these details. The draft states "On a per P-VLAN basis, the MSTP will designate a single PE-rs to be used for carrying the traffic across the core". Does your diagram help explain that statement? As a nit, draft-ietf-l2vpn-vpls-ldp-05 should refer to S-VLAN instead of P-VLAN in accordance with the 802.1ad terminology (and draft-sajassi-l2vpn-vpls-bridge-interop-00). I am hoping that your diagrams will clarify some points which still are not clear on these important issues. Expanded drafts are needed. ---------------------------------------------------------------------------------------------------- Lionel Silman, System, Optical Networks Division, ECI Telecom Tel Work: +972 (3) 9266007; Home: +972 (3) 6417464 Ali Sajassi Sent by: l2vpn-bounces@ietf.org 18/11/2004 08:38 To: "Busschbach, Peter B (Peter)" , "'Ali Sajassi'" , l2vpn@ietf.org cc: Subject: RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00 Hi Peter, Please refer to my comments below ... [snipped] >Unfortunately, I don't fully understand section 9.2 of the vpls-ldp draft. >Perhaps you could shed your light on that as well :-) Section 9.2 mentions: > >"If an island has more than one PE-rs, then a dedicated full-mesh of >pseudowires is used among these PE-rs devices for carrying the SP BPDU >packets for that island." > >What is meant by "dedicated"? Since the PE-rs devices are part of the VPLS >network, there is by definition a full mesh of PWs between them. Are the >dedicated PWs for SP BDPU packets different PWs than the ones that carry >the data traffic? Exactly. These full-mesh of PWs are dedicated to carry the service providers BPDUs only and this full-mesh is for the PE-rs devices of that island only and not the whole network. So if the whole network consists of 5 access islands each of which having three PE-rs devices, then each island has a full-mesh of three PWs for its BPDU traffic. And if a VPLS instance (for a given customer) spans across all the five islands, then that VPLS instance needs a full-mesh of 105 PWs (15*7). The idea of having a separate full-mesh of PWs for each island's BPDU traffic is to make each island STP independent from every other islands. >Also, would it not be possible that as a result of running MSTP in the >P-VPLAN, the VPLS network itself is blocked? E.g. if an MTU-s is connected >to both PE1 and PE2 and the resulting spanning tree is such that the link >between PE1 and PE2 is blocked (i.e. the MTU-s is the root), then MTU-s >will forward packets with unknown MAC address received from PE1 to PE2 and >vice versa. Now, if PE1 and PE2 both block all traffic from the VPLS >network, the P-VPLAN is isolated from all remote nodes. On the other hand, >if PE1 and PE2 both forward traffic over the VPLS network, there is a loop. This won't happen. The full-mesh of PWs for that islands BPDUs is for the virtual bridge port that I draw in the PE model in page 7 of my IETF presentation (I have sent my preso to the chairs to be posted). So if you take a look at that figure, hopefully things become more clear. When that virtual port gets blocked, then all the VPLS instances (or provider VLANs) over that port gets blocked as well and therefore, only a single PE-rs will be active for any given VPLS instance. Even if there is another link between the two PE-rs devices, the MSTP will take care of blocking this additional link. >Does a single PW failure in a full-mesh of PWs cause a total interruption >of BPDUs? I would think that in a bridge world, every site that >participates in a VPLS instance would generate BPDUs. If PE1 stops >receiving BDPUs from PE2 due to a PW failure, but if it continues >receiving BPDUs from PE3, PE4, etc., why would it change the forwarding state? There are scenarios with dual-homing of a customer site or redundant connection via another network, where a unidirectional failure of PW can result in a loop - it would be easier to show these scenarios via figures. Also in the scenario that you describe above, because the CE1 connected to PE1 doesn't receive BPDUs directly from the CE2 (connected to PE2), then it can miscalculate its path to the root and block its link and open up an alternative link through another network which is not desirable. > > Now in case of a > > uni-directional failure > > of a PW, if the detection & recovery time for a PW failure is > > greater than > > twice the BPDU hello time, > >What is the BPDU hello time? typically 2 seconds. > > Let me give you another example: if three customer CEs are > > connected via 10 > > provider bridges (e.g., there are ten bridges in the path of > > these three > > CEs), then only a single bridge needs to do MAC address learning. > > >I still don't understand. If three CEs are connected to three PEs, don't >all three PEs need to participate in MAC address learning? > >You can avoid any MAC learning in PEs by establishing point-to-point PWs >between CEs. However, in a regular VPLS architecture, each PE needs to do >MAC learning, right? Typically yes, all the PEs need to learn MAC addresses but what I am talking about is that the MAC address learning can be optimized (per 802.1ad) such that only the PEs that need to learn MAC addresses, then learn MAC addresses. Let me give you another example, if a customer has only two CEs connected via a VPLS network, then we can optimized our network such that no MAC address learning is needed because the path between the two CEs through the network is basically a PtP path. Now if you consider three CEs, then there can be only a single Y branch along the path between the three CEs and therefore, only the PE with Y branch needs to learn MAC address. With this optimization, the question is not if a PE can learn customer MAC addresses but whether a PE needs to learn customer MAC addresses. -Ali > > >[snipped to the end] --=_alternative 00286DA2C2256F87_= Content-Type: text/html; charset="us-ascii"
Hi Ali,

This response mentions diagrams on page 7 of your IETF presentation. The presentation does not appear to have been posted. Where can it be found?

I found Section 9.2 of draft-ietf-l2vpn-vpls-ldp-05 to be so telegraphically written that I could not follow the details (and I think many other readers are in the same position). Your responses to Peter and  Interoperability Draft fill in some of these details.

The draft states "On a per P-VLAN basis, the MSTP will designate a single PE-rs to be used for carrying the traffic across the core". Does your diagram help explain that statement?

As a nit, draft-ietf-l2vpn-vpls-ldp-05 should refer to S-VLAN instead of P-VLAN in accordance with the 802.1ad terminology (and draft-sajassi-l2vpn-vpls-bridge-interop-00).

I am hoping that your diagrams will clarify some points which still are not clear on these important issues. Expanded drafts are needed.

----------------------------------------------------------------------------------------------------
Lionel Silman,  System, Optical Networks Division, ECI Telecom
Tel    Work: +972 (3) 9266007; Home: +972 (3) 6417464


Ali Sajassi <sajassi@cisco.com>
Sent by: l2vpn-bounces@ietf.org

18/11/2004 08:38

       
        To:        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>, "'Ali Sajassi'" <sajassi@cisco.com>, l2vpn@ietf.org
        cc:        
        Subject:        RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00


Hi Peter,

Please refer to my comments below ...

[snipped]


>Unfortunately, I don't fully understand section 9.2 of the vpls-ldp draft.
>Perhaps you could shed your light on that as well :-)   Section 9.2 mentions:
>
>"If an island has more than one PE-rs, then a dedicated full-mesh of
>pseudowires is used among these PE-rs devices for carrying the SP BPDU
>packets for  that island."
>
>What is meant by "dedicated"? Since the PE-rs devices are part of the VPLS
>network, there is by definition a full mesh of PWs between them. Are the
>dedicated PWs for SP BDPU packets different PWs than the ones that carry
>the data traffic?

Exactly. These full-mesh of PWs are dedicated to carry the service
providers BPDUs only and this full-mesh is for the PE-rs devices of that
island only and not the whole network. So if the whole network consists of
5 access islands each of which having three PE-rs devices, then each island
has a full-mesh of three PWs for its BPDU traffic. And if a VPLS instance
(for a given customer) spans across all the five islands, then that VPLS
instance needs a full-mesh of 105 PWs (15*7). The idea of having a separate
full-mesh of PWs for each island's BPDU traffic is to make each island STP
independent from every other islands.


>Also, would it not be possible that as a result of running MSTP in the
>P-VPLAN, the VPLS network itself is blocked? E.g. if an MTU-s is connected
>to both PE1 and PE2 and the resulting spanning tree is such that the link
>between PE1 and PE2 is blocked (i.e. the MTU-s is the root), then MTU-s
>will forward packets with unknown MAC address received from PE1 to PE2 and
>vice versa. Now, if PE1 and PE2 both block all traffic from the VPLS
>network, the P-VPLAN is isolated from all remote nodes. On the other hand,
>if PE1 and PE2 both forward traffic over the VPLS network, there is a loop.

This won't happen. The full-mesh of PWs for that islands BPDUs is for the
virtual bridge port that I draw in the PE model in page 7 of my IETF
presentation (I have sent my preso to the chairs to be posted). So if you
take a look at that figure, hopefully things become more clear. When that
virtual port gets blocked, then all the VPLS instances (or provider VLANs)
over that port gets blocked as well and therefore, only a single PE-rs will
be active for any given VPLS instance. Even if there is another link
between the two PE-rs devices, the MSTP will take care of blocking this
additional link.


>Does a single PW failure in a full-mesh of PWs cause a total interruption
>of BPDUs? I would think that in a bridge world, every site that
>participates in a VPLS instance would generate BPDUs. If PE1 stops
>receiving BDPUs from PE2 due to a PW failure, but if it continues
>receiving BPDUs from PE3, PE4, etc., why would it change the forwarding state?

There are scenarios with dual-homing of a customer site or redundant
connection via another network, where a unidirectional failure of PW can
result in a loop - it would be easier to show these scenarios via figures.
Also in the scenario that you describe above, because the CE1 connected to
PE1 doesn't receive BPDUs directly from the CE2 (connected to PE2), then it
can miscalculate its path to the root and block its link and open up an
alternative link through another network which is not desirable.



> > Now in case of a
> > uni-directional failure
> > of a PW, if the detection & recovery time for a PW failure is
> > greater than
> > twice the BPDU hello time,
>
>What is the BPDU hello time?

typically 2 seconds.

> > Let me give you another example: if three customer CEs are
> > connected via 10
> > provider bridges (e.g., there are ten bridges in the path of
> > these three
> > CEs), then only a single bridge needs to do MAC address learning.
>
>
>I still don't understand. If three CEs are connected to three PEs, don't
>all three PEs need to participate in MAC address learning?
>
>You can avoid any MAC learning in PEs by establishing point-to-point PWs
>between CEs. However, in a regular VPLS architecture, each PE needs to do
>MAC learning, right?

Typically yes, all the PEs need to learn MAC addresses but what I am
talking about is that the MAC address learning can be optimized (per
802.1ad) such that only the PEs that need to learn MAC addresses, then
learn MAC addresses. Let me give you another example, if a customer has
only two CEs connected via a VPLS network, then we can optimized our
network such that no MAC address learning is needed because the path
between the two CEs through the network is basically a PtP path. Now if you
consider three CEs, then there can be only a single Y branch along the path
between the three CEs and therefore, only the PE with Y branch needs to
learn MAC address. With this optimization, the question is not if a PE can
learn customer MAC addresses but whether a PE needs to learn customer MAC
addresses.

-Ali



> >
>[snipped to the end]



--=_alternative 00286DA2C2256F87_=-- From l2vpn-bounces@ietf.org Thu Jan 13 03:10:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15425 for ; Thu, 13 Jan 2005 03:10:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp0II-0004tf-MI for l2vpn-web-archive@ietf.org; Thu, 13 Jan 2005 03:25:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp005-00014N-IZ; Thu, 13 Jan 2005 03:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cozxn-0000GC-E5 for l2vpn@megatron.ietf.org; Thu, 13 Jan 2005 03:04:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15194 for ; Thu, 13 Jan 2005 03:04:13 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp0Bv-0004mN-Ff for l2vpn@ietf.org; Thu, 13 Jan 2005 03:18:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2005 00:07:00 -0800 Received: from sajassi-w2k4.cisco.com (sjc-vpn5-44.cisco.com [10.21.88.44]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0D83Wl3000258; Thu, 13 Jan 2005 00:03:32 -0800 (PST) Message-Id: <4.3.2.7.2.20050112231711.036ebda8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jan 2005 00:03:35 -0800 To: Lionel.Silman@ecitele.com, l2vpn@ietf.org From: Ali Sajassi In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_32909771==_.ALT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Subject: RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c --=====================_32909771==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Lionel, At 09:20 AM 1/12/2005 +0200, Lionel.Silman@ecitele.com wrote: >Hi Ali, > >This response mentions diagrams on page 7 of your IETF presentation. The >presentation does not appear to have been posted. Where can it be found? Here is the pointer to it. http://www1.ietf.org/proceedings_new/04nov/slides/l2vpn-9.pdf >I found Section 9.2 of draft-ietf-l2vpn-vpls-ldp-05 to be so >telegraphically written that I could not follow the details (and I think >many other readers are in the same position). Your responses to Peter >and Interoperability Draft fill in some of these details. I agree with you. The couple of paragraph in the section 9.2 is neither enough nor does Justices to treat this topic in reasonable details. As soon as I get a chance, I will incorporate some of the stuff that I discussed previously into either this draft or a new draft. >The draft states "On a per P-VLAN basis, the MSTP will designate a single >PE-rs to be used for carrying the traffic across the core". Does your >diagram help explain that statement? Not quite but Figure-7 may help somewhat. It shows the model for the PE-rs with bridging component and you can think of one those VPLS instances shown in the model is for carrying service provider BPDUs among the PE-rs devices of the same island. Furthermore, this BPDU VPLS is mapped into BPDU untagged traffic of the virtual bridge port. From there on, MSTP operates as it should among the provider's PE-rs devices of a given island (e.g., it is limited to that island only). >As a nit, draft-ietf-l2vpn-vpls-ldp-05 should refer to S-VLAN instead of >P-VLAN in accordance with the 802.1ad terminology (and >draft-sajassi-l2vpn-vpls-bridge-interop-00). Agree. >I am hoping that your diagrams will clarify some points which still are >not clear on these important issues. Expanded drafts are needed. I agree that we need more detailed description and I will work on it. -Ali >---------------------------------------------------------------------------------------------------- >Lionel Silman, System, Optical Networks Division, ECI Telecom >Tel Work: +972 (3) 9266007; Home: +972 (3) 6417464 > > >Ali Sajassi >Sent by: l2vpn-bounces@ietf.org > >18/11/2004 08:38 > > To: "Busschbach, Peter B (Peter)" , > "'Ali Sajassi'" , l2vpn@ietf.org > cc: > Subject: RE: Questions about > draft-sajassi-l2vpn-vpls-bridge-interop-00 > >Hi Peter, > >Please refer to my comments below ... > >[snipped] > > > >Unfortunately, I don't fully understand section 9.2 of the vpls-ldp draft. > >Perhaps you could shed your light on that as well :-) Section 9.2 > mentions: > > > >"If an island has more than one PE-rs, then a dedicated full-mesh of > >pseudowires is used among these PE-rs devices for carrying the SP BPDU > >packets for that island." > > > >What is meant by "dedicated"? Since the PE-rs devices are part of the VPLS > >network, there is by definition a full mesh of PWs between them. Are the > >dedicated PWs for SP BDPU packets different PWs than the ones that carry > >the data traffic? > >Exactly. These full-mesh of PWs are dedicated to carry the service >providers BPDUs only and this full-mesh is for the PE-rs devices of that >island only and not the whole network. So if the whole network consists of >5 access islands each of which having three PE-rs devices, then each island >has a full-mesh of three PWs for its BPDU traffic. And if a VPLS instance >(for a given customer) spans across all the five islands, then that VPLS >instance needs a full-mesh of 105 PWs (15*7). The idea of having a separate >full-mesh of PWs for each island's BPDU traffic is to make each island STP >independent from every other islands. > > > >Also, would it not be possible that as a result of running MSTP in the > >P-VPLAN, the VPLS network itself is blocked? E.g. if an MTU-s is connected > >to both PE1 and PE2 and the resulting spanning tree is such that the link > >between PE1 and PE2 is blocked (i.e. the MTU-s is the root), then MTU-s > >will forward packets with unknown MAC address received from PE1 to PE2 and > >vice versa. Now, if PE1 and PE2 both block all traffic from the VPLS > >network, the P-VPLAN is isolated from all remote nodes. On the other hand, > >if PE1 and PE2 both forward traffic over the VPLS network, there is a loop. > >This won't happen. The full-mesh of PWs for that islands BPDUs is for the >virtual bridge port that I draw in the PE model in page 7 of my IETF >presentation (I have sent my preso to the chairs to be posted). So if you >take a look at that figure, hopefully things become more clear. When that >virtual port gets blocked, then all the VPLS instances (or provider VLANs) >over that port gets blocked as well and therefore, only a single PE-rs will >be active for any given VPLS instance. Even if there is another link >between the two PE-rs devices, the MSTP will take care of blocking this >additional link. > > > >Does a single PW failure in a full-mesh of PWs cause a total interruption > >of BPDUs? I would think that in a bridge world, every site that > >participates in a VPLS instance would generate BPDUs. If PE1 stops > >receiving BDPUs from PE2 due to a PW failure, but if it continues > >receiving BPDUs from PE3, PE4, etc., why would it change the forwarding > state? > >There are scenarios with dual-homing of a customer site or redundant >connection via another network, where a unidirectional failure of PW can >result in a loop - it would be easier to show these scenarios via figures. >Also in the scenario that you describe above, because the CE1 connected to >PE1 doesn't receive BPDUs directly from the CE2 (connected to PE2), then it >can miscalculate its path to the root and block its link and open up an >alternative link through another network which is not desirable. > > > > > > Now in case of a > > > uni-directional failure > > > of a PW, if the detection & recovery time for a PW failure is > > > greater than > > > twice the BPDU hello time, > > > >What is the BPDU hello time? > >typically 2 seconds. > > > > Let me give you another example: if three customer CEs are > > > connected via 10 > > > provider bridges (e.g., there are ten bridges in the path of > > > these three > > > CEs), then only a single bridge needs to do MAC address learning. > > > > > >I still don't understand. If three CEs are connected to three PEs, don't > >all three PEs need to participate in MAC address learning? > > > >You can avoid any MAC learning in PEs by establishing point-to-point PWs > >between CEs. However, in a regular VPLS architecture, each PE needs to do > >MAC learning, right? > >Typically yes, all the PEs need to learn MAC addresses but what I am >talking about is that the MAC address learning can be optimized (per >802.1ad) such that only the PEs that need to learn MAC addresses, then >learn MAC addresses. Let me give you another example, if a customer has >only two CEs connected via a VPLS network, then we can optimized our >network such that no MAC address learning is needed because the path >between the two CEs through the network is basically a PtP path. Now if you >consider three CEs, then there can be only a single Y branch along the path >between the three CEs and therefore, only the PE with Y branch needs to >learn MAC address. With this optimization, the question is not if a PE can >learn customer MAC addresses but whether a PE needs to learn customer MAC >addresses. > >-Ali > > > > > > > >[snipped to the end] > > > > > --=====================_32909771==_.ALT Content-Type: text/html; charset="us-ascii" Hi Lionel,
At 09:20 AM 1/12/2005 +0200, Lionel.Silman@ecitele.com wrote:

Hi Ali,

This response mentions diagrams on page 7 of your IETF presentation. The presentation does not appear to have been posted. Where can it be found?

Here is the pointer to it.
http://www1.ietf.org/proceedings_new/04nov/slides/l2vpn-9.pdf


I found Section 9.2 of draft-ietf-l2vpn-vpls-ldp-05 to be so telegraphically written that I could not follow the details (and I think many other readers are in the same position). Your responses to Peter and  Interoperability Draft fill in some of these details.

I agree with you. The couple of paragraph in the section 9.2 is neither enough nor does Justices to treat this topic in reasonable details. As soon as I get a chance, I will incorporate some of the stuff that I discussed previously into either this draft or a new draft.


The draft states "On a per P-VLAN basis, the MSTP will designate a single PE-rs to be used for carrying the traffic across the core". Does your diagram help explain that statement?

Not quite but Figure-7 may help somewhat. It shows the model for the PE-rs with bridging component and you can think of one those VPLS instances shown in the model is for carrying service provider BPDUs among the PE-rs devices of the same island. Furthermore, this BPDU VPLS is mapped into BPDU untagged traffic of the virtual bridge port. From there on, MSTP operates as it should among the provider's PE-rs devices of a given island (e.g., it is limited to that island only).


As a nit, draft-ietf-l2vpn-vpls-ldp-05 should refer to S-VLAN instead of P-VLAN in accordance with the 802.1ad terminology (and draft-sajassi-l2vpn-vpls-bridge-interop-00).

Agree.


I am hoping that your diagrams will clarify some points which still are not clear on these important issues. Expanded drafts are needed.

I agree that we need more detailed description and I will work on it.

-Ali


----------------------------------------------------------------------------------------------------
Lionel Silman,  System, Optical Networks Division, ECI Telecom
Tel    Work: +972 (3) 9266007; Home: +972 (3) 6417464


Ali Sajassi <sajassi@cisco.com>
Sent by: l2vpn-bounces@ietf.org

18/11/2004 08:38
       
        To:        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>, "'Ali Sajassi'" <sajassi@cisco.com>, l2vpn@ietf.org
        cc:       
        Subject:        RE: Questions about draft-sajassi-l2vpn-vpls-bridge-interop-00

Hi Peter,

Please refer to my comments below ...

[snipped]


>Unfortunately, I don't fully understand section 9.2 of the vpls-ldp draft.
>Perhaps you could shed your light on that as well :-)   Section 9.2 mentions:
>
>"If an island has more than one PE-rs, then a dedicated full-mesh of
>pseudowires is used among these PE-rs devices for carrying the SP BPDU
>packets for  that island."
>
>What is meant by "dedicated"? Since the PE-rs devices are part of the VPLS
>network, there is by definition a full mesh of PWs between them. Are the
>dedicated PWs for SP BDPU packets different PWs than the ones that carry
>the data traffic?

Exactly. These full-mesh of PWs are dedicated to carry the service
providers BPDUs only and this full-mesh is for the PE-rs devices of that
island only and not the whole network. So if the whole network consists of
5 access islands each of which having three PE-rs devices, then each island
has a full-mesh of three PWs for its BPDU traffic. And if a VPLS instance
(for a given customer) spans across all the five islands, then that VPLS
instance needs a full-mesh of 105 PWs (15*7). The idea of having a separate
full-mesh of PWs for each island's BPDU traffic is to make each island STP
independent from every other islands.


>Also, would it not be possible that as a result of running MSTP in the
>P-VPLAN, the VPLS network itself is blocked? E.g. if an MTU-s is connected
>to both PE1 and PE2 and the resulting spanning tree is such that the link
>between PE1 and PE2 is blocked (i.e. the MTU-s is the root), then MTU-s
>will forward packets with unknown MAC address received from PE1 to PE2 and
>vice versa. Now, if PE1 and PE2 both block all traffic from the VPLS
>network, the P-VPLAN is isolated from all remote nodes. On the other hand,
>if PE1 and PE2 both forward traffic over the VPLS network, there is a loop.

This won't happen. The full-mesh of PWs for that islands BPDUs is for the
virtual bridge port that I draw in the PE model in page 7 of my IETF
presentation (I have sent my preso to the chairs to be posted). So if you
take a look at that figure, hopefully things become more clear. When that
virtual port gets blocked, then all the VPLS instances (or provider VLANs)
over that port gets blocked as well and therefore, only a single PE-rs will
be active for any given VPLS instance. Even if there is another link
between the two PE-rs devices, the MSTP will take care of blocking this
additional link.


>Does a single PW failure in a full-mesh of PWs cause a total interruption
>of BPDUs? I would think that in a bridge world, every site that
>participates in a VPLS instance would generate BPDUs. If PE1 stops
>receiving BDPUs from PE2 due to a PW failure, but if it continues
>receiving BPDUs from PE3, PE4, etc., why would it change the forwarding state?

There are scenarios with dual-homing of a customer site or redundant
connection via another network, where a unidirectional failure of PW can
result in a loop - it would be easier to show these scenarios via figures.
Also in the scenario that you describe above, because the CE1 connected to
PE1 doesn't receive BPDUs directly from the CE2 (connected to PE2), then it
can miscalculate its path to the root and block its link and open up an
alternative link through another network which is not desirable.



> > Now in case of a
> > uni-directional failure
> > of a PW, if the detection & recovery time for a PW failure is
> > greater than
> > twice the BPDU hello time,
>
>What is the BPDU hello time?

typically 2 seconds.

> > Let me give you another example: if three customer CEs are
> > connected via 10
> > provider bridges (e.g., there are ten bridges in the path of
> > these three
> > CEs), then only a single bridge needs to do MAC address learning.
>
>
>I still don't understand. If three CEs are connected to three PEs, don't
>all three PEs need to participate in MAC address learning?
>
>You can avoid any MAC learning in PEs by establishing point-to-point PWs
>between CEs. However, in a regular VPLS architecture, each PE needs to do
>MAC learning, right?

Typically yes, all the PEs need to learn MAC addresses but what I am
talking about is that the MAC address learning can be optimized (per
802.1ad) such that only the PEs that need to learn MAC addresses, then
learn MAC addresses. Let me give you another example, if a customer has
only two CEs connected via a VPLS network, then we can optimized our
network such that no MAC address learning is needed because the path
between the two CEs through the network is basically a PtP path. Now if you
consider three CEs, then there can be only a single Y branch along the path
between the three CEs and therefore, only the PE with Y branch needs to
learn MAC address. With this optimization, the question is not if a PE can
learn customer MAC addresses but whether a PE needs to learn customer MAC
addresses.

-Ali



> >
>[snipped to the end]





--=====================_32909771==_.ALT-- From l2vpn-bounces@ietf.org Thu Jan 13 20:10:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12310 for ; Thu, 13 Jan 2005 20:10:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpGDA-0005tY-0u for l2vpn-web-archive@ietf.org; Thu, 13 Jan 2005 20:25:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpFrd-0008Tu-FB; Thu, 13 Jan 2005 20:02:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpFhh-0004LC-GZ for l2vpn@megatron.ietf.org; Thu, 13 Jan 2005 19:52:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10989 for ; Thu, 13 Jan 2005 19:52:37 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpFvp-0005W9-2y for l2vpn@ietf.org; Thu, 13 Jan 2005 20:07:30 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAA00CKN7S2IH@szxga02-in.huawei.com> for l2vpn@ietf.org; Fri, 14 Jan 2005 08:52:50 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAA00MFD7S1FN@szxga02-in.huawei.com> for l2vpn@ietf.org; Fri, 14 Jan 2005 08:52:49 +0800 (CST) Received: from h22280B ([10.110.49.238]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IAA00M3G7WCZ1@szxml01-in.huawei.com> for l2vpn@ietf.org; Fri, 14 Jan 2005 08:55:24 +0800 (CST) Date: Fri, 14 Jan 2005 08:53:39 +0800 From: Huke Hu Chun Zhe To: l2vpn@ietf.org Message-id: <004101c4f9d3$7cd75900$ee316e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: base64 Subject: Request for comments ===>Fw: Two issues regarding BGP VPLS X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkh1a2UgSHUgQ2h1biBaaGUi IDxodWNodW56aGVAaHVhd2VpLmNvbT4NClRvOiA8a2lyZWV0aUBqdW5pcGVyLm5ldD4NClNlbnQ6 IEZyaWRheSwgSmFudWFyeSAwNywgMjAwNSA2OjU0IFBNDQpTdWJqZWN0OiBSZTogVHdvIGlzc3Vl cyByZWdhcmRpbmcgQkdQIFZQTFMNCg0KDQo+IFRoaXMgaXMgbWUgYW5kIERocnV2J3MgZm9ybWFs IHJlcGx5ICwgcGxlYXNlIGNoZWNrIA0KPiANCj4gRGVhciBLaXJlZXRpLA0KPiANCj4gIA0KPiAN Cj4gSXNzdWUgMTogTXVsdGkgaG9taW5nDQo+IA0KPiBGcm9tIHRoZSBkcmFmdCAtIKGwV2hlbiBh IEJHUCBzcGVha2VyIHJlY2VpdmVzIHR3byBlcXVpdmFsZW50IE5MUklzIChzZWUgYmVsb3cgZm9y IHRoZSBkZWZpbml0aW9uKSwgaXQgYXBwbGllcyBzdGFuZGFyZCBwYXRoIHNlbGVjdGlvbiBjcml0 ZXJpYSBzdWNoIGFzIExvY2FsIFByZWZlcmVuY2UgYW5kIEFTIFBhdGggTGVuZ3RoIHRvIGRldGVy bWluZSB3aGljaCBOTFJJIHRvIGNob29zZTsgaXQgTVVTVCBwaWNrIG9ubHkgb25lLqGxDQo+IA0K PiAgDQo+IA0KPiAxKSAgICAgV2UgY2FudCB1c2UgdGhlIEJHUCBzdGFuZGFyZCBwYXRoIHNlbGVj dGlvbiBhbGdvcml0aG0gYXMgcGVyIHlvdXIgcmVwbHkNCj4gDQo+IDIpICAgICBDYW50IHVzZSBB UyBQYXRoIExlbmd0aCBhcyBtZW50aW9uZWQgaW4geW91ciByZXBseSwgYnV0IHN0YXRlZCBpbiBk cmFmdA0KPiANCj4gMykgICAgIExvY2FsIFByZWZlcmVuY2UgaXMgbG9jYWwgdG8gYW4gQVMgYW5k IGlzIGV4Y2hhbmdlZCBiZXR3ZWVuIElCR1AgcGVlcnMgb25seSwgd2hlbiBtdWx0aS1ob21lZCBQ RXMgYmVsb25nIHRvIGRpZmZlcmVudCBBUywgd2UgY2Fubm90IHVzZSBpdC4NCj4gDQo+IDQpICAg ICBXZSBoYXZlIGEgZnVsbCBtZXNoIHJlcXVpcmVtZW50IGZvciBQRXMgd2l0aGluIGFuIEFTIGJ1 dCB3aGVuIGEgc2l0ZSBpcyBtdWx0aS1ob21lZCB0byBQRXMgYmVsb25naW5nIHRvIGRpZmZlcmVu dCBBUyBhIGZ1bGwgbWVzaCByZXF1aXJlbWVudCBiZXR3ZWVuIHRoZXNlIFBFcyBpcyBhIHRvbyBt dWNoIHRvIGFzayBmb3IuDQo+IA0KPiAgDQo+IA0KPiBJc3N1ZSAyOiBUdW5uZWwgSGFuZGxpbmcN Cj4gDQo+IFJlbW92aW5nIHRoZSBzaXRlIGZyb20gVlBMUywgd2hlbiB0dW5uZWwgdG8gb25lIHBl ZXIgaXMgZG93biB3aWxsIGJlIGEgdmVyeSBjb3N0bHkgb3BlcmF0aW9uLiBJbiBjYXNlIG9mIHJv dXRlIGRhbXBpbmcgb3IgdHVubmVsIGZsdWN0dWF0aW9uIHdlIHdvdWxkIGVuZCB1cCBzZW5kaW5n IFJFQUNIIC8gVU5SRUFDSCB0byBhbGwgdGhlIHBlZXJzIGFuZCB0aGUgd2hvbGUgVlBMUyB3b3Vs ZCBiZSBhZmZlY3RlZCBiZWNhdXNlIG9mIGp1c3Qgb25lIHBlZXIuIFRoZSBkYXRhIHBsYW5lIHdv dWxkIGxvb3NlIGl0cyByb2J1c3RuZXNzIGFuZCBhbGwgdGhlIFBFcyB0aHJvdWdob3V0IHRoZSBW UExTIHdvdWxkIGJlIGFkZGluZyBhbmQgZGVsZXRpbmcgZm9yd2FyZGluZyBlbnRyaWVzLiANCj4g DQo+ICANCj4gDQo+IEluIGNhc2Ugb2YgVlBMUyB2aWEgTERQIGRyYWZ0LWlldGYtbDJ2cG4tdnBs cy1sZHAtMDMgd2UgY2FuIHNlbmQgd2l0aGRyYXduIHRvIGp1c3Qgb25lIHBlZXIgYW5kIHRoZXJl IHdvdWxkIGJlIG5vIGltcGFjdCBvbiBvdGhlciBQRXMgaW4gdGhlIFZQTFMuIEluIGNhc2Ugb2Yg UFdFMyB3ZSBoYXZlIG1lY2hhbmlzbSB0byBzZW5kIG5vdGlmaWNhdGlvbiB0byBwZWVycyBpbiBj YXNlIG9mIHN1Y2ggdHVubmVsIGV2ZW50cy4gVGhpcyBtYWtlcyB0aGUgZGF0YSBwbGFuZSB2ZXJ5 IHN0YWJsZS4NCj4gDQo+ICANCj4gDQo+IFR1bm5lbCBkb3duIHRvIGp1c3Qgb25lIHBlZXIgKGEg cGFydGljdWxhciBzaXRlKSBzaG91bGQgYmUgbm90aWZpZWQgdG8gdGhhdCBwZWVyLiBJbiBjYXNl IHdlIGFkZCBDU1YgYml0cyB3ZSB3b3VsZCBzZW5kIFJlYWNoIE5MUkkgYWdhaW4gYnV0IGZvcndh cmRpbmcgZW50cmllcyB3b3VsZCBiZSB1cGRhdGVkIG9ubHkgb24gdGhlIHRhcmdldCBQRXMgYW5k IGF0IGFsbCBvdGhlciBQRXMgTkxSSXMgd291bGQganVzdCBiZSB1cGRhdGVkLiANCj4gDQo+ICAN Cj4gDQo+IFRoZSBpZGVhIG9mIHJlbW92aW5nIGEgc2l0ZSBjb21wbGV0ZWx5IGZvciBWUExTIGlu IGFuIGV2ZW50IG9mIGp1c3Qgb25lIHR1bm5lbCBkb3duIHNlZW1zIGluYXBwcm9wcmlhdGUuDQo+ IA0KPiAgDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZXNlIHByb21wdCByZXBsaWVzLg0KPiANCj4g IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEh1Y2h1bnpoZSAvIERocnV2DQo+IA0KPiANCj4gDQo+ IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206IDxraXJlZXRpQGp1bmlwZXIu bmV0Pg0KPiBUbzogPGh1Y2h1bnpoZUBodWF3ZWkuY29tPjsgPGtpcmVldGlAanVuaXBlci5uZXQ+ DQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAwNywgMjAwNSAyOjA0IFBNDQo+IFN1YmplY3Q6IFJl OiBUd28gaXNzdWVzIHJlZ2FyZGluZyBCR1AgVlBMUw0KPiANCj4gDQo+ID4gPiBJIHRoaW5rIGlm IG9ubHkgb25lIHR1bm5lbCBidHcgUEUxIGFuZCBQRTkgZ28gZG93biANCj4gPiA+IFBFMSB3aWxs IHdpdGhkcmF3IGZyb20gVlBMUyAsIHRoaXMgcHJvY2VzcyBpcyB2ZXJ5IGNvc3RseSANCj4gPiA+ IGNvbXBhcmVkIHdpdGggbWFydGluaSBtb2RlICwgd2hlcmUgdGhlcmUgaXMgbm90aWZpY2F0aW9u IGluIExEUA0KPiA+ID4gdG8gcmVjb3ZlciBmcm9tIHRoaXMgdHVubmVsIGRvd24gYW5kIGFnYWlu IHVwIGV2ZW50IC4NCj4gPiANCj4gPiBJIHRoaW5rIHlvdSBhcmUgbWlzc2luZyB0aGUgcG9pbnQu ICBWUExTICpyZXF1aXJlcyogYSBmdWxsIG1lc2guDQo+ID4gVGhpcyBpcyBpbmRlcGVuZGVudCBv ZiB0aGUgcHJvdG9jb2wgdXNlZCBmb3Igc2lnbmFsaW5nLiAgU28gd2hldGhlcg0KPiA+IHRoZSBz aWduYWxpbmcgaXMgQkdQIG9yIExEUCwgUEUxIGhhcyB0byB3aXRoZHJhdyBmcm9tIHRoZSBWUExT Lg0KPiA+IFdpdGggQkdQLCB0aGlzIGlzIGEgc2luZ2xlIE5MUkkgd2l0aGRyYXdhbC4gIFdpdGgg TERQLCBQRTEgaGFzIHRvDQo+ID4gc2VuZCBOIGluZGVwZW5kZW50IHdpdGhkcmF3cyAob3Igbm90 aWZpY2F0aW9ucykuDQo+ID4gDQo+ID4gKElmIHlvdSBnbyBvdmVyIHRoZSBMMlZQTiBhcmNoaXZl cywgeW91IHdpbGwgc2VlIGEgZGlzY3Vzc2lvbiBvbiB0aGlzLikNCj4gPiANCj4gPiBLaXJlZXRp Lg== From RRUVL@hotmail.com Sat Jan 22 04:47:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21387; Sat, 22 Jan 2005 04:47:17 -0500 (EST) Received: from [220.86.98.30] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CsI7X-0001Hg-0F; Sat, 22 Jan 2005 05:03:55 -0500 Received: from [92.50.234.23] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 689LFL-0078PT-10 Message-ID: <14955893144732.R37444@.noc..gr> Sender: freeradius-devel-RRUVL@hotmail.com X-Mailman-Version: 2.0.1 Date: Sat, 22 Jan 2005 05:42:53 -0400 From: "Melissa Vargas" To: l2vpn-web-archive@ietf.org Cc: l3vpn@ietf.org, l3vpn-admin@ietf.org, l3vpn-web-archive@ietf.org, ldap-dir@ietf.org, ldap-dir-admin@ietf.org, ldap-dir-web-archive@ietf.org, ldapext@ietf.org, ldapext-admin@ietf.org, ldapext-archive@ietf.org, lemonade@ietf.org, lemonade-request@ietf.org Subject: Viic0din and Hydr0c0done Heere ToE X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Offers of the month... Viaggra $139.95 Ciallis $129.95 Vallium $179.95 Xanaax $160.95 Ambient $114.95 Visitt us today for irresistable offerss.. http://expedited2u.biz/2/?wid=200007 This is 1 -time mailing. N0-re m0val are re'qui-red wDa0vw4d3jx0FFh8X5BcSAmWn3GxuBRhJsJM44kHYgD5MlLBfOU6ede4f From l2vpn-bounces@ietf.org Mon Jan 31 01:34:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09119 for ; Mon, 31 Jan 2005 01:34:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvVR1-0002ri-LR for l2vpn-web-archive@ietf.org; Mon, 31 Jan 2005 01:53:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvV7e-000098-2m; Mon, 31 Jan 2005 01:33:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvV57-0008Iz-Tb for l2vpn@megatron.ietf.org; Mon, 31 Jan 2005 01:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08941 for ; Mon, 31 Jan 2005 01:30:31 -0500 (EST) Received: from [152.102.113.70] (helo=mailman-kbt.datacraft-asia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvVMq-0002mh-5T for l2vpn@ietf.org; Mon, 31 Jan 2005 01:49:02 -0500 Received: from krsel-exchange2.Datacraft-Asia.Com (unverified) by mailman-kbt.datacraft-asia.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 31 Jan 2005 14:28:33 +0800 Message-ID: Received: from jerry (210.94.1.31 [210.94.1.31]) by krsel-exchange2.Datacraft-Asia.Com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DY2HX2Z2; Mon, 31 Jan 2005 15:26:17 +0900 From: "Jong-Hwan.Hyon\(Jerry\)" To: Date: Mon, 31 Jan 2005 15:29:41 +0900 Organization: DCK MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C507A9.B183CEC0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUHXj5kashavCbBR3acThw3xvRQWg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 1.3 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: Encap BPDUs has some problem in "draft-ietf-l2vpn-vpls-ldp-05.txt" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jerry@datacraft-korea.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C507A9.B183CEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, I've got a question about the use of "Encapsulation of BPDU" in VPLS Section 5.2 in page 11 of draft-ietf-l2vpn-vpls-ldp-05.txt states: " For STP to work in qualified mode, a VPLS PE must be able to forward STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case (see details in Section 10), service delimiting tags (Q-in-Q or Martini) can be added by MTU-s nodes such that PEs can unambiguously identify all customer traffic, including STP/MSTP BPDUs. In a basic VPLS case, upstream switches must insert such service delimiting tags. When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic. The STP/MSTP frames are encapsulated with a unique provider tag per customer (as the regular customer traffic), and a PEs looks up the provider tag to send such frames across the proper VPLS instance. ." If I have 1 sites, and this site has three location(branch), A, B, C. And loc.A uses a QinQ or Martini, and other locations, B and C use basic vpls mode(access mode), then the BPDUs port type is not match among each others. Location A's BPDUs look as Trunk, B and C switch discard these BPDUs because of port type mismatch. In this case, the STP don't work properly. Isn't it? Can someone explain to me please? Thanks, Jerry. ***Pls, excuese my poor engilsh!!! ** ------=_NextPart_000_000A_01C507A9.B183CEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 folks,
I've got a question about the use of = "Encapsulation of BPDU" in VPLS
Section 5.2 in page 11=20 of draft-ietf-l2vpn-vpls-ldp-05.txt  states:
 
"=20 For STP to work in qualified mode, a VPLS PE must be able to = forward STP=20 BPDUs over the proper VPLS instance. In a hierarchical VPLS case (see = details in=20 Section 10), service delimiting tags (Q-in-Q or Martini) can be added by = MTU-s=20 nodes such that PEs can unambiguously identify all customer traffic, = including=20 STP/MSTP BPDUs. In a basic VPLS case, upstream switches must insert such = service=20 delimiting tags. When an access port is shared among multiple customers, = a=20 reserved VLAN per customer domain must be used to carry STP/MSTP = traffic. The=20 STP/MSTP frames are encapsulated with a unique provider tag per customer = (as the=20 regular customer traffic), and a PEs looks up the provider tag to send = such=20 frames across the proper VPLS instance. ."
 
If I have 1 sites, and this=20 site has three location(branch), A,=20 B, C. 
And loc.A uses a QinQ or Martini, and = other=20 locations, B and C use basic vpls mode(access mode), then the BPDUs port = type is=20 not match among each others.
Location A's=20 BPDUs look as Trunk,  B and C switch discard these BPDUs because of = port=20 type mismatch.
 
In = this case,=20 the STP don't work properly. Isn't it?
 
Can someone explain to me = please?
 
Thanks,
Jerry.
 
***Pls, excuese=20 my poor engilsh!!! **
------=_NextPart_000_000A_01C507A9.B183CEC0-- From l2vpn-bounces@ietf.org Mon Jan 31 19:24:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28010 for ; Mon, 31 Jan 2005 19:24:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvm8a-0008Gc-S0 for l2vpn-web-archive@ietf.org; Mon, 31 Jan 2005 19:43:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvlgj-00060T-An; Mon, 31 Jan 2005 19:14:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvlUZ-0003kJ-P7 for l2vpn@megatron.ietf.org; Mon, 31 Jan 2005 19:02:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25703 for ; Mon, 31 Jan 2005 19:02:00 -0500 (EST) From: uwe.lindmueller@axxessit.no Received: from pt20-qms-02.ptn.no ([64.28.25.139]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cvlmb-0007hp-Ed for l2vpn@ietf.org; Mon, 31 Jan 2005 19:20:42 -0500 Received: (qmail 25161 invoked by uid 500); 31 Jan 2005 23:58:21 -0000 Received: from 10.20.44.2 by pt20-qms-02.ptn.no (envelope-from , uid 502) with qmail-scanner-1.23st (clamdscan: 0.75.1. uvscan: v4.3.20/v4388. perlscan: 1.23st. Clear:RC:1(10.20.44.2):. Processed in 0.276944 secs); 31 Jan 2005 23:58:21 -0000 X-AntiVirus-PTN-Mail-From: uwe.lindmueller@axxessit.no via pt20-qms-02.ptn.no X-AntiVirus-PTN: 1.23st (Clear:RC:1(10.20.44.2):. Processed in 0.276944 secs Process 25143) Received: from unknown (HELO axithnts20.axxessit.no) (10.20.44.2) by pt20-qms-02.ptn.no with SMTP; 31 Jan 2005 23:58:20 -0000 To: l2vpn@ietf.org Message-ID: Date: Tue, 1 Feb 2005 01:01:34 +0100 X-MIMETrack: Serialize by Router on NotesHalden/AxxessIT(Release 5.0.12 |February 13, 2003) at 01.02.2005 01:01:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: Uwe Lindmuller/AxxessIT is not available X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 I will be out of the office starting 31.01.2005 and will not return until 02.02.2005. I'm on vacation till 3th of January. In urgent cases please contact our support team at support@axxessit.no.