From l2vpn-bounces@ietf.org Mon Nov 1 12:13:24 2004 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 MAA05102 for ; Mon, 1 Nov 2004 12:13:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfz9-0004f3-Re for l2vpn-web-archive@ietf.org; Mon, 01 Nov 2004 12:28:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfUM-0003Yf-OZ; Mon, 01 Nov 2004 11:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COf3q-00078h-T5 for l2vpn@megatron.ietf.org; Mon, 01 Nov 2004 11:29:39 -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 LAA29038 for ; Mon, 1 Nov 2004 11:29:37 -0500 (EST) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfIl-000390-IM for l2vpn@ietf.org; Mon, 01 Nov 2004 11:45:05 -0500 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id iA1GNvr30566 for ; Mon, 1 Nov 2004 17:23:57 +0100 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Mon, 01 Nov 2004 17:29:16 +0100 Message-ID: <4186645A.6070105@pi.se> Date: Mon, 01 Nov 2004 17:29:14 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: L2VPN , Vach Kompella , Rick Wilder Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: draft agenda for the l2vpn meeting in DC 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit All, please find a draft agenda for the L2VPN WG meeting in Washingto DC http://www.tla-group.com/~l2vpn/l2vpn-agenda-dc.htm It is not yet completed, but ping me if I missed any requests for agenda slots. Will try to finalize it tomorrow. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Tue Nov 2 19:51:10 2004 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 TAA08569 for ; Tue, 2 Nov 2004 19:51:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9by-0003z4-PZ for l2vpn-web-archive@ietf.org; Tue, 02 Nov 2004 20:06:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP96V-0003wG-MT; Tue, 02 Nov 2004 19:34:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP91K-0001Hj-PK for l2vpn@megatron.ietf.org; Tue, 02 Nov 2004 19:29: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 TAA05867 for ; Tue, 2 Nov 2004 19:28:59 -0500 (EST) Received: from howler.tri.sbc.com ([205.173.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9GX-0003QG-Kb for l2vpn@ietf.org; Tue, 02 Nov 2004 19:44:46 -0500 Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id iA30SqeG012969; Tue, 2 Nov 2004 18:28:52 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (trimail2.ad.tri.sbc.com [144.60.55.227]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id iA30SpEb007829; Tue, 2 Nov 2004 18:28:51 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Nov 2004 18:28:51 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D606C2DCD7@trimail2> From: "Serbest, Yetik" To: "'Loa Andersson'" , L2VPN , Vach Kompella , Rick Wilder Date: Tue, 2 Nov 2004 18:28:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: RE: draft agenda for the l2vpn meeting in DC 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: 538aad3a3c4f01d8b6a6477ca4248793 Hi Everybody, We have a new version of the vpls-mcast draft. You can download it from the anonymous ftp site ftp.labs.sbc.com. The exact file name is draft-serbest-l2vpn-vpls-mcast-01.txt. It is under "/incoming/vpls" directory. In version 01: - In IGMP snooping, reports are sent to all mcast routers not just the Querier. - The options for an IGMPv3 report are explicitly stated and the example is changed accordingly. - Last query membership interval is explicitly stated for IGMP leave operation. - The PIM joins are not flooded any more, they are forwarded according to the "Upstream Neighbor Address" in join message. - In PIM-SM/SSM snooping, the issue of duplicate traffic is addressed. Please send your comments and feedback. Thanks, yetik -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, November 01, 2004 10:29 AM To: L2VPN; Vach Kompella; Rick Wilder Subject: draft agenda for the l2vpn meeting in DC All, please find a draft agenda for the L2VPN WG meeting in Washingto DC http://www.tla-group.com/~l2vpn/l2vpn-agenda-dc.htm It is not yet completed, but ping me if I missed any requests for agenda slots. Will try to finalize it tomorrow. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Wed Nov 3 10:04:45 2004 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 KAA15998 for ; Wed, 3 Nov 2004 10:04:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMw9-00078v-Af for l2vpn-web-archive@ietf.org; Wed, 03 Nov 2004 10:20:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMUP-0005hk-Gj; Wed, 03 Nov 2004 09:51:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMSG-0004mG-RO for l2vpn@megatron.ietf.org; Wed, 03 Nov 2004 09:49:44 -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 JAA14494 for ; Wed, 3 Nov 2004 09:49:42 -0500 (EST) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm1.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMhb-0006jQ-OY for l2vpn@ietf.org; Wed, 03 Nov 2004 10:05:36 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by tm1.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id iA3Enene027775 for ; Wed, 3 Nov 2004 09:49:40 -0500 (EST) Message-ID: <4188F023.BF4346C2@alcatel.com> Date: Wed, 03 Nov 2004 09:50:11 -0500 From: Mustapha Aissaoui Organization: Alcatel Networks Corporaton X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tm1.ca.alcatel.com id iA3Enene027775 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Subject: draft-aissaoui-l2vpn-vpws-iw-oam-02.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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable All, this draft specifies the procedures for OAM interworking for heterogeneous VPWS such as IP L2 interworking (arp-mediation), FR-ATM interworking, and Ethernet interworking. This draft complements draft-ietf-pwe3-oam-msg-map-01.txt, which covers the homogeneous VPWS. We have made an update to this draft to reflect the outstanding issues I listed in the San-Diego presentation. Specifically: Issue 1:=20 Defect loop operation. Single emulated end-to-end loop versus multiple coupled loops. Response: after a discussion with Dave Allan, we settled on a modified "coupled loop" model which we believe works in all scenarios addressed in the draft.=20 Issue 2:=20 Action over a ATM AC as a result of a PE receiving a PW defect=20 indication for a defect in the PW transmit direction or in the remote PE =93AC transmit=94 direction. Should the PE generate a AIS (as stated in the draft) or a RDI? Response: Dave Allan provided an analysis of the defects for all scenarios in the draft and we have now an agreement to treat a received RDI as a separate fault. This is reflected in this revision. Issue 3:=20 Check the behavior in the case of L2TPv3 PSN. Response: updated L2TPv3 based PW defect handling using StopCCN and CDN=20 messages. This is based on a discussion with Mark Townsley in San-Diego. We would like to request comments from the mailing list. Thank you. Mustapha.=20 http://www.ietf.org/internet-drafts/draft-aissaoui-l2vpn-vpws-iw-oam-02.t= xt From l2vpn-bounces@ietf.org Fri Nov 5 04:48:49 2004 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 EAA21986 for ; Fri, 5 Nov 2004 04:48:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0xq-0006N4-D6 for l2vpn-web-archive@ietf.org; Fri, 05 Nov 2004 05:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0SQ-0005sO-Dr; Fri, 05 Nov 2004 04:32:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Mp-0004ww-Rl for l2vpn@megatron.ietf.org; Fri, 05 Nov 2004 04:26:47 -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 EAA19630 for ; Fri, 5 Nov 2004 04:26:45 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0cU-0005oJ-H5 for l2vpn@ietf.org; Fri, 05 Nov 2004 04:43:01 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59QCDU008874 for ; Fri, 5 Nov 2004 10:26:13 +0100 Message-Id: <200411050926.iA59QCDU008874@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:26:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01C4C321.DE2329C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGXwLfy3Jb0sjSQGfih04SeeSdQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: SSL VPN Conference: Call for proposals 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.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C4C321.DE2329C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00CE_01C4C321.DE2329C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

 

The call for proposal dead line has been = extended to November 30.

 

Details = at:

 

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

 

------=_NextPart_000_00CE_01C4C321.DE2329C0-- From l2vpn-bounces@ietf.org Fri Nov 5 05:05:08 2004 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 FAA23809 for ; Fri, 5 Nov 2004 05:05:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1Dg-0006kb-Na for l2vpn-web-archive@ietf.org; Fri, 05 Nov 2004 05:21:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0SW-0005tB-9J; Fri, 05 Nov 2004 04:32:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0N5-0004xF-He for l2vpn@megatron.ietf.org; Fri, 05 Nov 2004 04:27:04 -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 EAA19666; Fri, 5 Nov 2004 04:27:01 -0500 (EST) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0cl-0005pM-2P; Fri, 05 Nov 2004 04:43:17 -0500 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id iA59L6r28614; Fri, 5 Nov 2004 10:21:06 +0100 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Fri, 05 Nov 2004 10:26:36 +0100 Message-ID: <418B474B.6030902@pi.se> Date: Fri, 05 Nov 2004 10:26:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: L2VPN , IETF Agenda via RT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Rick Wilder , Vach Kompella Subject: l2vpn agenda for the washington meeting 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit All, an updated agenda will be found at: http://www.tla-group.com/~l2vpn/l2vpn-agenda-dc.htm /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Mon Nov 8 10:59:23 2004 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 KAA23941 for ; Mon, 8 Nov 2004 10:59:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBvz-00057d-SF for l2vpn-web-archive@ietf.org; Mon, 08 Nov 2004 11:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBe2-0005ph-Qx; Mon, 08 Nov 2004 10:41:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBPp-0000iQ-QY for l2vpn@megatron.ietf.org; Mon, 08 Nov 2004 10:26:45 -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 KAA19048 for ; Mon, 8 Nov 2004 10:26:43 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBQN-0003zc-GC for l2vpn@ietf.org; Mon, 08 Nov 2004 10:27:20 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2004 16:47:22 +0100 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA8FQ7vL004714; Mon, 8 Nov 2004 16:26:08 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp433.cisco.com [10.61.65.177]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA06761; Mon, 8 Nov 2004 15:26:04 GMT Message-ID: <418F900D.1020704@cisco.com> Date: Mon, 08 Nov 2004 15:26:05 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kireeti@juniper.net, yakov@juniper.net Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org Subject: pair of pseudowires 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-02.txt Makes a number of references to pairs of pseudowires between PEs, but pseudowires are bidirectional, so it should be just a single PW between the PEs. - Stewart From l2vpn-bounces@ietf.org Wed Nov 10 11:15:02 2004 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 LAA25641 for ; Wed, 10 Nov 2004 11:15:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRv8f-0006E0-LC for l2vpn-web-archive@ietf.org; Wed, 10 Nov 2004 11:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuvt-0003NZ-SC; Wed, 10 Nov 2004 11:02:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuoV-0001En-Nd for l2vpn@megatron.ietf.org; Wed, 10 Nov 2004 10:55: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 KAA23303 for ; Wed, 10 Nov 2004 10:55:12 -0500 (EST) Received: from lin1-118-34-24.ciena.com ([63.118.34.24] helo=ripley.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRupQ-0005el-W6 for l2vpn@ietf.org; Wed, 10 Nov 2004 10:56:16 -0500 Received: from mdmail.ciena.com (HELO mdmxb01.ciena.com) (63.118.39.25) by ripley.ciena.com with ESMTP; 10 Nov 2004 11:09:48 -0500 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB00100B6BC@w2kmaexg02.wavesmithnet.com> From: "Shah, Himanshu" To: "'l2vpn@ietf.org'" Date: Wed, 10 Nov 2004 10:55:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: multicast pruning in VPLS, IPLS etc 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 We heard two presentations yesterday about multicast pruning for VPLS. We (IPLS authors) would like to offer yet another option which applies to VPLS as well. In IPLS we have discussed in detail about mp2p PW and we have a dedicated mp2p PW per IPLS instance dedicated for multicast/broadcast/unknown traffic. We think this mp2p PW concept applies very well also for multicast pruning. In this concept, PE would snoop local IGMP and PIM joins and leaves. For a first local join, PE would erect a mp2p PW for that multicast MAC address to all the member PEs of the VPLS/IPLS instance. And remove the PW for the last leave, remove the Mp2p PW. All the mechanisms for establishing and processing data packets is described in the draft wrt mp2p pw. End result is the existence of multiple PWs (one each for a multicast address). There are some restrictions, such as direct host connection, etc, but would work for most other cases that were described during the presentations. Any opinions?? /himanshu From l2vpn-bounces@ietf.org Wed Nov 10 16:09:21 2004 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 QAA03057 for ; Wed, 10 Nov 2004 16:09:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzjW-0007KV-W4 for l2vpn-web-archive@ietf.org; Wed, 10 Nov 2004 16:10:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzVc-0008EX-4d; Wed, 10 Nov 2004 15:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzEY-0003Vg-AB for l2vpn@megatron.ietf.org; Wed, 10 Nov 2004 15:38:26 -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 PAA25949 for ; Wed, 10 Nov 2004 15:38:23 -0500 (EST) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzFZ-0004wW-5D for l2vpn@ietf.org; Wed, 10 Nov 2004 15:39:29 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 10 Nov 2004 15:37:49 -0500 From: Irwin Lazar To: L2VPN Message-ID: In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB00100B6BC@w2kmaexg02.wavesmithnet.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3182945870_2022164" X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: Re: multicast pruning in VPLS, IPLS etc 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: 6ffdee8af20de249c24731d8414917d3 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3182945870_2022164 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Folks, If any of you are interested in submitting a presentation proposal for MPLScon on multicast in VPLS environments please let me know. I=B9m planning to have a round-table specifically focused on this issue, with various scenarios being explored (both within VPLS as well as in RFC-2547 environments). MPLScon is May 16-18 in NYC. The call for presentations is available at http://www.mplscon.com/speaker/submit_pres.html if you=B9d like more info about the conference. Thanks, Irwin From: "Shah, Himanshu" Date: Wed, 10 Nov 2004 08:55:07 -0700 To: Subject: multicast pruning in VPLS, IPLS etc We heard two presentations yesterday about multicast pruning for VPLS.=20 We (IPLS authors) would like to offer yet another option which applies to VPLS as well. In IPLS we have discussed in detail about mp2p PW and we have a dedicated mp2p PW per IPLS instance dedicated for multicast/broadcast/unknown traffic. We think this mp2p PW concept applies very well also for multicast pruning. In this concept, PE would snoop local IGMP and PIM joins and leaves. For a first local join, PE would erect a mp2p PW for that multicast MAC address=20 to all the member PEs of the VPLS/IPLS instance. And remove the PW for the last leave, remove the Mp2p PW. All the mechanisms for establishing and processing data packets is described in the draft wrt mp2p pw. End result is the existence of multiple PWs (one each for a multicast address). There are some restrictions, such as direct host connection, etc, but would work for most other cases that were described during the presentations. Any opinions??=20 /himanshu=20 --B_3182945870_2022164 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: multicast pruning in VPLS, IPLS etc Folks= ,
If any of you are interested in submitting a presentation proposal for MPLS= con on multicast in VPLS environments please let me know.  I’m pl= anning to have a round-table specifically focused on this issue, with variou= s scenarios being explored (both within VPLS as well as in RFC-2547 environm= ents).  MPLScon is May 16-18 in NYC.

The call for presentations is available at http://www.mplscon.com/speaker/submit_pres.html if you’d like more info about the conference.

Thanks,
Irwin

From: "Shah, Himanshu&quo= t; <hshah@ciena.com>
Date: Wed, 10 Nov 2004 08:55:07 -0700
To: <l2vpn@ietf.org>
Subject: multicast pruning in VPLS, IPLS etc

We heard two presentations yesterday about multicast
pruning for VPLS.

We (IPLS authors) would like to offer yet another option
which applies to VPLS as well.

In IPLS we have discussed in detail about mp2p PW and
we have a dedicated mp2p PW per IPLS instance dedicated
for multicast/broadcast/unknown traffic. We think this
mp2p PW concept applies very well also for multicast pruning.

In this concept, PE would snoop local IGMP and PIM joins and leaves.
For a first local join, PE would erect a mp2p PW for that multicast MAC add= ress
to all the member PEs of the VPLS/IPLS instance. And remove the
PW for the last leave, remove the Mp2p PW. All the mechanisms for
establishing and processing data packets is described in the draft wrt
mp2p pw.  End result is the existence of multiple PWs (one each for a =
multicast address).

There are some restrictions, such as direct host connection, etc, but would=
work for most other cases that were described during the presentations.
Any opinions??

/himanshu

--B_3182945870_2022164-- From l2vpn-bounces@ietf.org Thu Nov 11 10:34:19 2004 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 KAA23065 for ; Thu, 11 Nov 2004 10:34:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGz0-0004vX-I8 for l2vpn-web-archive@ietf.org; Thu, 11 Nov 2004 10:35:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGri-0007Ud-6C; Thu, 11 Nov 2004 10:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGo4-0006iy-1m for l2vpn@megatron.ietf.org; Thu, 11 Nov 2004 10:24:16 -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 KAA22015 for ; Thu, 11 Nov 2004 10:24:13 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGpE-0004gd-6H for l2vpn@ietf.org; Thu, 11 Nov 2004 10:25:28 -0500 Received: from lasserretplxp by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id HAA12913; Thu, 11 Nov 2004 07:23:36 -0800 (PST) Message-ID: <004201c4c802$691cc740$7201a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "Shah, Himanshu" , References: <8162DD929D7AD24CAD3FC5317CE41FB00100B6BC@w2kmaexg02.wavesmithnet.com> Date: Thu, 11 Nov 2004 16:23:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: Re: multicast pruning in VPLS, IPLS etc 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Himanshu, Pre-setting multipoint PWs with all peer PEs at the first join, and relying on PIM/IGMP snooping means that traffic is replicated in the core and filtered out at the egress points. This prevents traffic from being sent to receivers that did not join but it does not optimize traffic replication between PEs. Marc ----- Original Message ----- From: "Shah, Himanshu" To: Sent: Wednesday, November 10, 2004 4:55 PM Subject: multicast pruning in VPLS, IPLS etc > We heard two presentations yesterday about multicast > pruning for VPLS. > > We (IPLS authors) would like to offer yet another option > which applies to VPLS as well. > > In IPLS we have discussed in detail about mp2p PW and > we have a dedicated mp2p PW per IPLS instance dedicated > for multicast/broadcast/unknown traffic. We think this > mp2p PW concept applies very well also for multicast pruning. > > In this concept, PE would snoop local IGMP and PIM joins and leaves. > For a first local join, PE would erect a mp2p PW for that multicast MAC > address > to all the member PEs of the VPLS/IPLS instance. And remove the > PW for the last leave, remove the Mp2p PW. All the mechanisms for > establishing and processing data packets is described in the draft wrt > mp2p pw. End result is the existence of multiple PWs (one each for a > multicast address). > > There are some restrictions, such as direct host connection, etc, but > would > work for most other cases that were described during the presentations. > > Any opinions?? > > /himanshu > > From l2vpn-bounces@ietf.org Thu Nov 11 12:33:12 2004 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 MAA05576 for ; Thu, 11 Nov 2004 12:33:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIq5-00082s-9w for l2vpn-web-archive@ietf.org; Thu, 11 Nov 2004 12:34:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIht-0001WT-1W; Thu, 11 Nov 2004 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIVb-0005Ty-8Z for l2vpn@megatron.ietf.org; Thu, 11 Nov 2004 12:13:19 -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 MAA03689 for ; Thu, 11 Nov 2004 12:13:16 -0500 (EST) Received: from lin1-118-34-24.ciena.com ([63.118.34.24] helo=ripley.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIWn-0007Xb-0S for l2vpn@ietf.org; Thu, 11 Nov 2004 12:14:33 -0500 Received: from mdmail.ciena.com (HELO mdmxb01.ciena.com) (63.118.39.25) by ripley.ciena.com with ESMTP; 11 Nov 2004 12:28:00 -0500 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB00100B6CB@w2kmaexg02.wavesmithnet.com> From: "Shah, Himanshu" To: "'Marc Lasserre'" , l2vpn@ietf.org Date: Thu, 11 Nov 2004 12:13:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: RE: multicast pruning in VPLS, IPLS etc 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: cd26b070c2577ac175cd3a6d878c6248 That is not what I am proposing. Let me explain with an example. 1) there are 3 PEs in an VPLS/IPLS instance, PE-A, PE-B and PE-C 2) Lets say PE-A has 10 ACs in the VPLS/IPLS instance 3) PE-A does IGMP snooping on all 10 ACs 4) PE-A gets a join on AC-1 for Multicast address M1. 5) PE-A advertises PW label 101 to PE-B and PE-C (hence the mp2p PW). 6) PE-A includes label 101 and AC-1 in replication 7) PE-A gets anothoer join on AC-6, PE-A includes AC-6 in replication (note no new PW label advertisement) 8) When PE-B or PE-C receives a MAC-DA to M1, it uses label 101 to send the packet to PE-A 9) When PE-A receives packet on PW label 101, it replicates to AC-1 and and AC-6 10) Now lets say PE-B gets join for multicast address M1. He advertises PW label 102 to PE-A and PE-C. 11) If PE-C receives a packet to M1 DA, he would send the packet out to PE-A on PW label 101 and to PE-B on label 102. 12) and so on and so forth. This has been described in IPLS draft. What I am suggesting is a 'multicast PW' that is created for each multicast MAC address only when join is received. hope this clears up.. /himanshu -----Original Message----- From: Marc Lasserre [mailto:marc@riverstonenet.com] Sent: Thursday, November 11, 2004 10:24 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: Re: multicast pruning in VPLS, IPLS etc Himanshu, Pre-setting multipoint PWs with all peer PEs at the first join, and relying on PIM/IGMP snooping means that traffic is replicated in the core and filtered out at the egress points. This prevents traffic from being sent to receivers that did not join but it does not optimize traffic replication between PEs. Marc ----- Original Message ----- From: "Shah, Himanshu" To: Sent: Wednesday, November 10, 2004 4:55 PM Subject: multicast pruning in VPLS, IPLS etc > We heard two presentations yesterday about multicast > pruning for VPLS. > > We (IPLS authors) would like to offer yet another option > which applies to VPLS as well. > > In IPLS we have discussed in detail about mp2p PW and > we have a dedicated mp2p PW per IPLS instance dedicated > for multicast/broadcast/unknown traffic. We think this > mp2p PW concept applies very well also for multicast pruning. > > In this concept, PE would snoop local IGMP and PIM joins and leaves. > For a first local join, PE would erect a mp2p PW for that multicast MAC > address > to all the member PEs of the VPLS/IPLS instance. And remove the > PW for the last leave, remove the Mp2p PW. All the mechanisms for > establishing and processing data packets is described in the draft wrt > mp2p pw. End result is the existence of multiple PWs (one each for a > multicast address). > > There are some restrictions, such as direct host connection, etc, but > would > work for most other cases that were described during the presentations. > > Any opinions?? > > /himanshu > > From l2vpn-bounces@ietf.org Fri Nov 12 16:22:58 2004 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 QAA28435 for ; Fri, 12 Nov 2004 16:22:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSiu0-0007Em-Bb for l2vpn-web-archive@ietf.org; Fri, 12 Nov 2004 16:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSihO-00079z-2X; Fri, 12 Nov 2004 16:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiP8-0006GA-16 for l2vpn@megatron.ietf.org; Fri, 12 Nov 2004 15:52:22 -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 PAA20080 for ; Fri, 12 Nov 2004 15:52:19 -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 1CSiQW-0004aD-Dc for l2vpn@ietf.org; Fri, 12 Nov 2004 15:53:51 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id iACKpiDU006552; Fri, 12 Nov 2004 12:51:45 -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 iACKpi93006549; Fri, 12 Nov 2004 12:51:44 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 12 Nov 2004 12:51:44 -0800 (PST) From: Kireeti Kompella To: Stewart Bryant In-Reply-To: <418F900D.1020704@cisco.com> Message-ID: <20041112125130.T6396@kummer.juniper.net> References: <418F900D.1020704@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: l2vpn@ietf.org, yakov@juniper.net Subject: Re: pair of pseudowires 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad On Mon, 8 Nov 2004, Stewart Bryant wrote: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-02.txt > > Makes a number of references to pairs of pseudowires between PEs, > but pseudowires are bidirectional, so it should be just a single > PW between the PEs. Thanks, will fix. Kireeti. ------- From l2vpn-bounces@ietf.org Fri Nov 12 23:30:37 2004 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 XAA28423 for ; Fri, 12 Nov 2004 23:30:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSpa9-0002cd-SY for l2vpn-web-archive@ietf.org; Fri, 12 Nov 2004 23:32:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSpTt-0007Ou-Re; Fri, 12 Nov 2004 23:25:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSpDR-0003GL-Cz for l2vpn@megatron.ietf.org; Fri, 12 Nov 2004 23:08:46 -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 XAA27349 for ; Fri, 12 Nov 2004 23:08:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSpEg-0001k0-Sb for l2vpn@ietf.org; Fri, 12 Nov 2004 23:10:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 12 Nov 2004 20:08:53 -0800 X-BrightmailFiltered: true Received: from sajassi-w2k4.cisco.com (sjc-vpn2-36.cisco.com [10.21.112.36]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAD47WV2015803; Fri, 12 Nov 2004 20:07:51 -0800 (PST) Message-Id: <4.3.2.7.2.20041112062924.02843350@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Nov 2004 10:07:25 -0800 To: "Shah, Himanshu" , "'Marc Lasserre'" , l2vpn@ietf.org From: Ali Sajassi In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB00100B6CB@w2kmaexg02.wavesm ithnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.6 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: RE: multicast pruning in VPLS, IPLS etc 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.6 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Himanshu, A few comments/questions ... 1) The scheme you described still uses ingress PE replication, right ? 2) Since you are not doing any snooping over these set of MPtP PWs, I assume that for each multicast group, you will need to setup a set of MP2P PWs, right ? 3) If you need to setup the MP2P PWs for each multicast group, then there is a potential of dropping the initial customer multicast traffic because of the time it takes to establish the MP2P PWs (e.g., delay between out-of-band signalling and in-band signaling). This would also exist with BGP-based signaling scheme. So basically the common denominator among all these three multicast schemes, is the snooping of the ACs. And as we had some discussion during the meeting, there can be several potential issues with the snooping (specially with respect to PIM). I think we should concentrate on these snooping issues first. -Ali At 12:13 PM 11/11/2004 -0500, Shah, Himanshu wrote: >That is not what I am proposing. Let me explain with an example. >1) there are 3 PEs in an VPLS/IPLS instance, PE-A, PE-B and PE-C >2) Lets say PE-A has 10 ACs in the VPLS/IPLS instance >3) PE-A does IGMP snooping on all 10 ACs >4) PE-A gets a join on AC-1 for Multicast address M1. >5) PE-A advertises PW label 101 to PE-B and PE-C (hence the mp2p PW). >6) PE-A includes label 101 and AC-1 in replication >7) PE-A gets anothoer join on AC-6, PE-A includes AC-6 in replication > (note no new PW label advertisement) >8) When PE-B or PE-C receives a MAC-DA to M1, it uses label 101 to send > the packet to PE-A >9) When PE-A receives packet on PW label 101, it replicates to AC-1 and > and AC-6 >10) Now lets say PE-B gets join for multicast address M1. He advertises > PW label 102 to PE-A and PE-C. >11) If PE-C receives a packet to M1 DA, he would send the packet out to > PE-A on PW label 101 and to PE-B on label 102. >12) and so on and so forth. This has been described in IPLS draft. > >What I am suggesting is a 'multicast PW' that is created for each >multicast MAC address only when join is received. > >hope this clears up.. > >/himanshu > >-----Original Message----- >From: Marc Lasserre [mailto:marc@riverstonenet.com] >Sent: Thursday, November 11, 2004 10:24 AM >To: Shah, Himanshu; l2vpn@ietf.org >Subject: Re: multicast pruning in VPLS, IPLS etc > > >Himanshu, > >Pre-setting multipoint PWs with all peer PEs at the first join, and relying >on PIM/IGMP snooping means that traffic is replicated in the core and >filtered out at the egress points. This prevents traffic from being sent to >receivers that did not join but it does not optimize traffic replication >between PEs. > >Marc > >----- Original Message ----- >From: "Shah, Himanshu" >To: >Sent: Wednesday, November 10, 2004 4:55 PM >Subject: multicast pruning in VPLS, IPLS etc > > > > We heard two presentations yesterday about multicast > > pruning for VPLS. > > > > We (IPLS authors) would like to offer yet another option > > which applies to VPLS as well. > > > > In IPLS we have discussed in detail about mp2p PW and > > we have a dedicated mp2p PW per IPLS instance dedicated > > for multicast/broadcast/unknown traffic. We think this > > mp2p PW concept applies very well also for multicast pruning. > > > > In this concept, PE would snoop local IGMP and PIM joins and leaves. > > For a first local join, PE would erect a mp2p PW for that multicast MAC > > address > > to all the member PEs of the VPLS/IPLS instance. And remove the > > PW for the last leave, remove the Mp2p PW. All the mechanisms for > > establishing and processing data packets is described in the draft wrt > > mp2p pw. End result is the existence of multiple PWs (one each for a > > multicast address). > > > > There are some restrictions, such as direct host connection, etc, but > > would > > work for most other cases that were described during the presentations. > > > > Any opinions?? > > > > /himanshu > > > > From l2vpn-bounces@ietf.org Tue Nov 16 17:44:04 2004 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 RAA04447 for ; Tue, 16 Nov 2004 17:44:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC5j-0005la-9i for l2vpn-web-archive@ietf.org; Tue, 16 Nov 2004 17:46:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBuE-0001WV-Rb; Tue, 16 Nov 2004 17:34:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBJQ-0007Az-RI for l2vpn@megatron.ietf.org; Tue, 16 Nov 2004 16:56:32 -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 QAA23287 for ; Tue, 16 Nov 2004 16:56:31 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBLi-0002MS-Ij for l2vpn@ietf.org; Tue, 16 Nov 2004 16:58:54 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAGLuU8i014983 for ; Tue, 16 Nov 2004 15:56:30 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M32S7TJ>; Tue, 16 Nov 2004 16:56:30 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: l2vpn@ietf.org Date: Tue, 16 Nov 2004 16:56:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: 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: 93238566e09e6e262849b4f805833007 1) Section 8 of draft-sajassi-l2vpn-vpls-bridge-interop-00 says "And if the CE devices belonging to an ESI are IEEE bridges, then a partial-mesh of PWs can cause broadcast storms in the customer and provider networks" I understand that when a MAC address becomes unreachable, new messages destined for that MAC address will be replicated over all links, but does that qualify as a broadcast storm? Or is there more to it than that? 2) The next sentence in section 8: "Furthermore, it can cause multiple copies of a single frame to be received by the CE and/or PE devices" How can that happen? 3) A few paragraphs down: "Therefore, the detection time may be longer than the detection time needed for loop prevention inside the customer network" Apparently, partial mesh can lead to a loop in the customer network. I guess this is a consequence of the interworking between STP and VPLS, but don't understand the details. Is this easy to explain or should I take a course in STP? 4) Section 10 "For example, if a service instance is associated with four CEs at four different sites, then the maximum number of provider bridges (or PEs), that need to participate in that customer MAC address learning, is only three regardless of how many PEs are in the path of that service instance." I don't understand that. If four CE2 are connected to four PEs with a full-mesh of PWs between the PEs, don't all four PEs need to participate in MAC address learning? That's all (for now). Peter From l2vpn-bounces@ietf.org Wed Nov 17 01:37:47 2004 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 BAA17533 for ; Wed, 17 Nov 2004 01:37:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJUE-0008PO-Cy for l2vpn-web-archive@ietf.org; Wed, 17 Nov 2004 01:40:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJOT-0007KN-It; Wed, 17 Nov 2004 01:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJKK-0006HD-8z for l2vpn@megatron.ietf.org; Wed, 17 Nov 2004 01:30:00 -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 BAA16676 for ; Wed, 17 Nov 2004 01:29:59 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJMg-0008BI-GU for l2vpn@ietf.org; Wed, 17 Nov 2004 01:32:26 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2004 22:29:32 -0800 X-BrightmailFiltered: true Received: from sajassi-w2k4.cisco.com (sjc-vpn5-504.cisco.com [10.21.89.248]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAH6TPYs010255; Tue, 16 Nov 2004 22:29:26 -0800 (PST) Message-Id: <4.3.2.7.2.20041116214120.02777630@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Nov 2004 22:29:24 -0800 To: "Busschbach, Peter B (Peter)" , l2vpn@ietf.org From: Ali Sajassi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: 73734d43604d52d23b3eba644a169745 Peter, Please refer to my comments below ... At 04:56 PM 11/16/2004 -0500, Busschbach, Peter B (Peter) wrote: >1) Section 8 of draft-sajassi-l2vpn-vpls-bridge-interop-00 says "And if >the CE devices belonging to an ESI are IEEE bridges, then a partial-mesh >of PWs can cause broadcast storms in the customer and provider networks" > >I understand that when a MAC address becomes unreachable, new messages >destined for that MAC address will be replicated over all links, but does >that qualify as a broadcast storm? Or is there more to it than that? It is more than that. The type of broadcast storm that I am talking about is a permanent one as the result of a loop inside the customer network. When a customer site is dual-homed (even if its CE is singled-homed) or when it has backward connections, then a failure of PW in one direction can result in a loop within the customer network. >2) The next sentence in section 8: "Furthermore, it can cause multiple >copies of a single frame to be received by the CE and/or PE devices" > >How can that happen? One of the scenario that this can happen is during n-PE redundancy of section 9.2 of vpls-ldp draft. In this case, when the PW that carries the provider BPDU traffic between two n-PEs fail, then both n-PEs go into forwarding state and both forward the traffic of a given customer (VPLS) over their corresponding PWs. The receiving PE, receive two copies of each packets that gets brodcasted. >3) A few paragraphs down: "Therefore, the detection time may be longer >than the detection time needed for loop prevention inside the customer network" > >Apparently, partial mesh can lead to a loop in the customer network. I >guess this is a consequence of the interworking between STP and VPLS, but >don't understand the details. Is this easy to explain or should I take a >course in STP? Well, lets give it try first :-) In the bridge world, the Ethernet link failure is not uni-directional (if it fails, it fails in both direction). Furthermore, the bridge finds out about the link failure immediately and does its failure recovery (by switching to alternate links). In IEEE bridges, if a bridge stops receiving BPDUs over a link but doesn't get any failure indication for that link, it puts that link in the forwarding state (from its previous blocked state). 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, then it can result in a loop inside the customer network. >4) Section 10 "For example, if a service instance is associated with four >CEs at four different sites, then the maximum number of provider bridges >(or PEs), that need to participate in that customer MAC address learning, >is only three regardless of how many PEs are in the path of that service >instance." > >I don't understand that. If four CE2 are connected to four PEs with a >full-mesh of PWs between the PEs, don't all four PEs need to participate >in MAC address learning? 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. The reason for this is that the data path through other nine bridges along the end-to-end path is PtP and thus no MAC address learning is needed for those nine bridges. IEEE 802.1ad does this by using the GVRP and disabling MAC address learning for the VLANs that have only a single ingress and egress point on that bridge. >That's all (for now). I am glad that you are going through these issues. I think these are important issues that providers need to be aware of when offering multipoint Ethernet service. -Ali >Peter From l2vpn-bounces@ietf.org Wed Nov 17 11:01:04 2004 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 LAA11758 for ; Wed, 17 Nov 2004 11:01:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSHS-0004Lv-HV for l2vpn-web-archive@ietf.org; Wed, 17 Nov 2004 11:03:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUS99-0000hy-Qg; Wed, 17 Nov 2004 10:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUS5I-00084T-AN for l2vpn@megatron.ietf.org; Wed, 17 Nov 2004 10:51:04 -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 KAA10909 for ; Wed, 17 Nov 2004 10:51:01 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUS7j-00047G-1M for l2vpn@ietf.org; Wed, 17 Nov 2004 10:53:35 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAHFoU4g023174 for ; Wed, 17 Nov 2004 09:50:30 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M32TXDZ>; Wed, 17 Nov 2004 10:50:30 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Ali Sajassi'" , l2vpn@ietf.org Date: Wed, 17 Nov 2004 10:50:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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: 37af5f8fbf6f013c5b771388e24b09e7 Hi Ali, Thanks for your response. If you don't mind, I do have a few follow-up questions. Peter > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Wednesday, November 17, 2004 1:29 AM > To: Busschbach, Peter B (Peter); l2vpn@ietf.org > Subject: Re: Questions about > draft-sajassi-l2vpn-vpls-bridge-interop-00 > [snipped] > >2) The next sentence in section 8: "Furthermore, it can > cause multiple > >copies of a single frame to be received by the CE and/or PE devices" > > > >How can that happen? > > One of the scenario that this can happen is during n-PE redundancy of > section 9.2 of vpls-ldp draft. In this case, when the PW that > carries the > provider BPDU traffic between two n-PEs fail, then both n-PEs go into > forwarding state and both forward the traffic of a given > customer (VPLS) > over their corresponding PWs. The receiving PE, receive two > copies of each > packets that gets brodcasted. > 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? 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. > > >3) A few paragraphs down: "Therefore, the detection time may > be longer > >than the detection time needed for loop prevention inside > the customer network" > > > >Apparently, partial mesh can lead to a loop in the customer > network. I > >guess this is a consequence of the interworking between STP > and VPLS, but > >don't understand the details. Is this easy to explain or > should I take a > >course in STP? > > Well, lets give it try first :-) In the bridge world, the > Ethernet link > failure is not uni-directional (if it fails, it fails in > both direction). > Furthermore, the bridge finds out about the link failure > immediately and > does its failure recovery (by switching to alternate links). In IEEE > bridges, if a bridge stops receiving BPDUs over a link but > doesn't get any > failure indication for that link, it puts that link in the > forwarding state > (from its previous blocked state). 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? > 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? > then it can result in a loop > inside the customer > network. > > > >4) Section 10 "For example, if a service instance is > associated with four > >CEs at four different sites, then the maximum number of > provider bridges > >(or PEs), that need to participate in that customer MAC > address learning, > >is only three regardless of how many PEs are in the path of > that service > >instance." > > > >I don't understand that. If four CE2 are connected to four > PEs with a > >full-mesh of PWs between the PEs, don't all four PEs need to > participate > >in MAC address learning? > > 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? > [snipped to the end] From l2vpn-bounces@ietf.org Thu Nov 18 01:42:14 2004 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 BAA05745 for ; Thu, 18 Nov 2004 01:42:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUg2J-0001C9-3d for l2vpn-web-archive@ietf.org; Thu, 18 Nov 2004 01:44:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfwl-0001gP-H9; Thu, 18 Nov 2004 01:39:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfwG-0001SN-5Q for l2vpn@megatron.ietf.org; Thu, 18 Nov 2004 01:38:40 -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 BAA05207 for ; Thu, 18 Nov 2004 01:38:38 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUfyp-00016C-7w for l2vpn@ietf.org; Thu, 18 Nov 2004 01:41:19 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2004 22:38:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from sajassi-w2k4.cisco.com (sjc-vpn1-369.cisco.com [10.21.97.113]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAI6c5W0002828; Wed, 17 Nov 2004 22:38:06 -0800 (PST) Message-Id: <4.3.2.7.2.20041117210911.027a5300@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Nov 2004 22:38:02 -0800 To: "Busschbach, Peter B (Peter)" , "'Ali Sajassi'" , l2vpn@ietf.org From: Ali Sajassi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: 7fa173a723009a6ca8ce575a65a5d813 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] From l2vpn-bounces@ietf.org Thu Nov 18 16:39:48 2004 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 QAA19245 for ; Thu, 18 Nov 2004 16:39:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUu33-0007fP-Ug for l2vpn-web-archive@ietf.org; Thu, 18 Nov 2004 16:42:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtiJ-0007m1-5z; Thu, 18 Nov 2004 16:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtIf-0007Ou-Tu for l2vpn@megatron.ietf.org; Thu, 18 Nov 2004 15:54:42 -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 PAA09349 for ; Thu, 18 Nov 2004 15:54:39 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtLM-0004fy-GM for l2vpn@ietf.org; Thu, 18 Nov 2004 15:57:28 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAIKscZ2020481 for ; Thu, 18 Nov 2004 14:54:39 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M32V6GA>; Thu, 18 Nov 2004 15:54:38 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Ali Sajassi'" , l2vpn@ietf.org Date: Thu, 18 Nov 2004 15:54:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Ali, Thanks for the detailed reponse. Things are becoming clearer. I discovered that one of the issues that causes much of my confusion is the way Ethernet deals with Spanning Trees. I tend to think of a Spanning Tree as a tree from which entire links are pruned. Instead, in the ethernet world, it is a matter of blocking ports. Someday, hopefully, I will be able to internalize that. A few things: Ali> There are scenarios with dual-homing of a customer site or Ali> redundant Ali> connection via another network, where a unidirectional Ali> failure of PW can Ali> result in a loop - it would be easier to show these Ali> scenarios via figures. It would be very helpful for me to see a detailed example that shows exactly what can go wrong and why. If at some point in time you develop such material that you are willing to share, I would greatly appreciate it. Ali> Now if you Ali> consider three CEs, then there can be only a single Y Ali> branch along the path Ali> between the three CEs and therefore, only the PE with Y Ali> branch needs to Ali> learn MAC address. With this optimization, the question is Ali> not if a PE can Ali> learn customer MAC addresses but whether a PE needs to Ali> learn customer MAC Ali> addresses. With three CEs you can create an architecture in which *none* of the PEs needs to perform MAC address learning: create point-to-point links between the CEs and let one of the CEs function as the hub node. I understand your point that you don't necessarily need to do MAC learning in every PE. However, it is not clear to me what the ultimate relevance of that is. With N CEs in a regular VPLS architecture, all N PEs need to do MAC address learning. However, as you point out, you could choose for a different architecture: create a VPLS among a subset of PEs (including the empty subset) and connect all remaining PEs to that subset via point-to-point PWs. These remaining PEs then don't need to perform MAC address learning. By doing this, you trade data plane efficiency off against the number of MAC entries that you store in the network. The question is: do you think this fine-tuning of VPLS is important? It seems to me that the benefit is small and the operational complexity significant. Peter P.S. A completely different question (not just for Ali, but for anyone who reads this email): when I check my own emails in the email archive (e.g. http://www.ietf.org/mail-archive/web/l2vpn/current/msg00793.html ) I see that the lines are not trunkated. Instead, you need to use the scroll bar to scroll to the end of a sentence. This is not the case for emails from others in the same archive. I have tried to solve it and even worked with our IT department, but to no avail. When you receive my emails, do they appear on your screen as they do in the archive (i.e. with scroll bar)? Any idea what to do about it? From l2vpn-bounces@ietf.org Thu Nov 18 21:47:04 2004 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 VAA20601 for ; Thu, 18 Nov 2004 21:47:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUyqT-00070Y-91 for l2vpn-web-archive@ietf.org; Thu, 18 Nov 2004 21:49:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUym1-0005QJ-1B; Thu, 18 Nov 2004 21:45:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUyYy-0001dJ-C2 for l2vpn@megatron.ietf.org; Thu, 18 Nov 2004 21:31:52 -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 VAA19080 for ; Thu, 18 Nov 2004 21:31:50 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUybi-0006a5-34 for l2vpn@ietf.org; Thu, 18 Nov 2004 21:34:42 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 18 Nov 2004 18:31:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from sajassi-w2k4.cisco.com (sjc-vpn4-188.cisco.com [10.21.80.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAJ2VJYs012726; Thu, 18 Nov 2004 18:31:20 -0800 (PST) Message-Id: <4.3.2.7.2.20041118175841.0284ca90@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Nov 2004 18:31:16 -0800 To: "Busschbach, Peter B (Peter)" , "'Ali Sajassi'" , l2vpn@ietf.org From: Ali Sajassi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: 7fa173a723009a6ca8ce575a65a5d813 Peter, At 03:54 PM 11/18/2004 -0500, Busschbach, Peter B (Peter) wrote: >Ali, > >Thanks for the detailed reponse. Things are becoming clearer. I discovered >that one of the issues that causes much of my confusion is the way >Ethernet deals with Spanning Trees. I tend to think of a Spanning Tree as >a tree from which entire links are pruned. Instead, in the ethernet world, >it is a matter of blocking ports. Someday, hopefully, I will be able to >internalize that. And the blocking doesn't have to be for all the VLANs - e.g., it can be for a group of VLANs by associated that group of VLANs with a one instance of spanning tree by running MSTP. Therefore, by allowing multiple spanning trees (typically 2 or 3), you can have a nice load balancing across different links. >A few things: > >Ali> There are scenarios with dual-homing of a customer site or >Ali> redundant >Ali> connection via another network, where a unidirectional >Ali> failure of PW can >Ali> result in a loop - it would be easier to show these >Ali> scenarios via figures. > >It would be very helpful for me to see a detailed example that shows >exactly what can go wrong and why. If at some point in time you develop >such material that you are willing to share, I would greatly appreciate it. Sure, I will work on it and will add it as an appendix to my bridge-interop draft. >Ali> Now if you >Ali> consider three CEs, then there can be only a single Y >Ali> branch along the path >Ali> between the three CEs and therefore, only the PE with Y >Ali> branch needs to >Ali> learn MAC address. With this optimization, the question is >Ali> not if a PE can >Ali> learn customer MAC addresses but whether a PE needs to >Ali> learn customer MAC >Ali> addresses. > >With three CEs you can create an architecture in which *none* of the PEs >needs to perform MAC address learning: create point-to-point links between >the CEs and let one of the CEs function as the hub node. True, but this is no longer a VPLS service and instead it is a VPWS service. >I understand your point that you don't necessarily need to do MAC >learning in every PE. However, it is not clear to me what the ultimate >relevance of that is. With N CEs in a regular VPLS architecture, all N PEs >need to do MAC address learning. However, as you point out, you could >choose for a different architecture: create a VPLS among a subset of PEs >(including the empty subset) and connect all remaining PEs to that subset >via point-to-point PWs. These remaining PEs then don't need to perform MAC >address learning. By doing this, you trade data plane efficiency off >against the number of MAC entries that you store in the network. The >question is: do you think this fine-tuning of VPLS is important? It seems >to me that the benefit is small and the operational complexity significant. This depends on what flavor of VPLS we are talking about. With VPLS H-VPLS with either QinQ or MPLS access network, you will have at least four bridging nodes along the path of any two CEs. So if a customer has three sites as they are connected to the provider network as follow: CE1 ----- u-PE1---------n-PE1 -----------------------n-PE2 --------------u-PE2 ------ CE2 | |--------------------u-PE-3 ------ CE3 then the only PEs that need to learn MAC addresses for that customer is n-PE2. Also when you use QinQ access network (802.1ad), then you can take advantage of 802.1ad protocols for figuring out which PE doesn't need to learn customer MAC addresses and disable MAC address learning on those PE dynamically without any configuration what so ever. This is specified in 802.1ad standard. With MPLS access network one can also leverage the 802.1ad protocol as well and achieve the same result. So even with MPLS access network you will setup the PWs for a give customer as before and then run the .1ad protocol on your PEs to decided which PEs should disable MAC address learning for which customers. This should disabling feature should be transparent and orthogonal to your PW setup. -Ali >Peter > > >P.S. > >A completely different question (not just for Ali, but for anyone who >reads this email): when I check my own emails in the email archive (e.g. >http://www.ietf.org/mail-archive/web/l2vpn/current/msg00793.html ) I see >that the lines are not trunkated. Instead, you need to use the scroll bar >to scroll to the end of a sentence. This is not the case for emails from >others in the same archive. I have tried to solve it and even worked with >our IT department, but to no avail. > >When you receive my emails, do they appear on your screen as they do in >the archive (i.e. with scroll bar)? Any idea what to do about it?