From exim@www1.ietf.org Tue Jul 8 13:46:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01754 for ; Tue, 8 Jul 2003 13:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwXW-00005v-CP for l2vpn-archive@odin.ietf.org; Tue, 08 Jul 2003 13:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Hk6FG000357 for l2vpn-archive@odin.ietf.org; Tue, 8 Jul 2003 13:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwXW-00005g-97 for l2vpn-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 13:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01727 for ; Tue, 8 Jul 2003 13:46:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZwXU-0003rK-00 for l2vpn-web-archive@ietf.org; Tue, 08 Jul 2003 13:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZwXT-0003rG-00 for l2vpn-web-archive@ietf.org; Tue, 08 Jul 2003 13:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwXR-0008Vs-Pg; Tue, 08 Jul 2003 13:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwWe-0008V2-RS for l2vpn@optimus.ietf.org; Tue, 08 Jul 2003 13:45:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01689 for ; Tue, 8 Jul 2003 13:45:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZwWc-0003qX-00 for l2vpn@ietf.org; Tue, 08 Jul 2003 13:45:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ZwWc-0003qT-00 for l2vpn@ietf.org; Tue, 08 Jul 2003 13:45:10 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19ZwWb-000FfW-Bu for l2vpn@ietf.org; Tue, 08 Jul 2003 17:45:09 +0000 Date: Tue, 8 Jul 2003 10:44:39 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <77735868953.20030708104439@psg.com> To: l2vpn@ietf.org Subject: Fwd: WG Action: Layer 2 Virtual Private Networks (l2vpn) Working Group In-Reply-To: <200307081528.LAA26627@ietf.org> References: <200307081528.LAA26627@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI below, folks. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: The IESG To: Cc: rwilder@masergy.com, vkompella@timetra.com, loa@pi.se Date: Tuesday, July 8, 2003, 8:28:27 AM Subject: WG Action: Layer 2 Virtual Private Networks (l2vpn) Working Group ===8<==============Original message text=============== A new IETF working group has been formed in the Internet Area of the IETF. For additional information, please contact the Area Directors or the WG Chairs. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Current Status: Active Working Group Chair(s): Rick Wilder Vach Kompella Loa Andersson Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Thomas Narten Technical Advisor(s): Russell Housley Alex Zinin Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn Archive: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/maillist.html Description of Working Group: Alex Zinin is the routing advisor. Russ Housley is the security advisor. This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs). The WG is responsible for standardization of the following solutions: 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network. 3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN segment or a point- to-point circuit. The WG will address intra-AS scenarios only at this point (other scenarios will be considered for inclusion in the updated charter when the current one is completed.) As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG. L2VPN WG will review proposed protocol extensions for L2VPNs before they are recommended to appropriate protocol-specific WGs. The WG will work on the following items. Adding new work items will require rechartering. 1. Discovery of PEs participating in L2 service, and topology of required connectivity 2. Signaling of l2vpn related information for the purpose of setup and maintenance of l2vpn circuits. As much as possible PWE3 signaling procedures should be used 3. Solution documents (providing the framework for a specific solution, should include info on how discovery, signaling, and encaps work together, include security, AS as a separate document) 4. MIBs 5. L2VPN-specific OAM extensions--extensions to existing OAM solutions for VPLS, VPWS, and IP-only L2VPNs. Where necessary, the WG will coordinate its activities with IEEE 802.1 Goals and Milestones: Jul 03 Submit L2 requirements to IESG for publication as Informational RFC Jul 03 Submit L2 framework to IESG for publication as Informational RFC Jul 03 Identify VPLS and VPWS solutions for the WG Aug 03 Submit an I-D describing MIB for VPLS Aug 03 Submit an I-D describing MIB for VPWS Aug 03 Submit an I-D on OAM for VPLS Aug 03 Submit an I-D on OAM for VPWS Dec 03 Submit VPLS solution documents to IESG Dec 03 Submit VPWS solution documents to IESG Jan 04 Submit IP-only L2VPN solution documents to IESG Feb 04 Submit MIB for VPLS to IESG Feb 04 Submit MIB for VPWS to IESG Mar 04 Submit OAM for VPWS to IESG Mar 04 Submit OAM for VPLS to IESG Apr 04 Submit OAM for IP L2VPN to IESG ===8<===========End of original message text=========== From exim@www1.ietf.org Wed Jul 16 04:25:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20748 for ; Wed, 16 Jul 2003 04:25:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chbI-0001wc-50 for l2vpn-archive@odin.ietf.org; Wed, 16 Jul 2003 04:25:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G8POY4007468 for l2vpn-archive@odin.ietf.org; Wed, 16 Jul 2003 04:25:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chbH-0001wN-UD for l2vpn-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 04:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20706 for ; Wed, 16 Jul 2003 04:25:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chbC-0004Z2-00 for l2vpn-web-archive@ietf.org; Wed, 16 Jul 2003 04:25:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19chb6-0004Yv-00 for l2vpn-web-archive@ietf.org; Wed, 16 Jul 2003 04:25:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chax-0001sX-LV; Wed, 16 Jul 2003 04:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chaL-0001rX-EJ for l2vpn@optimus.ietf.org; Wed, 16 Jul 2003 04:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20629; Wed, 16 Jul 2003 04:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chaI-0004YK-00; Wed, 16 Jul 2003 04:24:22 -0400 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by ietf-mx with esmtp (Exim 4.12) id 19cha7-0004Xu-00; Wed, 16 Jul 2003 04:24:11 -0400 Received: from pi.se ([81.160.245.12]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6G8Mqk26103; Wed, 16 Jul 2003 10:22:53 +0200 (MEST) Message-ID: <3F1509DE.9020902@pi.se> Date: Wed, 16 Jul 2003 10:16:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ppvpn@nortelnetworks.com, l2vpn@ietf.org, l3vpn@ietf.org Subject: the ppvpn agenda in Vienna: l3vpn and l2vpn Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, as result of the decission on splitting the ppvpn group in one l3vpn wg and one l2vpn wg came close to the actual meeting it has not been time to update the IETF online agendas. However, the meeting Wednesday July 16th at 1PM will be the first meeting of the l3vpn working group and the meeting Thursday July 17th at 1PM will be the first meeting of the l2vpn working group. Both these meetings shows up as ppvpn meetings on the online agenda. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From exim@www1.ietf.org Thu Jul 17 15:00:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17881 for ; Thu, 17 Jul 2003 15:00:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDzH-0002pv-95 for l2vpn-archive@odin.ietf.org; Thu, 17 Jul 2003 15:00:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HJ0Jrh010897 for l2vpn-archive@odin.ietf.org; Thu, 17 Jul 2003 15:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDzH-0002pg-3C for l2vpn-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 15:00:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17873 for ; Thu, 17 Jul 2003 15:00:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDzE-0000ju-00 for l2vpn-web-archive@ietf.org; Thu, 17 Jul 2003 15:00:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dDz8-0000jq-00 for l2vpn-web-archive@ietf.org; Thu, 17 Jul 2003 15:00:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDyz-0002oY-Uh; Thu, 17 Jul 2003 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDyy-0002nv-HJ for l2vpn@optimus.ietf.org; Thu, 17 Jul 2003 15:00:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17844 for ; Thu, 17 Jul 2003 14:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDyv-0000jb-00 for l2vpn@ietf.org; Thu, 17 Jul 2003 14:59:57 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19dDyk-0000j1-00 for l2vpn@ietf.org; Thu, 17 Jul 2003 14:59:46 -0400 Received: (qmail 22379 invoked from network); 17 Jul 2003 19:09:40 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 17 Jul 2003 19:09:40 -0000 Received: from alcatel.com ([138.120.250.22]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HI6NEL00.54C; Thu, 17 Jul 2003 14:59:09 -0400 Message-ID: <3F16F1E1.6E853B2E@alcatel.com> Date: Thu, 17 Jul 2003 14:58:41 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2vpn@ietf.org Subject: [Isis-wg] Re: Inconsistent view of routers over a LAN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, During the L2VPN meeting today, I believe the L2VPN WG needs to consider the critical issue of loss of communication among CE routers on an emulated LAN, when using solutions such as : http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-bgp-00.txt http://www.ietf.org/internet-drafts/draft-radoaca-ppvpn-gvpls-02.txt http://www.ietf.org/internet-drafts/draft-shah-ppvpn-ipls-02.txt Here is an email from Tony Li discussing this critical issue on the L2VPN mailing list: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/msg00045.html Section 5.1 and 5.3 of http://www.ietf.org/internet-drafts/draft-lee-ppvpn-hybrid-vpls-01.txt discusses some of the impact of these issues, for those interested. Regards Cheng-Yin p.s The issue with CE bridges using these solutions have been discussed in IEEE 802.1 mailing list as well as in PPVPN mailing list in the past. From exim@www1.ietf.org Thu Jul 17 15:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19845 for ; Thu, 17 Jul 2003 15:29:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dERB-00049n-4d for l2vpn-archive@odin.ietf.org; Thu, 17 Jul 2003 15:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HJT9lJ015979 for l2vpn-archive@odin.ietf.org; Thu, 17 Jul 2003 15:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dERA-00049e-Iw for l2vpn-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 15:29:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19839 for ; Thu, 17 Jul 2003 15:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dER9-0000t1-00 for l2vpn-web-archive@ietf.org; Thu, 17 Jul 2003 15:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dER3-0000sy-00 for l2vpn-web-archive@ietf.org; Thu, 17 Jul 2003 15:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dER2-00048p-W4; Thu, 17 Jul 2003 15:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dEQS-00048N-A1 for l2vpn@optimus.ietf.org; Thu, 17 Jul 2003 15:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19785 for ; Thu, 17 Jul 2003 15:28:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dEQQ-0000so-00 for l2vpn@ietf.org; Thu, 17 Jul 2003 15:28:22 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19dEQF-0000sa-00 for l2vpn@ietf.org; Thu, 17 Jul 2003 15:28:12 -0400 Received: (qmail 7214 invoked from network); 17 Jul 2003 19:38:36 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 17 Jul 2003 19:38:36 -0000 Received: from alcatel.com ([138.120.250.22]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HI6OQT00.32K; Thu, 17 Jul 2003 15:28:05 -0400 Message-ID: <3F16F8A9.8126E8C1@alcatel.com> Date: Thu, 17 Jul 2003 15:27:37 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2vpn@ietf.org Subject: CE-based VPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vach, Loa, The L2VPN charter states "The WG is responsible for standardization of the following solutions: 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. ... " This is the service that CE-based VPLS (where CE is provisioned by provider) provides. I believe it does allow standard Ethernet devices to communicate with each other as if they were connected to a common LAN segment. So I think CE-based VPLS is within the scope of the L2VPN charter (unless the charter is changed to explicitly exclude CE-based VPLS). I believe the following drafts do not currently allow standard Ethernet devices to communicate with each other as if they were connected to a common LAN segment: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-bgp-00.txt http://www.ietf.org/internet-drafts/draft-radoaca-ppvpn-gvpls-02.txt http://www.ietf.org/internet-drafts/draft-shah-ppvpn-ipls-02.txt I believe this draft does allow standard Ethernet devices to communicate with each other as if they were connected to a common LAN segment: http://www.ietf.org/internet-drafts/draft-lee-ppvpn-hybrid-vpls-01.txt Thanks Cheng-Yin From exim@www1.ietf.org Fri Jul 18 14:01:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06592 for ; Fri, 18 Jul 2003 14:01:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZXY-0007MV-Mz for l2vpn-archive@odin.ietf.org; Fri, 18 Jul 2003 14:01:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6II18Cb028295 for l2vpn-archive@odin.ietf.org; Fri, 18 Jul 2003 14:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZXY-0007MI-IN for l2vpn-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 14:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06585 for ; Fri, 18 Jul 2003 14:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dZXW-0002K7-00 for l2vpn-web-archive@ietf.org; Fri, 18 Jul 2003 14:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dZXQ-0002K4-00 for l2vpn-web-archive@ietf.org; Fri, 18 Jul 2003 14:01:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZXQ-0007LS-Ie; Fri, 18 Jul 2003 14:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dZWg-0007Kn-7t for l2vpn@optimus.ietf.org; Fri, 18 Jul 2003 14:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06558 for ; Fri, 18 Jul 2003 14:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dZWd-0002Ji-00 for l2vpn@ietf.org; Fri, 18 Jul 2003 14:00:11 -0400 Received: from mailf.telia.com ([194.22.194.25]) by ietf-mx with esmtp (Exim 4.12) id 19dZWO-0002JS-00 for l2vpn@ietf.org; Fri, 18 Jul 2003 14:00:00 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h6IFTY6j020063; Fri, 18 Jul 2003 17:29:34 +0200 (CEST) X-Original-Recipient: rick_h_wilder@yahoo.com Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h6IFTXc20515; Fri, 18 Jul 2003 17:29:33 +0200 (CEST) Message-ID: <3F1810DF.6040109@pi.se> Date: Fri, 18 Jul 2003 17:23:11 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn CC: Rick Wilder , Vach Kompella , Thomas Narten , Alex Zinin , Scott Bradner Subject: opinion on number of vpls soluions - polling operators in the l2vpn wg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Working Group, we would like to solicit the input of operators represented in the l2vpn working group on the discusion on the number of vpls solutions to be progressed and standardized by the IETF. This have been discussed on the mailing list and ws discussed over again at the l2vpn wg meeting in Vienna. We know that operators some times, e.g. for competitive reason, don't want to speak up in public, therefore it is possible to send a mail to Scott Bradner sob@harvard.edu He will make sure that the response will be kept annonymous, and only the content made known to the wg chairs. The rest of you can send mail directly to the wg-chairs, with a copy to the wg mailing list as you see fit. What we would like to is: - do you prefer one single solution for the vpls space - do you prefer multiple solutions vpls space - do care if there is any solution at all for the vpls space - do you care about the number of solutions at all, as long as your prefered solution is represented. We don't plan to make the "votes" public, just tell the working group the sense of the operator community. We appreciate your support in this. Rick, Vach and Loa -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From exim@www1.ietf.org Sun Jul 20 19:40:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01078 for ; Sun, 20 Jul 2003 19:40:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNmp-0005uw-Q1 for l2vpn-archive@odin.ietf.org; Sun, 20 Jul 2003 19:40:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KNeFcZ022742 for l2vpn-archive@odin.ietf.org; Sun, 20 Jul 2003 19:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNmp-0005uj-LZ for l2vpn-web-archive@optimus.ietf.org; Sun, 20 Jul 2003 19:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01067 for ; Sun, 20 Jul 2003 19:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eNmo-0005w4-00 for l2vpn-web-archive@ietf.org; Sun, 20 Jul 2003 19:40:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eNmi-0005vu-00 for l2vpn-web-archive@ietf.org; Sun, 20 Jul 2003 19:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNmb-0005tY-Ic; Sun, 20 Jul 2003 19:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNlo-0005sr-CA for l2vpn@optimus.ietf.org; Sun, 20 Jul 2003 19:39:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01058 for ; Sun, 20 Jul 2003 19:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eNlm-0005vk-00 for l2vpn@ietf.org; Sun, 20 Jul 2003 19:39:10 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19eNlb-0005vO-00 for l2vpn@ietf.org; Sun, 20 Jul 2003 19:38:59 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6KNc4u74905; Sun, 20 Jul 2003 16:38:04 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h6KNc4D29021; Sun, 20 Jul 2003 16:38:04 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sun, 20 Jul 2003 16:38:04 -0700 (PDT) From: Kireeti Kompella To: Cheng-Yin Lee cc: l2vpn@ietf.org Subject: Re: CE-based VPLS In-Reply-To: <3F16F8A9.8126E8C1@alcatel.com> Message-ID: <20030720155356.A28944@kummer.juniper.net> References: <3F16F8A9.8126E8C1@alcatel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Cheng-Lin, On Thu, 17 Jul 2003, Cheng-Yin Lee wrote: > The L2VPN charter states > "The WG is responsible for standardization of the following solutions: > 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN > across an IP and an MPLS-enabled IP network, allowing standard > Ethernet devices communicate with each other as if they were > connected to a common LAN segment. > ... > " > > This is the service that CE-based VPLS (where CE is provisioned by > provider) provides. It would be interesting (but ultimately irrelevant) to understand how you made the leap from "service that emulates LAN" to "CE-based VPLS ... where CE is provisioned by provider". The charter does not say who provisions the VPLS, although since L2VPN emerged from PPVPN, it seems logical that the provider provisions it. Furthermore, the charter doesn't mention "CE-based". If by "CE", you mean (as in rfc2547bis) a device owned, operated and managed by the customer, then "CE provisioned by the provider" is an oxymoron. If you mean something else, it would be useful to define it; and furthermore, to read the decoupled VPLS and the H-VPLS drafts. > So I think CE-based VPLS is within the scope of the L2VPN > charter (unless the charter is changed to explicitly exclude CE-based > VPLS). The parenthetical statement is not a bad idea. Chairs? ADs? > I believe the following drafts do not currently allow standard Ethernet > devices to communicate with each other as if they were connected to a > common LAN segment: > http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-bgp-00.txt > http://www.ietf.org/internet-drafts/draft-radoaca-ppvpn-gvpls-02.txt > http://www.ietf.org/internet-drafts/draft-shah-ppvpn-ipls-02.txt There is an existence proof that most (if not all) of the above _do_ in fact allow standard Ethernet devices to communicate with each other as if they were on a LAN. So, your belief does not jive with reality. Step into any number of vendor or provider labs for proof. If there are corner cases where the "VPLS" in the above drafts fails to emulate a LAN perfectly, please communicate that to the group. This would be productive, and help the group understand whether the failure was systemic or the artifact of particular implementations, and thus guide further standards development. Kireeti. From exim@www1.ietf.org Mon Jul 21 06:46:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23627 for ; Mon, 21 Jul 2003 06:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYBF-00088i-Dy for l2vpn-archive@odin.ietf.org; Mon, 21 Jul 2003 06:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LAk9ju031284 for l2vpn-archive@odin.ietf.org; Mon, 21 Jul 2003 06:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYBD-00088V-Tj for l2vpn-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 06:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23593 for ; Mon, 21 Jul 2003 06:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eYBA-0001h3-00 for l2vpn-web-archive@ietf.org; Mon, 21 Jul 2003 06:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eYB4-0001h0-00 for l2vpn-web-archive@ietf.org; Mon, 21 Jul 2003 06:45:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYB6-000885-P3; Mon, 21 Jul 2003 06:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eYAf-00087d-TR for l2vpn@optimus.ietf.org; Mon, 21 Jul 2003 06:45:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23583 for ; Mon, 21 Jul 2003 06:45:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eYAb-0001gp-00 for l2vpn@ietf.org; Mon, 21 Jul 2003 06:45:29 -0400 Received: from mailf.telia.com ([194.22.194.25]) by ietf-mx with esmtp (Exim 4.12) id 19eYAQ-0001gN-00 for l2vpn@ietf.org; Mon, 21 Jul 2003 06:45:18 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h6LAisev017905; Mon, 21 Jul 2003 12:44:54 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h6LAisc27343; Mon, 21 Jul 2003 12:44:54 +0200 (CEST) Message-ID: <3F1BC2A0.1010905@pi.se> Date: Mon, 21 Jul 2003 12:38:24 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: Cheng-Yin Lee , l2vpn@ietf.org Subject: Re: CE-based VPLS References: <3F16F8A9.8126E8C1@alcatel.com> <20030720155356.A28944@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit WG, Kireeti and Cheng-Yin, Speaking as chair: It is the opinion of the wg chairs and the ADs that the CE-based is out of charter. Speaking as a "terminology police": CE is not a piece of equipment, it is the functionality needed to handle the customer side of the vpls (or vpn in genral). Nor is PE a piece of equipment, it is the functionality needed to handle the provider side of the vpls (or vpn in general). It is conceivable that the CE and PE could be allocated to the same box, or to any number of boxes. Don't ask me why you would like to do that. /Loa Kireeti Kompella wrote: > Hi Cheng-Lin, > > On Thu, 17 Jul 2003, Cheng-Yin Lee wrote: > > >>The L2VPN charter states >>"The WG is responsible for standardization of the following solutions: >>1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN >> across an IP and an MPLS-enabled IP network, allowing standard >> Ethernet devices communicate with each other as if they were >> connected to a common LAN segment. >>... >>" >> >>This is the service that CE-based VPLS (where CE is provisioned by >>provider) provides. > > > It would be interesting (but ultimately irrelevant) to understand how > you made the leap from "service that emulates LAN" to "CE-based VPLS > ... where CE is provisioned by provider". The charter does not say who > provisions the VPLS, although since L2VPN emerged from PPVPN, it seems > logical that the provider provisions it. Furthermore, the charter > doesn't mention "CE-based". > > If by "CE", you mean (as in rfc2547bis) a device owned, operated and > managed by the customer, then "CE provisioned by the provider" is an > oxymoron. If you mean something else, it would be useful to define it; > and furthermore, to read the decoupled VPLS and the H-VPLS drafts. > > >>So I think CE-based VPLS is within the scope of the L2VPN >>charter (unless the charter is changed to explicitly exclude CE-based >>VPLS). > > > The parenthetical statement is not a bad idea. Chairs? ADs? > > >>I believe the following drafts do not currently allow standard Ethernet >>devices to communicate with each other as if they were connected to a >>common LAN segment: >>http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-00.txt >>http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-bgp-00.txt >>http://www.ietf.org/internet-drafts/draft-radoaca-ppvpn-gvpls-02.txt >>http://www.ietf.org/internet-drafts/draft-shah-ppvpn-ipls-02.txt > > > There is an existence proof that most (if not all) of the above _do_ > in fact allow standard Ethernet devices to communicate with each other > as if they were on a LAN. So, your belief does not jive with reality. > Step into any number of vendor or provider labs for proof. > > If there are corner cases where the "VPLS" in the above drafts fails > to emulate a LAN perfectly, please communicate that to the group. > This would be productive, and help the group understand whether the > failure was systemic or the artifact of particular implementations, > and thus guide further standards development. > > Kireeti. > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From exim@www1.ietf.org Mon Jul 21 12:59:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03616 for ; Mon, 21 Jul 2003 12:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee0W-0004g1-BO for l2vpn-archive@odin.ietf.org; Mon, 21 Jul 2003 12:59:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGxSNR017971 for l2vpn-archive@odin.ietf.org; Mon, 21 Jul 2003 12:59:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee0R-0004fm-6t for l2vpn-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03552 for ; Mon, 21 Jul 2003 12:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ee0A-0004bF-00 for l2vpn-web-archive@ietf.org; Mon, 21 Jul 2003 12:59:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ee04-0004b9-00 for l2vpn-web-archive@ietf.org; Mon, 21 Jul 2003 12:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee04-0004bD-Li; Mon, 21 Jul 2003 12:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19axrw-0001GX-6M for l2vpn@optimus.ietf.org; Fri, 11 Jul 2003 09:23:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28567 for ; Fri, 11 Jul 2003 09:23:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19axru-0005bc-00 for l2vpn@ietf.org; Fri, 11 Jul 2003 09:23:22 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19axrt-0005bY-00 for l2vpn@ietf.org; Fri, 11 Jul 2003 09:23:21 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id <3RSYS2LP>; Fri, 11 Jul 2003 09:23:14 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB00105BF@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'l2vpn@ietf.org'" Subject: L2VPN agenda Date: Fri, 11 Jul 2003 09:23:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C347AF.9495F3D0" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C347AF.9495F3D0 Content-Type: text/plain; charset="iso-8859-1" Any progress on L2VPN agenda? /himanshu ------_=_NextPart_001_01C347AF.9495F3D0 Content-Type: text/html; charset="iso-8859-1" L2VPN agenda

Any progress on L2VPN agenda?

/himanshu

------_=_NextPart_001_01C347AF.9495F3D0-- From exim@www1.ietf.org Mon Jul 21 13:00:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03667 for ; Mon, 21 Jul 2003 13:00:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee0l-0004gh-8U for l2vpn-archive@odin.ietf.org; Mon, 21 Jul 2003 12:59:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGxhKI018013 for l2vpn-archive@odin.ietf.org; Mon, 21 Jul 2003 12:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee0R-0004fl-31 for l2vpn-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03549 for ; Mon, 21 Jul 2003 12:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ee0A-0004bC-00 for l2vpn-web-archive@ietf.org; Mon, 21 Jul 2003 12:59:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ee04-0004b8-00 for l2vpn-web-archive@ietf.org; Mon, 21 Jul 2003 12:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee04-0004bN-Tm; Mon, 21 Jul 2003 12:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIHE-00056J-Lv for l2vpn@optimus.ietf.org; Thu, 17 Jul 2003 19:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27027 for ; Thu, 17 Jul 2003 19:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dIHC-0002MP-00 for l2vpn@ietf.org; Thu, 17 Jul 2003 19:35:06 -0400 Received: from patrician.office.packetexchange.net ([212.113.5.71] helo=patrician ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19dIH2-0002Lt-00 for l2vpn@ietf.org; Thu, 17 Jul 2003 19:34:56 -0400 Received: from [212.113.11.114] (helo=rincewind.office.packetexchange.net ident=mail) by patrician with esmtp (Exim 3.35 #1 (Debian)) id 19dJBa-00016C-00; Fri, 18 Jul 2003 01:33:22 +0100 Received: from [213.208.123.104] (helo=gizpad) by rincewind.office.packetexchange.net with esmtp (Exim 3.35 #1 (Debian)) id 19dIGE-0007pm-00; Fri, 18 Jul 2003 00:34:07 +0100 Subject: Re: CE-based VPLS From: Giles Heron To: Cheng-Yin.Lee@alcatel.com Cc: l2vpn@ietf.org In-Reply-To: <3F16F8A9.8126E8C1@alcatel.com> References: <3F16F8A9.8126E8C1@alcatel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Jul 2003 00:30:13 +0000 Message-Id: <1058488214.1960.19.camel@gizpad> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-07-17 at 19:27, Cheng-Yin Lee wrote: > Vach, Loa, > > The L2VPN charter states > "The WG is responsible for standardization of the following solutions: > 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN > across an IP and an MPLS-enabled IP network, allowing standard > Ethernet devices communicate with each other as if they were > connected to a common LAN segment. > ... > " > > This is the service that CE-based VPLS (where CE is provisioned by > provider) provides. I believe it does allow standard Ethernet devices to > communicate with each other as if they were connected to a common LAN > segment. So I think CE-based VPLS is within the scope of the L2VPN > charter (unless the charter is changed to explicitly exclude CE-based > VPLS). > > I believe the following drafts do not currently allow standard Ethernet > devices to communicate with each other as if they were connected to a > common LAN segment: > http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-bgp-00.txt > http://www.ietf.org/internet-drafts/draft-radoaca-ppvpn-gvpls-02.txt > http://www.ietf.org/internet-drafts/draft-shah-ppvpn-ipls-02.txt On what basis do you make this assertion? Or is this back to your previous post referencing Tony Li's email about disconnects between non-DR routers in the case of ISIS or OSPF? Since this is an error condition (i.e. not something that happens during normal operation of a VPLS) I would have to disagree with your assertion if this is indeed what you are referring to. For what it's worth, my view on the problem of loss of connectivity between CE routers is that when doing VPLS over MPLS it is preferable to use LDP to set up the tunnel labels - since I am happier trusting LDP to give me a full mesh than I am RSVP-TE (partly because there is no risk of LSP preemption or of failing to find a path matching a set of constraints, but also because there is no risk of "fat finger" problems resulting in missing config for an LSP). This is probably sloppy reasoning on my part, and I know a few vendors who don't agree with me... It is also worth remembering that not all VPLS instances with CE routers will use IGPs. Some may use BGP between the CEs, in which case disconnects are only an issue if there are route servers in the mix. Giles > I believe this draft does allow standard Ethernet devices to communicate > with each other as if they were connected to a common LAN segment: > http://www.ietf.org/internet-drafts/draft-lee-ppvpn-hybrid-vpls-01.txt > > > Thanks > Cheng-Yin > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From exim@www1.ietf.org Tue Jul 22 10:18:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15185 for ; Tue, 22 Jul 2003 10:18:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exyE-0000Nm-KH for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 10:18:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEIQbv001464 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 10:18:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exyE-0000NX-9o for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:18:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15161 for ; Tue, 22 Jul 2003 10:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exy0-0004v9-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 10:18:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19exxu-0004v5-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 10:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exxp-0000Go-9u; Tue, 22 Jul 2003 10:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exxA-0000G9-FG for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 10:17:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15152 for ; Tue, 22 Jul 2003 10:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exx8-0004uu-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 10:17:18 -0400 Received: from web20702.mail.yahoo.com ([216.136.226.175]) by ietf-mx with smtp (Exim 4.12) id 19exwx-0004um-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 10:17:07 -0400 Message-ID: <20030722141640.27058.qmail@web20702.mail.yahoo.com> Received: from [216.140.58.174] by web20702.mail.yahoo.com via HTTP; Tue, 22 Jul 2003 07:16:40 PDT Date: Tue, 22 Jul 2003 07:16:40 -0700 (PDT) From: Brad Neal Subject: Spanning Tree To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , from draft-ietf-ppvpn-l2-framework-03.txt, section 3.4: Bridge control protocols are generally designed to run in over a real LAN, and may presume, for their proper functioning, certain characteristics of the LAN, such as low latency and sequential delivery. If the Emulated LAN does not provide these characteristics, the control protocols may not perform as expected . . . Operational scaling issues notwithstanding, can anyone offer some insight on exactly what breaks when you run STP over high latency (RTT > 100ms) links? Do you get transient loops? If it's a convergence issue, is there some formula or rule of thumb about STP convergence with respect to average (or max?) link latency? I haven't found anything more specific than "it just wasn't designed for a WAN environment". Thanks in advance, brad __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From exim@www1.ietf.org Tue Jul 22 10:49:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16159 for ; Tue, 22 Jul 2003 10:49:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyRv-0001pS-J6 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 10:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEn7LI007027 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 10:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyRv-0001pG-Em for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 10:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16152 for ; Tue, 22 Jul 2003 10:49:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyRt-00059q-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 10:49:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eyRn-00059n-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 10:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyRp-0001n1-4I; Tue, 22 Jul 2003 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyQw-0001mL-HF for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 10:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16132 for ; Tue, 22 Jul 2003 10:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyQu-00059R-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 10:48:04 -0400 Received: from bzq-25-127-226.cust.bezeqint.net ([212.25.127.226] helo=tiger.seabridge.co.il) by ietf-mx with esmtp (Exim 4.12) id 19eyQi-000597-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 10:47:52 -0400 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 17:46:13 +0200 Message-ID: From: Yaron Nachman To: "'Brad Neal'" , l2vpn@ietf.org Subject: RE: Spanning Tree Date: Tue, 22 Jul 2003 17:46:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Another thing on this issue ... How does the Emulated LAN treat Customer's MAC BPDUs (STP)? Are they flooded towards all remote VPLS Forwarders, as if to emulate a share LAN segment between PE Bridge Modules? Thanks, Yaron. -----Original Message----- From: Brad Neal [mailto:bradneal6395@yahoo.com] Sent: Tuesday, July 22, 2003 16:17 To: l2vpn@ietf.org Subject: Spanning Tree from draft-ietf-ppvpn-l2-framework-03.txt, section 3.4: Bridge control protocols are generally designed to run in over a real LAN, and may presume, for their proper functioning, certain characteristics of the LAN, such as low latency and sequential delivery. If the Emulated LAN does not provide these characteristics, the control protocols may not perform as expected . . . Operational scaling issues notwithstanding, can anyone offer some insight on exactly what breaks when you run STP over high latency (RTT > 100ms) links? Do you get transient loops? If it's a convergence issue, is there some formula or rule of thumb about STP convergence with respect to average (or max?) link latency? I haven't found anything more specific than "it just wasn't designed for a WAN environment". Thanks in advance, brad __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From exim@www1.ietf.org Tue Jul 22 11:33:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17530 for ; Tue, 22 Jul 2003 11:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ez8V-0003V8-Pf for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 11:33:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MFX7pa013454 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 11:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ez8V-0003Uv-Lp for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 11:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17516 for ; Tue, 22 Jul 2003 11:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ez8U-0005X4-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 11:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ez8P-0005X1-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 11:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ez8O-0003Si-P6; Tue, 22 Jul 2003 11:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ez7h-0003SH-OM for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 11:32:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17477 for ; Tue, 22 Jul 2003 11:32:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ez7g-0005Wh-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 11:32:16 -0400 Received: from [63.150.47.130] (helo=claven.luminous.com) by ietf-mx with esmtp (Exim 4.12) id 19ez7W-0005Wb-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 11:32:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Spanning Tree Date: Tue, 22 Jul 2003 08:30:56 -0700 Message-ID: Thread-Topic: Spanning Tree Thread-Index: AcNQYGXDN6WbjXWfTYqt5CLHmOZiQQABIOoA From: "Raj Sharma" To: "Yaron Nachman" , "Brad Neal" , Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The BPDUs must be flooded within the LAN (VPLS). Whether the PEs actually do anything with them is a different issue.=20 > -----Original Message----- > From: Yaron Nachman [mailto:yaron.nachman@SeabridgeNetworks.com] > Sent: Tuesday, July 22, 2003 8:46 AM > To: 'Brad Neal'; l2vpn@ietf.org > Subject: RE: Spanning Tree >=20 >=20 > Another thing on this issue ... >=20 > How does the Emulated LAN treat Customer's MAC BPDUs (STP)? > Are they flooded towards all remote VPLS Forwarders, as if to=20 > emulate a > share LAN segment between PE Bridge Modules? >=20 > Thanks, >=20 > Yaron. >=20 > -----Original Message----- > From: Brad Neal [mailto:bradneal6395@yahoo.com] > Sent: Tuesday, July 22, 2003 16:17=20 > To: l2vpn@ietf.org > Subject: Spanning Tree >=20 >=20 > from draft-ietf-ppvpn-l2-framework-03.txt, section > 3.4: >=20 > Bridge control protocols are generally designed to > run in over a real > LAN, and may presume, for their proper > functioning, certain > characteristics of the LAN, such as low latency > and sequential > delivery. If the Emulated LAN does not provide > these > characteristics, the control protocols may not > perform as expected . . . >=20 > Operational scaling issues notwithstanding, can anyone > offer some insight on exactly what breaks when you run > STP over high latency (RTT > 100ms) links? Do you get > transient loops? If it's a convergence issue, is > there some formula or rule of thumb about STP > convergence with respect to average (or max?) link > latency? I haven't found anything more specific than > "it just wasn't designed for a WAN environment". >=20 > Thanks in advance, > brad >=20 >=20 >=20 > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com >=20 >=20 From exim@www1.ietf.org Tue Jul 22 13:14:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19951 for ; Tue, 22 Jul 2003 13:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0iG-0007eq-Vu for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 13:14:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MHE83O029435 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 13:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0iG-0007eg-Sr for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 13:14:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19948 for ; Tue, 22 Jul 2003 13:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0iF-000644-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 13:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f0i9-000641-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 13:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0i9-0007dl-Hc; Tue, 22 Jul 2003 13:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0ha-0007dV-Id for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 13:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19918 for ; Tue, 22 Jul 2003 13:13:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0hY-00063r-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 13:13:24 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19f0hN-00063Y-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 13:13:13 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6MHCMP25294 for ; Tue, 22 Jul 2003 12:12:23 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id <3CKSAF9L>; Tue, 22 Jul 2003 13:12:11 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'l2vpn@ietf.org'" Subject: Truly Generalized VPLS (?) Date: Tue, 22 Jul 2003 13:12:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In the WG meeting in Vienna I made a comment on draft-radoaca-ppvpn-gvpls-02, which I was asked to bring up on the mailing list. The issue is the following: In any "decoupled" solution there is a hierarchy of devices: a U-PE that performs a bridging function and an N-PE that forwards traffic based on identifiers other than MAC addresses. Between N-PEs, these identifiers are PW labels. In the access network, PW labels can also be used, although other options (Q-in-Q, MAC-in-MAC) could potentially play a role. Since the forwarding function in the N-PEs is essentially a form of label switching, the question is: why don't we treat the connection between two U-PEs as a regular Label Switched Path that goes through multiple intermediate hops and is set up and managed with regular MPLS protocols and tools? In essence, PWs are LSPs, U-PEs function as "PW-LERs" and N-PEs function as "PW-LSRs". PW-LERs and PW-LSRs form a logical MPLS infrastructure that is overlayed on top of the existing Packet Switched Network. Adjacencies between PW-LxRs are created through MPLS, IP and/or GRE tunnels. RSVP-TE is used to set up PWs between PW-LERs (i.e. U-PEs). How does this alternative view differ from draft-radoaca-ppvpn-gvpls? 1) Draft-radoaca-ppvpn-gvpls prescribes a fixed topology: U-PEs are connected to N-PEs and there is a full mesh of tunnels between N-PEs. Hence, a PW goes at maximum through two intermediate hops. In the more general approach, any topology is allowed. E.g. there is no need for a full mesh of tunnels between N-PEs. In case of a partial mesh, PWs could be routed through multiple PW-LSRs. Similarly, additional aggregation points (e.g. Border Routers between ASs) could be deployed. 2)In draft-radoaca-ppvpn-gvpls there is a notion that N-PEs are VPLS-specific network elements. The current draft actually specifies an approach in which N-PEs can forward traffic purely based on PW labels, but the draft still promotes an optimization where the SRC-ID is carried in the Control Word so as to decrease the number of PW labels required between N-PEs. In that case, an N-PE would perform VPLS-specific functions when forwarding packets in the data plane. In the more general approach, intermediate nodes are LSRs. VPLS-specific functions occur only at the edge. Hence, Service Providers can rely to a larger extent on general-purpose MPLS switches and don't need to distribute VPLS functionality throughout their networks. 3) In draft-radoaca-ppvpn-gvpls, signaling is completely PW-centric: PWs are set up using PW-specific signaling and then spliced together. In the more general approach, there is of course a need for VPLS-specific TLVs in the RSVP messages, but these are only relevant to the U-PEs. The PW-LSRs do not need to implement VPLS-specific signaling functions. In the meeting in Vienna, Vasile and Ali argued that the splicing approach described in draft-radoaca-ppvpn-gvpls was necessary because of control-plane scaleability. I may be missing something, but I don't see why that is the case. a) In terms of control message load required for PW set up, I don't see a significant difference between the splicing approach and the more general approach. b) In terms of control message load required for OAM and protection switching, I am not sure, because draft-radoaca-ppvpn-gvpls is not very specific about the impact is of splicing. This is another reason why I believe the more general approach is preferable: when a PW between U-PEs is in effect a regular LSP, mechanisms like vccv and the various forms of protection switching can be applied straightforwardly. With splicing that may also be the case, but one needs to think it through. Draft-radoaca-ppvpn-gvpls provides a solution that works across multiple access technologies. Personally, I believe that Q-in-Q doesn't work well in a decoupled network and I don't think MAC-in-MAC will ever be standardized. Still, it is important to note that the general RSVP-based approach that I advocate in this email could also be made to work across access networks based on Q-in-Q or MAC-in-MAC. In summary: I believe that draft-radoaca-ppvpn-gvpls is too narrowly focused on extending current PW and VPLS drafts. Instead, by accepting that PWs are LSPs that can be routed through multiple intermediate nodes, I believe one can define scaleable VPLS solutions that are superior to GVPLS. Peter From exim@www1.ietf.org Tue Jul 22 13:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20773 for ; Tue, 22 Jul 2003 13:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1J1-0000gI-KE for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 13:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MHq7PJ002614 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 13:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1J1-0000g5-Gp for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 13:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20770 for ; Tue, 22 Jul 2003 13:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1Iz-0006Dq-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 13:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f1It-0006Dn-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 13:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1Iv-0000dq-4D; Tue, 22 Jul 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1Is-0000de-JE for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 13:51:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20765 for ; Tue, 22 Jul 2003 13:51:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1Iq-0006Dk-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 13:51:56 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19f1If-0006DX-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 13:51:45 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2003 10:52:01 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6MHp8Ai023271; Tue, 22 Jul 2003 13:51:08 -0400 (EDT) Message-Id: <200307221751.h6MHp8Ai023271@rtp-core-2.cisco.com> To: "Busschbach, Peter B (Peter)" cc: "'l2vpn@ietf.org'" Subject: Re: Truly Generalized VPLS (?) In-reply-to: Your message of Tue, 22 Jul 2003 13:12:10 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 22 Jul 2003 13:51:08 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The point of the decoupled procedures is to reduce the number of control connections (e.g., LDP connections) which must be maintained by any one U-PE device. By using decoupled proceudres, a (spliced) PW can run between two U-PEs without there being an LDP connection between the U-PEs. This is the scalability consideration. I don't see how you get that without the splicing methodology. Peter> Since the forwarding function in the N-PEs is essentially a form of Peter> label switching, the question is: why don't we treat the connection Peter> between two U-PEs as a regular Label Switched Path that goes through Peter> multiple intermediate hops and is set up and managed with regular Peter> MPLS protocols and tools? Because that requires an LDP connection between the two U-PEs. Peter> Draft-radoaca-ppvpn-gvpls prescribes a fixed topology: U-PEs are Peter> connected to N-PEs and there is a full mesh of tunnels between Peter> N-PEs. Hence, a PW goes at maximum through two intermediate hops. Not necessarily. See, e.g., the related material in section 5.5 of draft- rosen-ppvpn-l2-signaling. There is no fundamental restriction on the topology. One may ask of course whether it is worthwhile to reduce the number of LDP connections. After all, the signaling load is, to first order, proportional to the number of PWs supported, not to the number of LDP connections, and the splicing approach does not reduce the number of PWs. In most common cases I think that a reduction in the number of LDP connections is not that big a deal. However, there are a couple of cases where it might be very useful: - A "low end" U-PE with limits on its TCP support. - When PWs go between SPs, the control connections need to be secured, and this requires management; having fewer means less management. With regard to the extra "control word" and to the MAC-in-MAC stuff, well, I agree that those particular pieces are not likely to go anywhere. From exim@www1.ietf.org Tue Jul 22 14:23:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21744 for ; Tue, 22 Jul 2003 14:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1n2-0002Fh-Vn for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 14:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MIN8Dd008651 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 14:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1n2-0002FS-Qu for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 14:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21730 for ; Tue, 22 Jul 2003 14:23:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1n0-0006Vh-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 14:23:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f1mu-0006Ve-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 14:23:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1mv-0002DE-Hg; Tue, 22 Jul 2003 14:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1mn-0002Ct-Rg for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 14:22:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21720 for ; Tue, 22 Jul 2003 14:22:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1ml-0006VR-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 14:22:51 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19f1ma-0006Uv-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 14:22:40 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6MILWU11550; Tue, 22 Jul 2003 14:21:33 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 14:21:33 -0400 Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, "Busschbach, Peter B (Peter)" Cc: "'l2vpn@ietf.org'" Subject: RE: Truly Generalized VPLS (?) Date: Tue, 22 Jul 2003 14:21:32 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric, > > > The point of the decoupled procedures is to reduce the > number of control > connections (e.g., LDP connections) which must be maintained > by any one U-PE > device. By using decoupled proceudres, a (spliced) PW can > run between two > U-PEs without there being an LDP connection between the > U-PEs. This is the > scalability consideration. Another aspect of scalability of the decoupled procedures is to keep the MAC-address learning, and l2 forwarding decisions relevant only to the "low-end/low-cost" U-PE (allowing N-PE to focus only on common pw/vpn control functions and not to keep MAC addresses, etc). Hamid. From exim@www1.ietf.org Tue Jul 22 14:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22488 for ; Tue, 22 Jul 2003 14:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2Ls-0003hK-VV for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 14:59:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MIx8to014213 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 14:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2Ls-0003h8-Rz for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 14:59:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22483 for ; Tue, 22 Jul 2003 14:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2Lq-0006gO-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 14:59:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f2Lk-0006gL-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 14:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2Ll-0003fY-Sg; Tue, 22 Jul 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2LE-0003fC-IA for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 14:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22474 for ; Tue, 22 Jul 2003 14:58:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2LB-0006g9-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 14:58:25 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19f2Kz-0006g0-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 14:58:13 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19f2Kb-000IuL-TF for l2vpn@ietf.org; Tue, 22 Jul 2003 18:57:49 +0000 Date: Tue, 22 Jul 2003 11:56:24 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15274323000.20030722115624@psg.com> To: l2vpn@ietf.org Subject: On VPLS and Routing Protocols MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [RTG TA hat on] I'd like to comment on the issue of routing protocol operations under the condition of a PW failure in a VPLS. First, let me note that both ISIS and OSPF protocols already know how to deal with NBMA clouds that exhibit the same behavior as VPLS as far as connectivity is concerned. ISIS takes the simplest approach--assumes any-to-any connectivity (essentially full mesh of VCs) and treats the cloud as broadcast media--DIS is elected, and the cloud itself is abstracted as a pseudo-node with all routers attached to it. The broadcast service itself is provided by the interface driver that replicates the multicast packets for multiple VCs. The same approach is used in OSPF's NBMA mode. The catch here is in potentially nasty problems that show up when connectivity between non-DR/DIS routers changes. Here's an example: 10.2/16 | ...[R2]... . / \ . 10.1/16--[R1]+----+[R3]--10.3./16 . . .......... Assume that R2 is elected as the DIS on the segment/cloud. R1 will establish an adjacency with R2, but not with R3, because both R1 and R3 are non-DIS routers. This means that the RP will be actively checking connectivity of the R1-R2 and R2-R3 VCs only, and if the R1-R3 VC goes down, the RP will not notice it. However, connectivity between R1 and R3 is still assumed by the protocol, and R1, for example, will install a route to 10.3/16 as follows: 10.3/16 -> FrameRelay0/0, R3 That is, R1 will try to route directly to R3, not through R2. So if R1-R3 VC is down, traffic will be black-holed. In the case of VPLS, the situation is essentially the same-- there is a risk of traffic black-holing when one PW goes down. Another risk is inconsistency in the DIS/DR calculations among the attached routers because of the differences in the sets of visible neighbors. This one leads to problems with adjacency establishment, which is a bit better, since they are visible at the RP level and should be reported to the admin. There are no additional and already existing mechanisms in ISIS that could help us address the problem. The operational model is to monitor the status of each VC/PW and troubleshoot when an alarm is received. OSPF is a little different. What we would like to have in the VPLS case is awareness of the PW topology and ability of the RP to reroute around a failure (R1 rerouting through R2 in the example above.) As only fully established adjacencies are used to abstract the network topology, we essentially need any-to-any adjacency establishment (vs DR/BDR to others in the normal NBMA case). We also need the RP to abstract connectivity over an emulated LAN as a set of p2p links, rather than a pseudo-node with all routers connected to it. What's described above is the point-to-multipoint mode in OSPF. It is normally used for NBMA clouds, but can be reused for the VPLS case. There's one subtle detail though--neighbor discovery. Normally, in the p2mp mode, neighbors are assumed to be configured manually. However, we don't want to require that VPLS customers have to configure them, so we need hello-broadcast neighbor discovery combined with p2mp OSPF network type. I know at least one major vendor that supports it, but others may not, so it is worth spelling out. Note that the choice of treating an emulated LAN as a broadcast network with DR/DIS vs a p2mp one, is not straight-forward. It is about the balance between protocol scalability and network availability. With the p2mp network approach, the number of adjacencies is O(N^2) (vs O(N) in the broadcast network case), which affects complexity of the protocol operation, most notably flooding and SPF computation. On the other hand, it gives us better connectivity in PW failure scenarios. Hope this sheds some light on this issue. If there's interest within the WG, these considerations could be captured in a short document. Regards -- Alex http://www.psg.com/~zinin/ From exim@www1.ietf.org Tue Jul 22 15:14:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23897 for ; Tue, 22 Jul 2003 15:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2aN-0004d1-2R for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 15:14:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJE7pA017785 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 15:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2aM-0004cm-V8 for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 15:14:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23837 for ; Tue, 22 Jul 2003 15:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2aL-0006nU-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 15:14:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f2aG-0006nR-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 15:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2aG-0004Zi-6g; Tue, 22 Jul 2003 15:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2ZO-0004Ya-B5 for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 15:13:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23723 for ; Tue, 22 Jul 2003 15:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2ZM-0006mo-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 15:13:04 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19f2ZB-0006mL-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 15:12:53 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6MJBxw26495 for ; Tue, 22 Jul 2003 14:12:00 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id <3CKSANXC>; Tue, 22 Jul 2003 15:11:59 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'erosen@cisco.com'" Cc: "'l2vpn@ietf.org'" Subject: RE: Truly Generalized VPLS (?) Date: Tue, 22 Jul 2003 15:11:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, July 22, 2003 1:51 PM > To: Busschbach, Peter B (Peter) > Cc: 'l2vpn@ietf.org' > Subject: Re: Truly Generalized VPLS (?) > > > > The point of the decoupled procedures is to reduce the > number of control > connections (e.g., LDP connections) which must be maintained > by any one U-PE > device. By using decoupled proceudres, a (spliced) PW can > run between two > U-PEs without there being an LDP connection between the > U-PEs. This is the > scalability consideration. I don't see how you get > that without the > splicing methodology. Since for a given VPLS, a U-PE needs PWs to a limited number of remote U-PEs, I thought it would make more sense to use RSVP-TE instead of LDP. In any case, I don't think that control connections would exist between U-PEs. PW labels need to be assigned on every segment of the end-to-end PW and I don't know how you would do that without involving the intermediate hops. Hence, if you use LDP, a U-PE would have an LDP control connections with its neighboring N-PEs, not with its remote U-PE peers. This would be the same as in the spliced approach. But again, I think that it would make more sense to use RSVP-TE. > > Peter> Since the forwarding function in the N-PEs is > essentially a form of > Peter> label switching, the question is: why don't we treat > the connection > Peter> between two U-PEs as a regular Label Switched Path > that goes through > Peter> multiple intermediate hops and is set up and > managed with regular > Peter> MPLS protocols and tools? > > Because that requires an LDP connection between the two U-PEs. > > Peter> Draft-radoaca-ppvpn-gvpls prescribes a fixed > topology: U-PEs are > Peter> connected to N-PEs and there is a full mesh of > tunnels between > Peter> N-PEs. Hence, a PW goes at maximum through two > intermediate hops. > > Not necessarily. See, e.g., the related material in > section 5.5 of draft- > rosen-ppvpn-l2-signaling. There is no fundamental > restriction on the > topology. > You are right. However, the problem I have with the splicing approach is that it looks very much like manual provisioning. Where do the local lists and remote lists that you specify in 5.5 come from? I guess that with a smart usage of autodiscovery algorithms you can come pretty far, but is this not a problem that begs for the use of the routing and signaling protocols that we all know and love? > One may ask of course whether it is worthwhile to reduce > the number of LDP > connections. After all, the signaling load is, to first > order, proportional > to the number of PWs supported, not to the number of LDP > connections, and > the splicing approach does not reduce the number of PWs. > In most common > cases I think that a reduction in the number of LDP > connections is not that > big a deal. However, there are a couple of cases where it > might be very > useful: > > - A "low end" U-PE with limits on its TCP support. > > - When PWs go between SPs, the control connections need to > be secured, and > this requires management; having fewer means less management. > > With regard to the extra "control word" and to the MAC-in-MAC > stuff, well, I > agree that those particular pieces are not likely to go anywhere. > > > > > > > From exim@www1.ietf.org Tue Jul 22 15:23:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24292 for ; Tue, 22 Jul 2003 15:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2j8-0005BB-CP for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 15:23:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJNAs2019903 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 15:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2j8-00059e-8T for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 15:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24287 for ; Tue, 22 Jul 2003 15:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2j5-0006qV-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 15:23:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f2j0-0006qS-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 15:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2iz-00058o-1c; Tue, 22 Jul 2003 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2iU-00057z-9J for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 15:22:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24267 for ; Tue, 22 Jul 2003 15:22:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2iT-0006qN-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 15:22:29 -0400 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 19f2iI-0006qE-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 15:22:18 -0400 Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jul 2003 12:21:27 -0700 Reply-To: From: "Vach Kompella" To: "Alex Zinin" , Subject: RE: On VPLS and Routing Protocols Date: Tue, 22 Jul 2003 12:22:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15274323000.20030722115624@psg.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 22 Jul 2003 19:21:27.0903 (UTC) FILETIME=[72D6DEF0:01C35086] Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Given a VPLS model that includes HVPLS, there is a straightforward modification of the VPLS topology to remove the blackhole. However, it may result in flapping. Here's how the black hole can be resolved: If a VPLS node loses one PW (which has to be a PW on which the split horizon rule applies), it declares all but one of its PWs to be down, and turns the remaining PW into a VPLS spoke, i.e., split horizon doesn't apply to it. Just bringing a PW down doesn't quite cut it, since that ripples across the entire VPLS and causes the VPLS to come down. Instead, a special state would apply to those PWs such that they are "blocking" to use a spanning tree term. When the PW that went down comes back up again, the state of all the PWs that were blocking goes back to split-horizon, along with the one PW that went into spoke mode. E.g., R1 to R2 goes down: R1-----R2 | \ / | | \ / | | / \ | | / \ | R3-----R4 This becomes R1 R2 | \ / | | \ / | | / \ | | / \ | R3-----R4 With the above rules, let's say R1 takes the action (for some a priori tie breaking rule between R1 and R2 so there is no need to communicate between R1 and R2) R1 R2 | \ / | | \ / | | / \ | | / \ | R3-----R4 One PW becomes a spoke: let's say R1-R3. All but one PWs are marked blocking: let's say R1-R4 is marked blocking. R1 R2 | / | | / | | / | | / | R3-----R4 Note that the remaining VPLS nodes are in a full mesh. Some relearns are necessary to fix blackholes. We'd have to deal with flapping PWs. -Vach > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org]On Behalf Of > Alex Zinin > Sent: Tuesday, July 22, 2003 11:56 AM > To: l2vpn@ietf.org > Subject: On VPLS and Routing Protocols > > > [RTG TA hat on] > > I'd like to comment on the issue of routing protocol operations under > the condition of a PW failure in a VPLS. > > First, let me note that both ISIS and OSPF protocols already know how > to deal with NBMA clouds that exhibit the same behavior as VPLS as far > as connectivity is concerned. > > ISIS takes the simplest approach--assumes any-to-any connectivity > (essentially full mesh of VCs) and treats the cloud as broadcast > media--DIS is elected, and the cloud itself is abstracted as a > pseudo-node with all routers attached to it. The broadcast service > itself is provided by the interface driver that replicates the > multicast packets for multiple VCs. The same approach is used in > OSPF's NBMA mode. The catch here is in potentially nasty problems that > show up when connectivity between non-DR/DIS routers changes. Here's > an example: > > 10.2/16 > | > ...[R2]... > . / \ . > 10.1/16--[R1]+----+[R3]--10.3./16 > . . > .......... > > Assume that R2 is elected as the DIS on the segment/cloud. > > R1 will establish an adjacency with R2, but not with R3, because both > R1 and R3 are non-DIS routers. This means that the RP will be actively > checking connectivity of the R1-R2 and R2-R3 VCs only, and if the > R1-R3 VC goes down, the RP will not notice it. However, connectivity > between R1 and R3 is still assumed by the protocol, and R1, for > example, will install a route to 10.3/16 as follows: > > 10.3/16 -> FrameRelay0/0, R3 > > That is, R1 will try to route directly to R3, not through R2. So if > R1-R3 VC is down, traffic will be black-holed. > > In the case of VPLS, the situation is essentially the same-- there is > a risk of traffic black-holing when one PW goes down. > > Another risk is inconsistency in the DIS/DR calculations among the > attached routers because of the differences in the sets of visible > neighbors. This one leads to problems with adjacency establishment, > which is a bit better, since they are visible at the RP level and > should be reported to the admin. > > There are no additional and already existing mechanisms in ISIS that > could help us address the problem. The operational model is to monitor > the status of each VC/PW and troubleshoot when an alarm is received. > OSPF is a little different. > > What we would like to have in the VPLS case is awareness of the PW > topology and ability of the RP to reroute around a failure (R1 > rerouting through R2 in the example above.) As only fully established > adjacencies are used to abstract the network topology, we essentially > need any-to-any adjacency establishment (vs DR/BDR to others in the > normal NBMA case). We also need the RP to abstract connectivity over > an emulated LAN as a set of p2p links, rather than a pseudo-node with > all routers connected to it. > > What's described above is the point-to-multipoint mode in OSPF. It is > normally used for NBMA clouds, but can be reused for the VPLS case. > There's one subtle detail though--neighbor discovery. > > Normally, in the p2mp mode, neighbors are assumed to be configured > manually. However, we don't want to require that VPLS customers have > to configure them, so we need hello-broadcast neighbor discovery > combined with p2mp OSPF network type. I know at least one major vendor > that supports it, but others may not, so it is worth spelling out. > > Note that the choice of treating an emulated LAN as a broadcast > network with DR/DIS vs a p2mp one, is not straight-forward. It is > about the balance between protocol scalability and network > availability. With the p2mp network approach, the number of > adjacencies is O(N^2) (vs O(N) in the broadcast network case), which > affects complexity of the protocol operation, most notably flooding > and SPF computation. On the other hand, it gives us better > connectivity in PW failure scenarios. > > Hope this sheds some light on this issue. > > If there's interest within the WG, these considerations could > be captured in a short document. > > Regards > > -- > Alex > http://www.psg.com/~zinin/ > > > From exim@www1.ietf.org Tue Jul 22 17:12:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27046 for ; Tue, 22 Jul 2003 17:12:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Qb-0001SL-6q for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 17:12:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MLC9OS005591 for l2vpn-archive@odin.ietf.org; Tue, 22 Jul 2003 17:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Qb-0001S6-2C for l2vpn-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 17:12:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27036 for ; Tue, 22 Jul 2003 17:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4QY-0007Rf-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 17:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f4QT-0007Rc-00 for l2vpn-web-archive@ietf.org; Tue, 22 Jul 2003 17:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4QT-0001Px-3K; Tue, 22 Jul 2003 17:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4QA-0001Pc-IN for l2vpn@optimus.ietf.org; Tue, 22 Jul 2003 17:11:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27030 for ; Tue, 22 Jul 2003 17:11:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4Q8-0007RW-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 17:11:40 -0400 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 19f4Px-0007Os-00 for l2vpn@ietf.org; Tue, 22 Jul 2003 17:11:29 -0400 Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jul 2003 14:02:35 -0700 Reply-To: From: "Vach Kompella" To: "L2vpn" Subject: Presentations Date: Tue, 22 Jul 2003 14:03:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 22 Jul 2003 21:02:35.0786 (UTC) FILETIME=[939456A0:01C35094] Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To everyone who made a presentation during the L2VPN: please forward Loa and I a copy of your presentation. Thanks. -Vach From exim@www1.ietf.org Wed Jul 23 03:56:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05105 for ; Wed, 23 Jul 2003 03:56:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fETx-0006Zy-6Z for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 03:56:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N7uHM7025290 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 03:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fETw-0006Zp-Do for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 03:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05079 for ; Wed, 23 Jul 2003 03:56:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fESp-0002pr-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 03:55:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fESj-0002po-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 03:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fESj-0006VV-U2; Wed, 23 Jul 2003 03:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fESD-0006UK-DZ for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 03:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05071 for ; Wed, 23 Jul 2003 03:54:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fESA-0002pc-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 03:54:26 -0400 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 19fERz-0002oq-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 03:54:16 -0400 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Wed, 23 Jul 2003 10:54:44 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 10:48:19 +0200 Message-ID: From: Sasha Vainshtein To: "'Alex Zinin'" , l2vpn@ietf.org Cc: Alik Shimelmits , Gonen Zilber Subject: RE: On VPLS and Routing Protocols Date: Wed, 23 Jul 2003 10:48:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Alex, It has been always my impression that a VPLS is a set of (virtual) LAN switches interconnected by Ethernet (pseudo)-wires, and hence its behavior wrt the routing protocols it should behave just like a set of native LAN switches interconnected by (native) Ethernet wires. In particular, it is capable of delivering LAN broadcasts, hence I do not understand your reference to the "NBMA clouds. " If you treat a VPLS as a LAN, the L2 network view would be slightly different from your diagram: 10.2/16 | ...[R2]... | [Sw2] . / \ / \ / \ 10.1/16--[R1]-[Sw1]+---+[Sw3]-[R3]--10.3./16 . . .......... where Sw1/2/3 are native or virtual LAN switches interconnected by native or pseudo-wires. IMO the problem you've raised does not exist in the native LAN case because failure of a native wire between Sw1 and Sw3 would be detected by the SPT running between the native bridges and, as the result, Sw1 would start forwarding frames addressed to R3 via Sw2. This process would not be noticed by R1, R2 or R3 since they would still treat themselves as interconnected over a LAN. The current VPLS approach seems to strongly discourage using of SPT between vrtual LAN switches interconnected over the Ethernet PWs (there is a parallel email thread running on this list at the moment). IMO you have made a very good case for for revising this position. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Tuesday, July 22, 2003 8:56 PM > To: l2vpn@ietf.org > Subject: On VPLS and Routing Protocols > > > [RTG TA hat on] > > I'd like to comment on the issue of routing protocol operations under > the condition of a PW failure in a VPLS. > > First, let me note that both ISIS and OSPF protocols already know how > to deal with NBMA clouds that exhibit the same behavior as VPLS as far > as connectivity is concerned. > > ISIS takes the simplest approach--assumes any-to-any connectivity > (essentially full mesh of VCs) and treats the cloud as broadcast > media--DIS is elected, and the cloud itself is abstracted as a > pseudo-node with all routers attached to it. The broadcast service > itself is provided by the interface driver that replicates the > multicast packets for multiple VCs. The same approach is used in > OSPF's NBMA mode. The catch here is in potentially nasty problems that > show up when connectivity between non-DR/DIS routers changes. Here's > an example: > > 10.2/16 > | > ...[R2]... > . / \ . > 10.1/16--[R1]+----+[R3]--10.3./16 > . . > .......... > > Assume that R2 is elected as the DIS on the segment/cloud. > > R1 will establish an adjacency with R2, but not with R3, because both > R1 and R3 are non-DIS routers. This means that the RP will be actively > checking connectivity of the R1-R2 and R2-R3 VCs only, and if the > R1-R3 VC goes down, the RP will not notice it. However, connectivity > between R1 and R3 is still assumed by the protocol, and R1, for > example, will install a route to 10.3/16 as follows: > > 10.3/16 -> FrameRelay0/0, R3 > > That is, R1 will try to route directly to R3, not through R2. So if > R1-R3 VC is down, traffic will be black-holed. > > In the case of VPLS, the situation is essentially the same-- there is > a risk of traffic black-holing when one PW goes down. > > Another risk is inconsistency in the DIS/DR calculations among the > attached routers because of the differences in the sets of visible > neighbors. This one leads to problems with adjacency establishment, > which is a bit better, since they are visible at the RP level and > should be reported to the admin. > > There are no additional and already existing mechanisms in ISIS that > could help us address the problem. The operational model is to monitor > the status of each VC/PW and troubleshoot when an alarm is received. > OSPF is a little different. > > What we would like to have in the VPLS case is awareness of the PW > topology and ability of the RP to reroute around a failure (R1 > rerouting through R2 in the example above.) As only fully established > adjacencies are used to abstract the network topology, we essentially > need any-to-any adjacency establishment (vs DR/BDR to others in the > normal NBMA case). We also need the RP to abstract connectivity over > an emulated LAN as a set of p2p links, rather than a pseudo-node with > all routers connected to it. > > What's described above is the point-to-multipoint mode in OSPF. It is > normally used for NBMA clouds, but can be reused for the VPLS case. > There's one subtle detail though--neighbor discovery. > > Normally, in the p2mp mode, neighbors are assumed to be configured > manually. However, we don't want to require that VPLS customers have > to configure them, so we need hello-broadcast neighbor discovery > combined with p2mp OSPF network type. I know at least one major vendor > that supports it, but others may not, so it is worth spelling out. > > Note that the choice of treating an emulated LAN as a broadcast > network with DR/DIS vs a p2mp one, is not straight-forward. It is > about the balance between protocol scalability and network > availability. With the p2mp network approach, the number of > adjacencies is O(N^2) (vs O(N) in the broadcast network case), which > affects complexity of the protocol operation, most notably flooding > and SPF computation. On the other hand, it gives us better > connectivity in PW failure scenarios. > > Hope this sheds some light on this issue. > > If there's interest within the WG, these considerations could > be captured in a short document. > > Regards > > -- > Alex > http://www.psg.com/~zinin/ > > From exim@www1.ietf.org Wed Jul 23 12:15:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18579 for ; Wed, 23 Jul 2003 12:15:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMGp-0001X0-DN for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 12:15:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGFFHg005881 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 12:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMGp-0001Wm-85 for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 12:15:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18557 for ; Wed, 23 Jul 2003 12:15:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMGn-0005uW-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 12:15:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fMGi-0005uQ-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 12:15:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMGa-0001Ub-QH; Wed, 23 Jul 2003 12:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMG7-0001U5-8q for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 12:14:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18541 for ; Wed, 23 Jul 2003 12:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMG5-0005tp-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 12:14:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19fMFv-0005tE-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 12:14:19 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2003 09:19:35 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6NGD1Ai027605; Wed, 23 Jul 2003 12:13:01 -0400 (EDT) Message-Id: <200307231613.h6NGD1Ai027605@rtp-core-2.cisco.com> To: "Busschbach, Peter B (Peter)" cc: "'l2vpn@ietf.org'" Subject: Re: Truly Generalized VPLS (?) In-reply-to: Your message of Tue, 22 Jul 2003 15:11:57 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Jul 2003 12:13:00 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Peter> Since for a given VPLS, a U-PE needs PWs to a limited number of Peter> remote U-PEs, I thought it would make more sense to use RSVP-TE Peter> instead of LDP. I don't understand why you think so. Peter> However, the problem I have with the splicing approach is that it Peter> looks very much like manual provisioning I guess I don't really understand your alternative, and just how it differs from the splicing approach. Can you describe it in a bit more detail? From exim@www1.ietf.org Wed Jul 23 13:25:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20341 for ; Wed, 23 Jul 2003 13:25:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNMU-0004RQ-Sq for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 13:25:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHPA5a017071 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 13:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNMU-0004RG-Au for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:25:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20330 for ; Wed, 23 Jul 2003 13:25:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNMS-0006Hb-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 13:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fNMM-0006HY-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 13:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNML-0004QP-Kk; Wed, 23 Jul 2003 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNLy-0004Q8-Lc for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 13:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20301 for ; Wed, 23 Jul 2003 13:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNJp-0006HD-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 13:22:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19fNJe-0006Gu-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 13:22:14 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2003 10:22:40 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6NHLVAi011626; Wed, 23 Jul 2003 13:21:32 -0400 (EDT) Message-Id: <200307231721.h6NHLVAi011626@rtp-core-2.cisco.com> To: Alex Zinin cc: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Tue, 22 Jul 2003 11:56:24 -0700. <15274323000.20030722115624@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Jul 2003 13:21:31 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Wouldn't it be nice if the CE only had to be a routing peer of its PE, and if the PEs were responsible for redistributing all the routing info (using, say, BGP)? Then we wouldn't have this "look like a LAN for scalability but look like a full mesh of p2p links for availability" conundrum. Oh, sorry, wrong working group ... ;-) If we look at the problem from an IPLS perspective, the "lack of full mesh" problem is that not all of the PEs supporting a given IPLS instance have operational PWs to all of the CEs that are attached to that IPLS instance. Note that each PE supporting an IPLS instance must know the IP addresses of all the CEs attached to that IPLS instance. If each PE sends to all the others the list of CEs that it "sees", then every PE will be able to determine whether there is a proper full mesh or not. In the non-transient absence of a full mesh, alarms could start to go off. Of course, the notion of "a PE sees a (remote) CE" would have to mean "a PE has an operational PW to a CE", where "operational" means "can pass data". The notion of "non-transient" would also have to be defined. One could also consider whether there should be any automatic action in addition to the sending of alarms. From exim@www1.ietf.org Wed Jul 23 13:43:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20871 for ; Wed, 23 Jul 2003 13:43:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNdr-0005MM-Sj for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 13:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHh7kh020582 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 13:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNdr-0005Lq-Mk for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20849 for ; Wed, 23 Jul 2003 13:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNdp-0006Nj-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 13:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fNdj-0006Ng-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 13:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNdk-0005JJ-UD; Wed, 23 Jul 2003 13:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNdD-0005IU-Qx for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 13:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20833 for ; Wed, 23 Jul 2003 13:42:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNdB-0006NW-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 13:42:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19fNd0-0006N7-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 13:42:15 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2003 10:42:46 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6NHfaMK021099; Wed, 23 Jul 2003 13:41:36 -0400 (EDT) Message-Id: <200307231741.h6NHfaMK021099@rtp-core-1.cisco.com> To: vkompella@timetra.com cc: "Alex Zinin" , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Tue, 22 Jul 2003 12:22:47 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Jul 2003 13:41:36 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vach> If a VPLS node loses one PW (which has to be a PW on which the split Vach> horizon rule applies), it declares all but one of its PWs to be down, Vach> and turns the remaining PW into a VPLS spoke, i.e., split horizon Vach> doesn't apply to it. Doesn't this mean that if one PE crashes, every other PE will try to turn into a spoke? You also have to deal with the case in which a PW fails to come up to begin with, and the case in which a PE fails to learn about the need for a particular PW, due perhaps to a failure in the autodiscovery procedure. Note that the only failures this protects against are hardware and/or software bugs; since such failures may easily impact more than one PW, I'm not sure that a procedure which will redo the topology in the event of a single PW failure is really worthwhile. From exim@www1.ietf.org Wed Jul 23 14:21:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22337 for ; Wed, 23 Jul 2003 14:21:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOEf-0007II-PL for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 14:21:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NIL9wF028014 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 14:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOEe-0007Hk-Qo for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 14:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22322 for ; Wed, 23 Jul 2003 14:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fOEc-0006hr-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 14:21:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fOEW-0006ho-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 14:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOEY-0007Fv-5A; Wed, 23 Jul 2003 14:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fODy-0007FL-EN for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 14:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22314 for ; Wed, 23 Jul 2003 14:20:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fODv-0006hh-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 14:20:24 -0400 Received: from mailf.telia.com ([194.22.194.25]) by ietf-mx with esmtp (Exim 4.12) id 19fODk-0006hR-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 14:20:13 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h6NIJkrK029614; Wed, 23 Jul 2003 20:19:46 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h6NIJjc08494; Wed, 23 Jul 2003 20:19:45 +0200 (CEST) Message-ID: <3F1ED031.8000006@pi.se> Date: Wed, 23 Jul 2003 20:13:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org CC: Vach Kompella , Thomas Narten , Alex Zinin Subject: WG last call - l2vpn requirements and framework Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, this is to initiate a WG last call on two documents: "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks" and "L2VPN Framework" Note: Both documents has been renamed after they been allocated to the L2VPN working group, but the content has not been changed. The last call ends (as agreed in Vienna) August 20th, the longer last call period because of the vaction periods in Europe and the US. Please address your comments to the list. And note that positive and supportive comments are welcome. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From exim@www1.ietf.org Wed Jul 23 15:09:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24504 for ; Wed, 23 Jul 2003 15:09:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOz7-0000qB-9R for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 15:09:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJ99EW003218 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 15:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOz7-0000pi-2w for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 15:09:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24464 for ; Wed, 23 Jul 2003 15:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fOz4-00072o-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 15:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fOyx-00072l-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 15:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOyz-0000lF-AV; Wed, 23 Jul 2003 15:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOyK-0000km-5C for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 15:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24372; Wed, 23 Jul 2003 15:08:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fOyH-00072f-00; Wed, 23 Jul 2003 15:08:17 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19fOy6-000721-00; Wed, 23 Jul 2003 15:08:06 -0400 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIH00614RHLE6@firewall.wcom.com>; Wed, 23 Jul 2003 19:00:57 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIH00801R8EC0@pmismtp06.wcomnet.com>; Wed, 23 Jul 2003 19:00:57 +0000 (GMT) Received: from dmcdysan ([166.32.199.64]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIH007JURGLO7@pmismtp06.wcomnet.com>; Wed, 23 Jul 2003 19:00:22 +0000 (GMT) Date: Wed, 23 Jul 2003 15:00:27 -0400 From: Dave McDysan Subject: MPLS 2003 International Conference To: Mpls , Ccamp , l2vpn@ietf.org, l3vpn@ietf.org, pwe3@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit MPLS 2003 International Conference Omni Shoreham Hotel, Washington D.C. October 26-28, 2003 ================================================================== http://www.mpls2003.com ================================================================== You are cordially invited to attend the MPLS 2003 International Conference to be held in Washington D.C. October 26-28, 2003 hosted by ISOCORE. The 3-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Registration for the conference is now open. Early registration discounts are extremely lucrative and are valid for a limited time only. To register, go to: http://www.mpls2003.com/registration.htm Important Dates: --------------------- - Early Registration Rates Cut-Off Date: July 30 - Tutorials: October 26, 9:00am - 5:30 pm - Conference sessions: October 27-28, 8:45am-6:30pm - Exhibits: October 27-28, 8:45am-6:30pm Program: -------- (visit http://mpls2003.com/sessions.htm for details) Sunday October 26 Tutorial 1 Tutorial 2: VPNs Tutorial 3: Layer 2 VPNs/VPLS Tutorial 4: MPLS Security Monday, October 27 Opening remarks - Peter Hill (BellSouth Telecommunications) & Dr. Hamid Ahmadi (AT&T Labs) Introduction - Luca Martini (Level3 Communications) Keynote Session: Convergence (Service Provider's Perspective) - What is the Role of MPLS in Network Convergence? - MPLS: The Catalyst of Convergence? Session: OAM - New Developments in MPLS and IP OAM - Network Management of MPLS-based VPNs - MPLS Convergence, Control and OAM Implications - Service OA&M for MPLS VPNs Session: Reliability - High Availability for MPLS LSRs - Next Generation Core Routers: Defining IP Reliability and Resiliency - High Resiliency MPLS Network Design - Hardening MPLS-based Networks Session: L2/L3 VPNs - BGP-VPN Services: Lessons Learned - Design and Deploy Scalable Inter-AS MPLS VPNs - L2-MPLS Networks - MPLS in Multi-AS Networks Panel: MPLS as a Fusing Technology - Chair: P. Hill, VP Technology Planning & Deployment, BellSouth Telecommunications - Members: D. McDysan (MCI), C. Kalmanek (ATT), P. Delavenne (LambdaNet), R. Wilder (Masergy), R. Doukov (Flag Telecom), McManus (Verizon), C. Liljenstolpe (Cable & Wireless), Y. Sato (NTT) Tuesday, October 28 Keynote Lessons Learned - Yakov Rekhter Critical Considerations for Network Consolidation - Daniel Awduche (MCI) Session: Layer 2 Transport & Interworking over MPLS - VPLS - Remember LANE? - Transitioning a Profitable Service Portfolio to an MPLS Core Network - VPLS Provisioning, Performance and Scalability: Problems and Solutions Session: IP Optical Integration - Optical Market Forces on GMPLS - Multiservice Metro Networks in Sweden and Their Plans to Go GMPLS - Photonic Internet Laboratory: New Challenges for Future Photonic Network - Generalized VPNs (GVPNs) Session: New MPLS Features - Scalable Multicast MPLS Technology for Next Generation Broadband Services Network - Multicast Traffic Engineering with MPLS - LDP Fast Convergence - How to secure an MPLS/VPN network - Integration of IPv6 and IPv6 VPN Services over MPLS Session: Traffic Engineering - Inter-area and Inter-AS MPLS Traffic Engineering - Traffic Engineering in Hierarchical Multiprovider Networks - Multi-Region (multiarea/multiAS) Traffic Engineering - Advanced MPLS Application Testing Session: Service & Provisioning Issues - MPLS Network Management: Enterprise Deployment Management - Attracting New Enterprise Customers with MPLS VPN Services - MPLS Beyond Service Provider Cores - Critical Quality of Service Issues in MPLS Networks - Practical Implementation of Tools Allied to the Network Management of IP/MPLS-based Networks We look forward to seeing you at the Conference. Regards, Dave McDysan, Luca Martini, Bijan Jabbari From exim@www1.ietf.org Wed Jul 23 18:12:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05534 for ; Wed, 23 Jul 2003 18:12:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRqC-00020K-L1 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 18:12:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NMC8Vr007700 for l2vpn-archive@odin.ietf.org; Wed, 23 Jul 2003 18:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRqC-000207-HP for l2vpn-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 18:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05484 for ; Wed, 23 Jul 2003 18:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRq9-0001Fp-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 18:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fRq4-0001Fm-00 for l2vpn-web-archive@ietf.org; Wed, 23 Jul 2003 18:12:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRq5-0001z8-0A; Wed, 23 Jul 2003 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRpG-0001uB-8w for l2vpn@optimus.ietf.org; Wed, 23 Jul 2003 18:11:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05371 for ; Wed, 23 Jul 2003 18:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRpD-0001FP-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 18:11:07 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19fRp2-0001FC-00 for l2vpn@ietf.org; Wed, 23 Jul 2003 18:10:56 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6NMA1A17552 for ; Wed, 23 Jul 2003 17:10:01 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 23 Jul 2003 18:10:00 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'erosen@cisco.com'" Cc: "'l2vpn@ietf.org'" Subject: RE: Truly Generalized VPLS (?) Date: Wed, 23 Jul 2003 18:09:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Peter> Since for a given VPLS, a U-PE needs PWs to a > limited number of > Peter> remote U-PEs, I thought it would make more sense > to use RSVP-TE > Peter> instead of LDP. > > I don't understand why you think so. > > Peter> However, the problem I have with the splicing > approach is that it > Peter> looks very much like manual provisioning > > I guess I don't really understand your alternative, and just > how it differs > from the splicing approach. Can you describe it in a bit > more detail? > Eric, I must have done a very poor job explaining my thoughts. I am sorry about that. Let me try again. GVPLS describes a solution where the end-to-end data path between two U-PEs for a given VPLS consists of up to three PWs that are spliced together. The N-PEs that tie the PWs together essentially do label switching: they take traffic received over one PW and forward it over another. The encapsulated data (including Control Word, etc) remains unchanged; only the value of the PW label changes. The core of my proposal is to recognize that the end-to-end data path between two U-PEs is *one* LSP that is routed through intermediate hops instead of three separate LSPs that are spliced together. The N-PEs are the intermediate hops, and, as said before, they are functioning as MPLS switches that switch based on PW labels. The second part of my proposal is to generalize this concept: an N-PE in a Decoupled VPLS solution is nothing more than an MPLS switch that is designated to switch PW labels: a "PW-LSR". How is a PW-LSR different than other MPLS switches in the Service Provider's network? It is not. It is just that the other switches in the MPLS network will not see the PW labels, because the PW-LSRs will use label stacking to tunnel the PWs through these other switches. The only complication is that the PW infrastructure (i.e. the U-PEs and the intermediate hops, the N-PEs or PW-LSRs) is an overlay network on top the MPLS network at large. To discover the topology of that PW infrastructure, you need to run a routing protocol within that overlay network. I hesitate to use the term "virtual routing", but that is probably the best way to look at it. [This may sound complicated, but isn't this a general issue? MPLS offers the possibility to create multiple network layers, one on top of the other, through label stacking. To fully utilize that functionality, it should be possible to run independent routing protocols in every layer] A U-PE discovers through auto-discovery the other U-PEs that belong to the same VPLS. It sets up PWs to these other U-PEs. In most cases, such a PW will be an LSP that goes through multiple intermediate hops. I seems to me that RSVP-TE is the most appropriate protocol to set up these multi-hop LSPs. The alternatives: 1) A targeted LDP between the two U-PEs doesn't work because it won't tell the intermediate hops how to switch PW labels. 2) Flooding LDP through the entire PW infrastructure might work, but is seems overkill because it will reach all other U-PEs instead of just the subset that belongs to the same VPLS. Besides, since each LSP needs to uniquely identify Source and Destination U-PEs , path merging is not allowed. RSVP-TE is straightforward: through autodiscovery, source and destination of the LSP are known and through the routing protocol in the PW infrastructure, the intermediate hops know which path to follow. ----------------------------------------------- Compared to the gvpls draft, I think I am proposing two things that are different: - Introduction of a routing protocol to discover the topology of the PW infrastructure. However, I think that something similar is required in the gvpls approach. E.g. in the current draft it is not clear to me how a SRC-N-PE knows which DST-N-PE to connect to to reach a DST-U-PE. If you don't want to rely on manual provisioning by the service provider, you need some form of topology discovery. - Use of RSVP-TE instead of Targeted LDP for PW set up. I think that the decision to consider a PW as an LSP between two peers without intermediate hops is a severe limitation. The splicing approach in the gvpls draft is an attempt to salvage the situation, but it is a non-standard fix to a problem for which well-known solutions already exist. Peter From exim@www1.ietf.org Thu Jul 24 21:14:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07590 for ; Thu, 24 Jul 2003 21:14:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr9z-0008Tf-Sv for l2vpn-archive@odin.ietf.org; Thu, 24 Jul 2003 21:14:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1EFOC032581 for l2vpn-archive@odin.ietf.org; Thu, 24 Jul 2003 21:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr9z-0008TQ-Nz for l2vpn-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07575 for ; Thu, 24 Jul 2003 21:14:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fr9x-0003cm-00 for l2vpn-web-archive@ietf.org; Thu, 24 Jul 2003 21:14:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fr9r-0003cg-00 for l2vpn-web-archive@ietf.org; Thu, 24 Jul 2003 21:14:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr9l-0008R5-0s; Thu, 24 Jul 2003 21:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr99-0008Nt-Cx for l2vpn@optimus.ietf.org; Thu, 24 Jul 2003 21:13:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07528 for ; Thu, 24 Jul 2003 21:13:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fr96-0003cR-00 for l2vpn@ietf.org; Thu, 24 Jul 2003 21:13:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19fr8w-0003cM-00 for l2vpn@ietf.org; Thu, 24 Jul 2003 21:13:10 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19fr8l-000Ly4-S8; Fri, 25 Jul 2003 01:12:59 +0000 Date: Thu, 24 Jul 2003 18:05:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14169932868.20030724180555@psg.com> To: "Vach Kompella" CC: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vach, Optimizations are fine. However, from the routing perspective, if there still are potential cases where any-to-any connectivity is not maintained, those considerations apply. -- Alex http://www.psg.com/~zinin/ Tuesday, July 22, 2003, 12:22:47 PM, Vach Kompella wrote: > Given a VPLS model that includes HVPLS, there is a straightforward modification > of the VPLS topology to remove the blackhole. However, it may result in > flapping. [...] From exim@www1.ietf.org Thu Jul 24 21:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08063 for ; Thu, 24 Jul 2003 21:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frUC-00016E-49 for l2vpn-archive@odin.ietf.org; Thu, 24 Jul 2003 21:35:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1Z8Ut004220 for l2vpn-archive@odin.ietf.org; Thu, 24 Jul 2003 21:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frUB-00015z-Uv for l2vpn-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08051 for ; Thu, 24 Jul 2003 21:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frU9-0003kF-00 for l2vpn-web-archive@ietf.org; Thu, 24 Jul 2003 21:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frU3-0003kC-00 for l2vpn-web-archive@ietf.org; Thu, 24 Jul 2003 21:34:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frU4-00013b-TV; Thu, 24 Jul 2003 21:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frTu-00013L-J4 for l2vpn@optimus.ietf.org; Thu, 24 Jul 2003 21:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08041 for ; Thu, 24 Jul 2003 21:34:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frTr-0003k4-00 for l2vpn@ietf.org; Thu, 24 Jul 2003 21:34:47 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19frTh-0003k1-00 for l2vpn@ietf.org; Thu, 24 Jul 2003 21:34:37 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19frTc-000NFD-Lg; Fri, 25 Jul 2003 01:34:32 +0000 Date: Thu, 24 Jul 2003 18:27:20 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6171217925.20030724182720@psg.com> To: Sasha Vainshtein CC: l2vpn@ietf.org, Alik Shimelmits , Gonen Zilber Subject: Re: On VPLS and Routing Protocols In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sasha, > Alex, > It has been always my impression that a VPLS is a set of (virtual) LAN > switches interconnected by Ethernet (pseudo)-wires, and hence its behavior > wrt the routing protocols it should behave just like a set of > native LAN switches interconnected by (native) Ethernet wires. It is certainly possible to treat a VPLS as a normal LAN in a steady state. The considerations I brought are applicable to the situations where any-to-any connectivity assumption is not true anymore because of PW failures. > In particular, it is capable of delivering LAN broadcasts, hence > I do not understand your reference to the "NBMA clouds. " The analogy is along the lines of the connectivity model, topology abstraction and route calculation. The difference in broadcast capabilities of the L2 technology itself is not extremely important here, as lack of it in the NBMA case is worked around either at the interface driver level or through manual configuration of the neighbors and sending unicast hellos at the RP level. [skip] > IMO the problem you've raised does not exist in the native LAN case sure > The current VPLS approach seems to strongly discourage using of SPT > between vrtual LAN switches interconnected over the Ethernet PWs > (there is a parallel email thread running on this list at the moment). > IMO you have made a very good case for for revising this position. the intent was not to revise that part, but given the realities of VPLS discuss the routing aspects. Alex From exim@www1.ietf.org Fri Jul 25 14:08:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13968 for ; Fri, 25 Jul 2003 14:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6z5-00028c-JT for l2vpn-archive@odin.ietf.org; Fri, 25 Jul 2003 14:08:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PI839N008215 for l2vpn-archive@odin.ietf.org; Fri, 25 Jul 2003 14:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6z5-00028Q-DS for l2vpn-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 14:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13960 for ; Fri, 25 Jul 2003 14:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6z3-0002Lf-00 for l2vpn-web-archive@ietf.org; Fri, 25 Jul 2003 14:08:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g6z2-0002Lc-00 for l2vpn-web-archive@ietf.org; Fri, 25 Jul 2003 14:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6z2-000281-RR; Fri, 25 Jul 2003 14:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6yN-0001xj-Uw for l2vpn@optimus.ietf.org; Fri, 25 Jul 2003 14:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13954 for ; Fri, 25 Jul 2003 14:07:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6yL-0002LZ-00 for l2vpn@ietf.org; Fri, 25 Jul 2003 14:07:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19g6yJ-0002LW-00 for l2vpn@ietf.org; Fri, 25 Jul 2003 14:07:15 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6PI6gMK022838; Fri, 25 Jul 2003 14:06:42 -0400 (EDT) Message-Id: <200307251806.h6PI6gMK022838@rtp-core-1.cisco.com> To: Alex Zinin , Sasha Vainshtein cc: "Vach Kompella" , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Thu, 24 Jul 2003 18:05:55 -0700. <14169932868.20030724180555@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 25 Jul 2003 14:06:42 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Alex> Vach, Alex> Optimizations are fine. However, from the routing perspective, Alex> if there still are potential cases where any-to-any connectivity Alex> is not maintained, those considerations apply. I'm not sure you've fully understood Vach's proposal. He is trying to come up with a scheme that maintains the any-to-any connectivity even if a PW fails. Such a scheme, if successful, would certainly eliminate the routing problem that you've described. Sasha> In particular, it is capable of delivering LAN broadcasts, hence I do Sasha> not understand your reference to the "NBMA clouds. " That's because you're taking a layer 1/2 perspective instead of a layer 3 perspective ;-) When link state routing protocols operate over a LAN, they use a certain "optimization" (all that "designated router" stuff). This optimization doesn't produce the correct result if the "VPLS full mesh" fails. However, one could eliminate this problem by not using the optimization when the routers are connected over a VPLS. Currently routers do know how to cope with the situation in which there are multiple peers out a single interface, but the LAN optimizations can't be used; this is exactly the situation that occurs when a router connects to an NBMA cloud. One solution is to have the routers use this same set of procedures when connected to a VPLS; that's how "NBMA" entered the picture. Having said all that, this probably isn't really a workable solution, because it may not always be apparent to a router that a particular LAN interface leads to a VPLS rather than a native LAN. Sasha> The current VPLS approach seems to strongly discourage using of SPT Sasha> between virtual LAN switches interconnected over the Ethernet PWs Sasha> (there is a parallel email thread running on this list at the Sasha> moment). IMO you have made a very good case for for revising this Sasha> position. I don't think so. Using SPT between the virtual LAN switches has a number of problems as well: - Every PE has to be able to serve as a transit point for traffic from any second PE to any third PE. (This in itself probably makes the idea a non-starter.) - Highly suboptimal routing in the backbone. - The usual spanning tree issues, e.g., all traffic is carried on a small set of links while other links remain idle, need to manage spanning tree within backbone, no inter-provider support, etc. Not to mention that one of the reasons for this whole effort is to keep the spanning tree out of the backbone. A better approach would be to see if there is a way to detect that the full mesh has failed (say, by having each PE tell all the others "here are the other PEs I can talk to in the specified VPLS instance"), and to determine what action to take when the full mesh does fail. From exim@www1.ietf.org Fri Jul 25 16:11:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21148 for ; Fri, 25 Jul 2003 16:11:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8u8-0007wf-SI for l2vpn-archive@odin.ietf.org; Fri, 25 Jul 2003 16:11:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PKB4nS030535 for l2vpn-archive@odin.ietf.org; Fri, 25 Jul 2003 16:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8u8-0007wQ-My for l2vpn-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 16:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21132 for ; Fri, 25 Jul 2003 16:11:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g8u7-0003it-00 for l2vpn-web-archive@ietf.org; Fri, 25 Jul 2003 16:11:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g8u6-0003iq-00 for l2vpn-web-archive@ietf.org; Fri, 25 Jul 2003 16:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8u5-0007vz-K4; Fri, 25 Jul 2003 16:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8tG-0007vc-V4 for l2vpn@optimus.ietf.org; Fri, 25 Jul 2003 16:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21119 for ; Fri, 25 Jul 2003 16:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g8tF-0003id-00 for l2vpn@ietf.org; Fri, 25 Jul 2003 16:10:09 -0400 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 19g8tE-0003iP-00 for l2vpn@ietf.org; Fri, 25 Jul 2003 16:10:08 -0400 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Fri, 25 Jul 2003 23:10:58 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 23:04:30 +0200 Message-ID: From: Sasha Vainshtein To: "'erosen@cisco.com'" , Alex Zinin Cc: Vach Kompella , l2vpn@ietf.org, Alik Shimelmits , Gonen Zilber Subject: RE: On VPLS and Routing Protocols Date: Fri, 25 Jul 2003 23:04:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric and all, Thank you for the clarification, Please see a couple of comments inline. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, July 25, 2003 8:07 PM > To: Alex Zinin; Sasha Vainshtein > Cc: Vach Kompella; l2vpn@ietf.org > Subject: Re: On VPLS and Routing Protocols > ... snipped ... > Having said all that, this probably isn't really a > workable solution, > because it may not always be apparent to a router that a > particular LAN > interface leads to a VPLS rather than a native LAN. > Exactly. On the other hand, there are other cases where such a distinction seems necessary, e.g., see the discussion of operation of OSPF over an IP PW in draft-shah-arp-mediation-02.txt. > > Sasha> The current VPLS approach seems to strongly > Sasha> discourage using of SPT between virtual LAN switches > Sasha> interconnected over the Ethernet PWs > Sasha> (there is a parallel email thread running on > Sasha> this list at the moment). IMO you have made a > Sasha> very good case for or revising this > Sasha> position. > > I don't think so. Using SPT between the virtual LAN > switches has a number > of problems as well: > > - Every PE has to be able to serve as a transit point for > traffic from any second PE to any third PE. > (This in itself probably makes the idea a non-starter.) > > - Highly suboptimal routing in the backbone. > > - The usual spanning tree issues, e.g., all traffic is > carried on a small set of links while other links remain > idle, need to manage spanning tree within backbone, no > inter-provider support, etc. > > Not to mention that one of the reasons for this whole effort > is to keep the spanning tree out of the backbone. > This is an interesting point. I have probably missed it altogether when I have been reading the VPLS requirements documents. > > A better approach would be to see if there is a way to > detect that the full mesh has failed (say, by having each > PE tell all the others "here are the other PEs I can talk to in > the specified VPLS instance"), and to determine > what action to take when the full mesh does fail. > This really looks like a much better approach. I do not remember that it has been actively discussed in the existing VPLS proposals. Did I miss something? > > From exim@www1.ietf.org Fri Jul 25 21:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04691 for ; Fri, 25 Jul 2003 21:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gDhE-0004a5-DR for l2vpn-archive@odin.ietf.org; Fri, 25 Jul 2003 21:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6Q1I4il017605 for l2vpn-archive@odin.ietf.org; Fri, 25 Jul 2003 21:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gDhE-0004Zs-9p for l2vpn-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 21:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04667 for ; Fri, 25 Jul 2003 21:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gDhB-00002U-00 for l2vpn-web-archive@ietf.org; Fri, 25 Jul 2003 21:18:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gDhB-00002O-00 for l2vpn-web-archive@ietf.org; Fri, 25 Jul 2003 21:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gDhB-0004ZT-9f; Fri, 25 Jul 2003 21:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gDgF-0004Wq-3E for l2vpn@optimus.ietf.org; Fri, 25 Jul 2003 21:17:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04642 for ; Fri, 25 Jul 2003 21:16:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gDgC-000019-00 for l2vpn@ietf.org; Fri, 25 Jul 2003 21:17:00 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19gDgB-000009-00 for l2vpn@ietf.org; Fri, 25 Jul 2003 21:17:00 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6Q1GQuI023133; Fri, 25 Jul 2003 18:16:28 -0700 (PDT) Received: from cisco.com (stealth-10-32-252-84.cisco.com [10.32.252.84]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AJQ15030; Fri, 25 Jul 2003 18:12:03 -0700 (PDT) Message-ID: <3F21D667.6DEE735B@cisco.com> Date: Fri, 25 Jul 2003 18:16:24 -0700 From: Wei Luo X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: "Busschbach, Peter B (Peter)" CC: "'erosen@cisco.com'" , "'l2vpn@ietf.org'" Subject: Re: Truly Generalized VPLS (?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Peter, Maybe you allow me to fill in some details so I can understand your proposal better. Before doing that, I have to point out there could be any number of intermediate hops (MPLS LSRs) between the U-PE and N-PE, and between the N-PE and N-PE in the distributed model. In other words, these U-PE and N-PE are not necessarily directly connected to each other. Scenario 1: If you want to use RSVP-TE for the end-to-end PW signaling and treat the N-PE just like any other LSRs, all LSRs between the U-PEs (inclusive) must be involved in PW signaling. In other words, the PWs are not transparent to the core network, and the core LSRs must have stateful information on every PW traversing them. Each U-PE might only have to manage a moderate number of PWs, but the core LSRs have to manage a very large number of PW LSPs in addition to all the IPv4 LSPs, which require large number of memory and process cycles. This reminds me about the legacy L2VPN based on Frame Relay and ATM network, and the scalability would be a real concern for the core LSRs. Scenario 2: Use RSVP-TE between U-PE and N-PE, and between N-PE and N-PE only. I am not sure if there is such a thing called directed RSVP (like directed LDP) that runs between the PEs and is transparent to intermediate LSRs. Even if there is, I am not so sure how it would be better or different from using directed LDP. Which scenario do you have in mind? ---Wei "Busschbach, Peter B (Peter)" wrote: > > > Peter> Since for a given VPLS, a U-PE needs PWs to a > > limited number of > > Peter> remote U-PEs, I thought it would make more sense > > to use RSVP-TE > > Peter> instead of LDP. > > > > I don't understand why you think so. > > > > Peter> However, the problem I have with the splicing > > approach is that it > > Peter> looks very much like manual provisioning > > > > I guess I don't really understand your alternative, and just > > how it differs > > from the splicing approach. Can you describe it in a bit > > more detail? > > > > Eric, > > I must have done a very poor job explaining my thoughts. I am sorry about that. Let me try again. > > GVPLS describes a solution where the end-to-end data path between two U-PEs for a given VPLS consists of up to three PWs that are spliced together. The N-PEs that tie the PWs together essentially do label switching: they take traffic received over one PW and forward it over another. The encapsulated data (including Control Word, etc) remains unchanged; only the value of the PW label changes. > > The core of my proposal is to recognize that the end-to-end data path between two U-PEs is *one* LSP that is routed through intermediate hops instead of three separate LSPs that are spliced together. > > The N-PEs are the intermediate hops, and, as said before, they are functioning as MPLS switches that switch based on PW labels. The second part of my proposal is to generalize this concept: an N-PE in a Decoupled VPLS solution is nothing more than an MPLS switch that is designated to switch PW labels: a "PW-LSR". > > How is a PW-LSR different than other MPLS switches in the Service Provider's network? It is not. It is just that the other switches in the MPLS network will not see the PW labels, because the PW-LSRs will use label stacking to tunnel the PWs through these other switches. > > The only complication is that the PW infrastructure (i.e. the U-PEs and the intermediate hops, the N-PEs or PW-LSRs) is an overlay network on top the MPLS network at large. To discover the topology of that PW infrastructure, you need to run a routing protocol within that overlay network. I hesitate to use the term "virtual routing", but that is probably the best way to look at it. > > [This may sound complicated, but isn't this a general issue? MPLS offers the possibility to create multiple network layers, one on top of the other, through label stacking. To fully utilize that functionality, it should be possible to run independent routing protocols in every layer] > > A U-PE discovers through auto-discovery the other U-PEs that belong to the same VPLS. It sets up PWs to these other U-PEs. In most cases, such a PW will be an LSP that goes through multiple intermediate hops. > > I seems to me that RSVP-TE is the most appropriate protocol to set up these multi-hop LSPs. The alternatives: > > 1) A targeted LDP between the two U-PEs doesn't work because it won't tell the intermediate hops how to switch PW labels. > > 2) Flooding LDP through the entire PW infrastructure might work, but is seems overkill because it will reach all other U-PEs instead of just the subset that belongs to the same VPLS. Besides, since each LSP needs to uniquely identify Source and Destination U-PEs , path merging is not allowed. > > RSVP-TE is straightforward: through autodiscovery, source and destination of the LSP are known and through the routing protocol in the PW infrastructure, the intermediate hops know which path to follow. > > ----------------------------------------------- > > Compared to the gvpls draft, I think I am proposing two things that are different: > > - Introduction of a routing protocol to discover the topology of the PW infrastructure. However, I think that something similar is required in the gvpls approach. E.g. in the current draft it is not clear to me how a SRC-N-PE knows which DST-N-PE to connect to to reach a DST-U-PE. If you don't want to rely on manual provisioning by the service provider, you need some form of topology discovery. > > - Use of RSVP-TE instead of Targeted LDP for PW set up. I think that the decision to consider a PW as an LSP between two peers without intermediate hops is a severe limitation. The splicing approach in the gvpls draft is an attempt to salvage the situation, but it is a non-standard fix to a problem for which well-known solutions already exist. > > Peter From exim@www1.ietf.org Sun Jul 27 22:06:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01988 for ; Sun, 27 Jul 2003 22:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gxOo-0007sl-Lh for l2vpn-archive@odin.ietf.org; Sun, 27 Jul 2003 22:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S266Q9030298 for l2vpn-archive@odin.ietf.org; Sun, 27 Jul 2003 22:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gxOo-0007sb-F4 for l2vpn-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 22:06:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01968 for ; Sun, 27 Jul 2003 22:06:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gxOl-0002UD-00 for l2vpn-web-archive@ietf.org; Sun, 27 Jul 2003 22:06:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gxOk-0002U9-00 for l2vpn-web-archive@ietf.org; Sun, 27 Jul 2003 22:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gxOj-0007rq-Ra; Sun, 27 Jul 2003 22:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gxNt-0007pd-5i for l2vpn@optimus.ietf.org; Sun, 27 Jul 2003 22:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01934 for ; Sun, 27 Jul 2003 22:05:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gxNq-0002TA-00 for l2vpn@ietf.org; Sun, 27 Jul 2003 22:05:06 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19gxNp-0002Sx-00 for l2vpn@ietf.org; Sun, 27 Jul 2003 22:05:05 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6S24Xs07073 for ; Sun, 27 Jul 2003 21:04:33 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Sun, 27 Jul 2003 22:04:32 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Wei Luo'" Cc: "'erosen@cisco.com'" , "'l2vpn@ietf.org'" Subject: RE: Truly Generalized VPLS (?) Date: Sun, 27 Jul 2003 22:04:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Wei Luo, Thanks for your comments. I had scenario 2 in mind. Further comments in-line. Peter > -----Original Message----- > From: Wei Luo [mailto:luo@cisco.com] > Sent: Friday, July 25, 2003 9:16 PM > To: Busschbach, Peter B (Peter) > Cc: 'erosen@cisco.com'; 'l2vpn@ietf.org' > Subject: Re: Truly Generalized VPLS (?) > > > Peter, > > Maybe you allow me to fill in some details so I can > understand your proposal > better. Before doing that, I have to point out there could > be any number of > intermediate hops (MPLS LSRs) between the U-PE and N-PE, and > between the N-PE > and N-PE in the distributed model. In other words, these > U-PE and N-PE are not > necessarily directly connected to each other. I agree, but by establishing transport LSPs between them, they become peers and the intermediate switches will only see the outer label and not the inner PW-LSP, i.e. scenario 2. > > Scenario 1: > > If you want to use RSVP-TE for the end-to-end PW signaling > and treat the N-PE > just > like any other LSRs, all LSRs between the U-PEs (inclusive) > must be involved in > PW signaling. In other words, the PWs are not transparent to > the core network, > and the core LSRs must have stateful information on every PW > traversing them. Yes, that would be a bit much. Therefore, you use label stacking, i.e. scenario 2. > Each U-PE might only have to manage a moderate number of PWs, > but the core LSRs > have to manage a very large number of PW LSPs in addition to > all the IPv4 LSPs, > which require large number of memory and process cycles. > This reminds me about > the legacy L2VPN based on Frame Relay and ATM network, and > the scalability would > be a real concern for the core LSRs. What exactly is the problem with Frame and ATM scaleability? In ATM you have a two-level hierarchy (VPs and VCs) and as far as I know, that works perfectly fine. Service providers have been able to build very large networks serving tens of thousands of customers. > > Scenario 2: > > Use RSVP-TE between U-PE and N-PE, and between N-PE and N-PE > only. I am not > sure if there is such a thing called directed RSVP (like > directed LDP) that runs > between the PEs and is transparent to intermediate LSRs. > Even if there is, I am > not so sure how it would be better or different from using > directed LDP. If you want to use targeted LDP, you need three sessions: between SRC-U-PE and SRC-N-PE; between SRC-N-PE and DST-N-PE; and between DST-N-PE and DST-U-PE. As a consequence you set up three independent PWs. You can consider these as one logical PW, but that would mean that you have to specify all kinds of additional procedures. E.g. 1) TTL Does each element in the path set the TTL to 2, or does the SRC-N-PE set it to 4 and the subsequent nodes decrease the value? 2) OAM If the SRC-U-PE sends a VCCV Ping message, is it terminated by SRC-N-PE? And is the PW between SRC-N-PE and DST-N-PE tested independently? Or is the VCCV Ping sent by SRC-U-PE, forwarded by SRC-N-PE to DST-N-PE, which in turn sends it to DST-U-PE? And if one of the reply messages on any of these segments does not arrive, how is that reported to SRC-U-PE? By not sending a response, or by sending an error message? 3) Protection switching Suppose SRC-U-PE is dual-homed but has set up ony a single spliced PW to DST-U-PE. Now suppose that the PW segment between SRC-N-PE and DST-N-PE goes down and can not be restored. How does SRC-U-PE find out that it needs to set up another PW tthrogh the other N-PE it is connected to? Does N-PE send an error message that reports a fault on a segment of the spliced PW? All these issues can be solved, but they need to be specified unambiguously. On the other hand, if you use RSVP-TE and consider the end-to-end PW between SRC-U-PE and DST-U-PE as a single LSP, the solution to these issues follows immediately from existing standards. Hence my question: why are we defining a non-standard way to do something for which standards already exist? > > Which scenario do you have in mind? 2 > > ---Wei > > > "Busschbach, Peter B (Peter)" wrote: > > > > > Peter> Since for a given VPLS, a U-PE needs PWs to a > > > limited number of > > > Peter> remote U-PEs, I thought it would make more sense > > > to use RSVP-TE > > > Peter> instead of LDP. > > > > > > I don't understand why you think so. > > > > > > Peter> However, the problem I have with the splicing > > > approach is that it > > > Peter> looks very much like manual provisioning > > > > > > I guess I don't really understand your alternative, and just > > > how it differs > > > from the splicing approach. Can you describe it in a bit > > > more detail? > > > > > > > Eric, > > > > I must have done a very poor job explaining my thoughts. I > am sorry about that. Let me try again. > > > > GVPLS describes a solution where the end-to-end data path > between two U-PEs for a given VPLS consists of up to three > PWs that are spliced together. The N-PEs that tie the PWs > together essentially do label switching: they take traffic > received over one PW and forward it over another. The > encapsulated data (including Control Word, etc) remains > unchanged; only the value of the PW label changes. > > > > The core of my proposal is to recognize that the end-to-end > data path between two U-PEs is *one* LSP that is routed > through intermediate hops instead of three separate LSPs that > are spliced together. > > > > The N-PEs are the intermediate hops, and, as said before, > they are functioning as MPLS switches that switch based on PW > labels. The second part of my proposal is to generalize this > concept: an N-PE in a Decoupled VPLS solution is nothing more > than an MPLS switch that is designated to switch PW labels: a > "PW-LSR". > > > > How is a PW-LSR different than other MPLS switches in the > Service Provider's network? It is not. It is just that the > other switches in the MPLS network will not see the PW > labels, because the PW-LSRs will use label stacking to tunnel > the PWs through these other switches. > > > > The only complication is that the PW infrastructure (i.e. > the U-PEs and the intermediate hops, the N-PEs or PW-LSRs) is > an overlay network on top the MPLS network at large. To > discover the topology of that PW infrastructure, you need to > run a routing protocol within that overlay network. I > hesitate to use the term "virtual routing", but that is > probably the best way to look at it. > > > > [This may sound complicated, but isn't this a general > issue? MPLS offers the possibility to create multiple network > layers, one on top of the other, through label stacking. To > fully utilize that functionality, it should be possible to > run independent routing protocols in every layer] > > > > A U-PE discovers through auto-discovery the other U-PEs > that belong to the same VPLS. It sets up PWs to these other > U-PEs. In most cases, such a PW will be an LSP that goes > through multiple intermediate hops. > > > > I seems to me that RSVP-TE is the most appropriate protocol > to set up these multi-hop LSPs. The alternatives: > > > > 1) A targeted LDP between the two U-PEs doesn't work > because it won't tell the intermediate hops how to switch PW labels. > > > > 2) Flooding LDP through the entire PW infrastructure might > work, but is seems overkill because it will reach all other > U-PEs instead of just the subset that belongs to the same > VPLS. Besides, since each LSP needs to uniquely identify > Source and Destination U-PEs , path merging is not allowed. > > > > RSVP-TE is straightforward: through autodiscovery, source > and destination of the LSP are known and through the routing > protocol in the PW infrastructure, the intermediate hops know > which path to follow. > > > > ----------------------------------------------- > > > > Compared to the gvpls draft, I think I am proposing two > things that are different: > > > > - Introduction of a routing protocol to discover the > topology of the PW infrastructure. However, I think that > something similar is required in the gvpls approach. E.g. in > the current draft it is not clear to me how a SRC-N-PE knows > which DST-N-PE to connect to to reach a DST-U-PE. If you > don't want to rely on manual provisioning by the service > provider, you need some form of topology discovery. > > > > - Use of RSVP-TE instead of Targeted LDP for PW set up. I > think that the decision to consider a PW as an LSP between > two peers without intermediate hops is a severe limitation. > The splicing approach in the gvpls draft is an attempt to > salvage the situation, but it is a non-standard fix to a > problem for which well-known solutions already exist. > > > > Peter > From exim@www1.ietf.org Mon Jul 28 13:23:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13329 for ; Mon, 28 Jul 2003 13:23:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hBiG-0007KD-II for l2vpn-archive@odin.ietf.org; Mon, 28 Jul 2003 13:23:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SHN8HJ028157 for l2vpn-archive@odin.ietf.org; Mon, 28 Jul 2003 13:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hBiG-0007K4-Bk for l2vpn-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 13:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13323 for ; Mon, 28 Jul 2003 13:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hBiA-0005xC-00 for l2vpn-web-archive@ietf.org; Mon, 28 Jul 2003 13:23:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hBi9-0005x9-00 for l2vpn-web-archive@ietf.org; Mon, 28 Jul 2003 13:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hBi9-0007J2-HY; Mon, 28 Jul 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hBi2-0007Iq-N2 for l2vpn@optimus.ietf.org; Mon, 28 Jul 2003 13:22:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13318 for ; Mon, 28 Jul 2003 13:22:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hBi0-0005x6-00 for l2vpn@ietf.org; Mon, 28 Jul 2003 13:22:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hBhy-0005wx-00 for l2vpn@ietf.org; Mon, 28 Jul 2003 13:22:52 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2003 10:24:46 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6SHMIAi005188; Mon, 28 Jul 2003 13:22:18 -0400 (EDT) Message-Id: <200307281722.h6SHMIAi005188@rtp-core-2.cisco.com> To: "Busschbach, Peter B (Peter)" cc: "'l2vpn@ietf.org'" Subject: Re: Truly Generalized VPLS (?) In-reply-to: Your message of Wed, 23 Jul 2003 18:09:59 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Jul 2003 13:22:18 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Peter> How is a PW-LSR different than other MPLS switches in the Service Peter> Provider's network? It is not. It is just that the other switches in Peter> the MPLS network will not see the PW labels, because the PW-LSRs will Peter> use label stacking to tunnel the PWs through these other switches. The two PW endpoints have to agree on such things as the use of the control word, the use of signaling, etc. They may also need to send each other status info. These things are done using the control plane. If the two endpoints are not peers in a control plane relationship, then the intermediate nodes must, be forwarding control plane signals from one pw endpoint to another, which means that the intermediate nodes maintain per-PW control state. When a PW packet is received by a PW endpoint, the PW label must be a label which was assigned by that endpoint. If the two endpoints are not peers in a control plane relationship, the PW labels need to be swapped by the intermediate nodes, which means that the intermediate nodes maintain per-PW labels. Given that these intermediate nodes must maintain per-PW state, I don't see how your proposal is any different than the splicing proposals. The operations performed by the intermediate nodes seem to be the same. I also don't see why RSVP-TE is any better than LDP here. Peter> The only complication is that the PW infrastructure (i.e. the U-PEs Peter> and the intermediate hops, the N-PEs or PW-LSRs) is an overlay Peter> network on top the MPLS network at large. To discover the topology of Peter> that PW infrastructure, you need to run a routing protocol within Peter> that overlay network. In theory you could pass around pw endpoint identifiers in a routing algorithm, with the splice points being the possible next hops. However, you'd need to invent a summarizable addressing scheme for the endpoints, make sure the routing is loop-free, etc. Frankly, I haven't seen the demand for this. From exim@www1.ietf.org Mon Jul 28 17:21:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21267 for ; Mon, 28 Jul 2003 17:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFQW-0005Dd-Pe for l2vpn-archive@odin.ietf.org; Mon, 28 Jul 2003 17:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SLL4UB020057 for l2vpn-archive@odin.ietf.org; Mon, 28 Jul 2003 17:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFQW-0005DQ-MP for l2vpn-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 17:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21256 for ; Mon, 28 Jul 2003 17:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hFQU-0000El-00 for l2vpn-web-archive@ietf.org; Mon, 28 Jul 2003 17:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hFQT-0000Ei-00 for l2vpn-web-archive@ietf.org; Mon, 28 Jul 2003 17:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFQS-0005Cu-MJ; Mon, 28 Jul 2003 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hFPe-0005Cd-6W for l2vpn@optimus.ietf.org; Mon, 28 Jul 2003 17:20:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21253 for ; Mon, 28 Jul 2003 17:20:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hFPb-0000Ef-00 for l2vpn@ietf.org; Mon, 28 Jul 2003 17:20:07 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19hFPb-0000Ec-00 for l2vpn@ietf.org; Mon, 28 Jul 2003 17:20:07 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6SLJmJ13959 for ; Mon, 28 Jul 2003 16:19:48 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Mon, 28 Jul 2003 17:19:33 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'erosen@cisco.com'" Cc: "'l2vpn@ietf.org'" Subject: RE: Truly Generalized VPLS (?) Date: Mon, 28 Jul 2003 17:19:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric> The two PW endpoints have to agree on such things as the use Eric> of the control Eric> word, the use of signaling, etc. They may also need to Eric> send each other Eric> status info. These things are done using the control Eric> plane. If the two Eric> endpoints are not peers in a control plane Eric> relationship, then the Eric> intermediate nodes must, be forwarding control plane Eric> signals from one pw Eric> endpoint to another, which means that the intermediate Eric> nodes maintain Eric> per-PW control state. (For the rest of this email, I assume a three hop PW: SRC-U-PE - SRC-N-PE - DST-N-PE - DST-U-PE) I would think that the most important information is exchanged between SRC-U-PE and DST-U-PE. Things like Requested VLAN id and Maximum number of ATM cells should apply to the end-to-end path. If not, intermediate nodes would have to modify the payload of the PW, which is highly undesirable. In the splicing approach, you have three separate control sessions. To enable information exchange between the two U-PEs, you need to forward parameters from one control session to the other. How exactly do you do that? Draft-rosen-l2-signaling suggests that you set up all PW segments independently and then splice them together. Suppose that SRC-U-PE and SRC-N-PE agree to use a Control Word and DST-N-PE and DST-U-PE agree not to use a Control Word. Is it the idea that one of the N-PEs inserts and deletes Control Words? My proposal is to use RSVP with additional objects for PW capability negotiation that are only interpreted by the two U-PEs. If anything, I would think that that would require less state information in the intermediate nodes (i.e. the N-PEs) than the splicing approach with three separate LDP sessions. In the RSVP approach, the only information maintained in the intermediate nodes is related to PW labels. However, in any Decoupled VPLS approach you need to do the same thing. Whatever mechanism you choose, an intermediate node needs to be able to map incoming label to outgoing label. > Eric> When a PW packet is received by a PW endpoint, the PW label Eric> must be a label Eric> which was assigned by that endpoint. If the two endpoints Eric> are not peers in Eric> a control plane relationship, the PW labels need to be Eric> swapped by the Eric> intermediate nodes, which means that the intermediate nodes Eric> maintain per-PW Eric> labels. Eric> Given that these intermediate nodes must maintain per-PW Eric> state, I don't see Eric> how your proposal is any different than the splicing Eric> proposals. The Eric> operations performed by the intermediate nodes seem to be the same. Eric> Indeed, the operations performed by the intermediate nodes are the same. That is exactly my point. The splicing approach is a non-standard way to do something that can be done with existing protocols. Above, I raised the question of how you do end-to-end capability negotiation if you have three separate control sessions. In my email to Wei Luo I identified issues with TTL, OAM and Protection Switching. I have no doubt that all these things can be solved, but they need to be specified in standards. The fact that a single LDP session between two peers is based on a standard protocol doesn't mean that three sessions spliced together is an obvious extension of that protocol. There are standard protocols for setting up an LSP across multiple intermediate nodes. Why don't we use an existing solution instead of inventing a new one? Eric> I also don't see why RSVP-TE is any better than LDP here. I hope the above makes clear why I think that three independent LDP sessions to set up separate PWs that are then spliced together is not a good approach. The question is: what to use otherwise? If by LDP you mean CR-LDP, then I don't see why RSVP-TE would be better, except for the fact that I thought we were moving away from CR-LDP. If by LDP you mean the topology-based flooding of labels, then I think RSVP-TE would be better. Capability negotiation and path set up is essentially a point-to-point information exchange between two U-PEs. I don't see how you would do that with LDP, but perhaps that is just my lack of understanding of LDP. > Eric> In theory you could pass around pw endpoint identifiers Eric> in a routing Eric> algorithm, with the splice points being the possible next Eric> hops. However, Eric> you'd need to invent a summarizable addressing scheme for Eric> the endpoints, Eric> make sure the routing is loop-free, etc. Frankly, I haven't Eric> seen the demand for this. This is probably just my ignorance. In a previous email I asked how an N-PE discovers the "local list" and "remote list" that you mention in section 5.5.1 of draft-rosen-l2-signaling. From your answer I got the impression that you envisioned that those lists would be manually provisioned by the Service Provider. If so, that strikes me as a big problem. It would mean that for every VPLS a Service Provider has to figure out how to route PWs and then provision the relevant information in all N-PEs that are involved. Why bother with things like auto-discovery and capability negotiation if connection set up is to a large extent manual? But again, I am probably just missing something. From exim@www1.ietf.org Mon Jul 28 19:10:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24192 for ; Mon, 28 Jul 2003 19:10:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hH80-0000YK-L7 for l2vpn-archive@odin.ietf.org; Mon, 28 Jul 2003 19:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SNA4q0002119 for l2vpn-archive@odin.ietf.org; Mon, 28 Jul 2003 19:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hH80-0000Y6-FS for l2vpn-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 19:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24188 for ; Mon, 28 Jul 2003 19:09:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hH7x-0000nC-00 for l2vpn-web-archive@ietf.org; Mon, 28 Jul 2003 19:10:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hH7w-0000n9-00 for l2vpn-web-archive@ietf.org; Mon, 28 Jul 2003 19:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hH7w-0000XI-Tm; Mon, 28 Jul 2003 19:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hH7f-0000Wf-MS for l2vpn@optimus.ietf.org; Mon, 28 Jul 2003 19:09:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24182 for ; Mon, 28 Jul 2003 19:09:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hH7c-0000n1-00 for l2vpn@ietf.org; Mon, 28 Jul 2003 19:09:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hH7b-0000my-00 for l2vpn@ietf.org; Mon, 28 Jul 2003 19:09:39 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hH7Z-0009lU-EC; Mon, 28 Jul 2003 23:09:37 +0000 Date: Mon, 28 Jul 2003 16:05:22 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14408300294.20030728160522@psg.com> To: Eric Rosen CC: Sasha Vainshtein , "Vach Kompella" , Subject: Re: On VPLS and Routing Protocols In-Reply-To: <200307251806.h6PI6gMK022838@rtp-core-1.cisco.com> References: <200307251806.h6PI6gMK022838@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Alex>> Optimizations are fine. However, from the routing perspective, Alex>> if there still are potential cases where any-to-any connectivity Alex>> is not maintained, those considerations apply. > I'm not sure you've fully understood Vach's proposal. He is trying to come > up with a scheme that maintains the any-to-any connectivity even if a PW > fails. Such a scheme, if successful, would certainly eliminate the routing > problem that you've described. I understood that, it just wasn't obvious to me that the proposed mechanism would cover all failure modes, such as failure of more than one PW. [rtg part clipped] > Having said all that, this probably isn't really a workable solution, > because it may not always be apparent to a router that a particular LAN > interface leads to a VPLS rather than a native LAN. Routers would need to be manually configured to treat the interface as point-to-mutlipoint broadcast. We normally don't have to do so for LAN interfaces, but it's a one-liner. [clipped] > A better approach would be to see if there is a way to detect that the full > mesh has failed (say, by having each PE tell all the others "here are the > other PEs I can talk to in the specified VPLS instance"), and to determine > what action to take when the full mesh does fail. Agreed, though we should keep the complexity as low as possible, I believe. From a higher perspective, it seems we have the following potential approaches to PW failures: 1. Fix connectivity within the PW mesh so that the VPN routing layer does not notice. 2. Don't fix connectivity and let the VPN routing layer track all details and reroute appropriately (the p2mp option I described) 3. When node A looses the PW to node Z, make sure nodes B..Y simulate loss of connectivity to A and Z too, so all CEs have a consistent view and VPN routing converges properly. I.e. PW failure triggers simulation of 2 node failures. 4. Don't fix connectivity, don't change VPN routing, just throw an alarm and wait till the admin fixes the problem. I'd need to think more if we can do 1) with multiple PW failures without ending up having to do routing within the PW mesh. Option 2 seems ok, but only applicable to some routing protocols (we can't guarantee that OSPF, or IP at all for that matter, will be running across the VPLS), so it would be ok as a recommendation if we decide to go with 4). It would be interesting to see what people think of option 3. Option 4 is the back-up we always have :) Alex From exim@www1.ietf.org Tue Jul 29 13:10:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01182 for ; Tue, 29 Jul 2003 13:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXzE-0003Re-D7 for l2vpn-archive@odin.ietf.org; Tue, 29 Jul 2003 13:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6THA85M013236 for l2vpn-archive@odin.ietf.org; Tue, 29 Jul 2003 13:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXzE-0003RP-9W for l2vpn-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 13:10:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01163 for ; Tue, 29 Jul 2003 13:10:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hXzC-00004x-00 for l2vpn-web-archive@ietf.org; Tue, 29 Jul 2003 13:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hXzB-00004t-00 for l2vpn-web-archive@ietf.org; Tue, 29 Jul 2003 13:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXz7-0003Qw-R8; Tue, 29 Jul 2003 13:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXyQ-0003QP-79 for l2vpn@optimus.ietf.org; Tue, 29 Jul 2003 13:09:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01145 for ; Tue, 29 Jul 2003 13:09:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hXyO-00004S-00 for l2vpn@ietf.org; Tue, 29 Jul 2003 13:09:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hXyN-00003s-00 for l2vpn@ietf.org; Tue, 29 Jul 2003 13:09:15 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 10:11:26 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TH8hAi029759; Tue, 29 Jul 2003 13:08:43 -0400 (EDT) Message-Id: <200307291708.h6TH8hAi029759@rtp-core-2.cisco.com> To: l2vpn@ietf.org Subject: l2vpn framework issue Reply-to: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Jul 2003 13:08:43 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Awhile back we had a discussion of the VPLS model in this doc, but that discussion is not reflected in draft-ietf-l2vpn-l2-framework-00.txt which is now being last called. My proposal is to add the following text at the end of section 2.2 (just before section 2.2.1). I think this text does the proper job for a framework document, i.e., places the controversial issue in context while leaving the resolution of the controversy to the solutions work. ------------------------------------------------------------------------------- This framework specifies that each "bridge module" has a single "Emulated LAN interface". It does not specify the number of bridge modules that a VPLS-PE may contain, nor does it specify the number of VPLS instances which may attach to a bridge module over a single "Emulated LAN interface". Thus the framework is compatible with at least the following three models: - Model 1 A VPLS-PE contains a single bridge module, and supports a single VPLS instance. The VPLS instance is an Emulated LAN; if that Emulated LAN contains VLANs, 802.1Q tagging must be used to indicate which packets are in which VLANs. - Model 2 A VPLS-PE contains a single bridge module, but supports multiple VPLS instances. Each VPLS instance is thought of as a VLAN (in effect, an "Emulated VLAN"), and the set of VPLS instances are treated as a set of VLANs on a common LAN. - Model 3 A VPLS-PE contains an arbitrary number of bridge modules, each of which attaches to a single VPLS instance. There may be other models as well, some of which are combinations of the 3 models above. Different models may have different characteristics, and different scopes of applicability. Each VPLS solution should specify the model or models that it is supporting. This framework does not specify the way in which bridge control protocols are used on the Emulated LANs. From exim@www1.ietf.org Wed Jul 30 13:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08643 for ; Wed, 30 Jul 2003 13:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huVc-0001tF-7k for l2vpn-archive@odin.ietf.org; Wed, 30 Jul 2003 13:13:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHD4t2007259 for l2vpn-archive@odin.ietf.org; Wed, 30 Jul 2003 13:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huVc-0001t0-3M for l2vpn-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 13:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08633 for ; Wed, 30 Jul 2003 13:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huVa-0001sX-00 for l2vpn-web-archive@ietf.org; Wed, 30 Jul 2003 13:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19huVZ-0001sT-00 for l2vpn-web-archive@ietf.org; Wed, 30 Jul 2003 13:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huVZ-0001sU-AC; Wed, 30 Jul 2003 13:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huVA-0001re-UE for l2vpn@optimus.ietf.org; Wed, 30 Jul 2003 13:12:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08620 for ; Wed, 30 Jul 2003 13:12:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huV9-0001s9-00 for l2vpn@ietf.org; Wed, 30 Jul 2003 13:12:35 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19huV8-0001s6-00 for l2vpn@ietf.org; Wed, 30 Jul 2003 13:12:34 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19huV8-0006fi-A6 for l2vpn@ietf.org; Wed, 30 Jul 2003 17:12:34 +0000 Date: Wed, 30 Jul 2003 10:11:50 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <152559887826.20030730101150@psg.com> To: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-Reply-To: <14408300294.20030728160522@psg.com> References: <200307251806.h6PI6gMK022838@rtp-core-1.cisco.com> <14408300294.20030728160522@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote: [...] > 3. When node A looses the PW to node Z, make sure nodes B..Y > simulate loss of connectivity to A and Z too, so all CEs > have a consistent view and VPN routing converges properly. > I.e. PW failure triggers simulation of 2 node failures. IF we decide to go this route, the simplest way to do this is for A and Z to logically put all other PWs they have logically down (stop sending outgoing and drop incoming traffic on them) when they see a PW failure. This way, the two-way connectivity of all other CEs with those attached to A and Z will be broken and VPN routing will reconverge properly. No extra message exchange, no additional signaling--everything is a node-local decision. Alex From exim@www1.ietf.org Wed Jul 30 13:53:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10664 for ; Wed, 30 Jul 2003 13:53:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv8n-0004cV-30 for l2vpn-archive@odin.ietf.org; Wed, 30 Jul 2003 13:53:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHrX3H017756 for l2vpn-archive@odin.ietf.org; Wed, 30 Jul 2003 13:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv8m-0004cJ-Vw for l2vpn-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 13:53:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10634 for ; Wed, 30 Jul 2003 13:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv8G-0004WP-UC; Wed, 30 Jul 2003 13:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv83-0004W5-K1 for l2vpn@optimus.ietf.org; Wed, 30 Jul 2003 13:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10593 for ; Wed, 30 Jul 2003 13:52:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hv80-0002I8-00 for l2vpn@ietf.org; Wed, 30 Jul 2003 13:52:44 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19hv80-0002Hu-00 for l2vpn@ietf.org; Wed, 30 Jul 2003 13:52:44 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 13:52:36 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB0010615@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'Alex Zinin'" , l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Wed, 30 Jul 2003 13:52:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C356C3.5AF939C0" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C356C3.5AF939C0 Content-Type: text/plain; charset="iso-8859-1" thats exactly what I was thinking (I had mentioned this to Vach and cheng-yin at IETF). But, I think that 'blocking' VPLS port (consisting of PW bundle of the affected VPLS instance) of A should be adequate If packet forwarding capability of A is compromised because PW from A to Z is down. /himanshu > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Wednesday, July 30, 2003 1:12 PM > To: l2vpn@ietf.org > Subject: Re: On VPLS and Routing Protocols > > > Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote: > [...] > > 3. When node A looses the PW to node Z, make sure nodes B..Y > > simulate loss of connectivity to A and Z too, so all CEs > > have a consistent view and VPN routing converges properly. > > I.e. PW failure triggers simulation of 2 node failures. > > IF we decide to go this route, the simplest way to do this is for A > and Z to logically put all other PWs they have logically down (stop > sending outgoing and drop incoming traffic on them) when they see a PW > failure. This way, the two-way connectivity of all other CEs with > those attached to A and Z will be broken and VPN routing will > reconverge properly. No extra message exchange, no additional > signaling--everything is a node-local decision. > > Alex > > > ------_=_NextPart_001_01C356C3.5AF939C0 Content-Type: text/html; charset="iso-8859-1" RE: On VPLS and Routing Protocols

thats exactly what I was thinking (I had mentioned this to Vach
and cheng-yin at IETF).

But, I think that  'blocking' VPLS port (consisting of PW bundle
of the affected VPLS instance) of A should be adequate If packet
forwarding capability of A is compromised because PW from A to Z
is down.

/himanshu


> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Wednesday, July 30, 2003 1:12 PM
> To: l2vpn@ietf.org
> Subject: Re: On VPLS and Routing Protocols
>
>
> Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote:
> [...]
> >  3. When node A looses the PW to node Z, make sure nodes B..Y
> >     simulate loss of connectivity to A and Z too, so all CEs
> >     have a consistent view and VPN routing converges properly.
> >     I.e. PW failure triggers simulation of 2 node failures.
>
> IF we decide to go this route, the simplest way to do this is for A
> and Z to logically put all other PWs they have logically down (stop
> sending outgoing and drop incoming traffic on them) when they see a PW
> failure. This way, the two-way connectivity of all other CEs with
> those attached to A and Z will be broken and VPN routing will
> reconverge properly. No extra message exchange, no additional
> signaling--everything is a node-local decision.
>
> Alex
>
>
>

------_=_NextPart_001_01C356C3.5AF939C0-- From exim@www1.ietf.org Wed Jul 30 14:36:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12258 for ; Wed, 30 Jul 2003 14:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvnw-0006Sg-Pe for l2vpn-archive@odin.ietf.org; Wed, 30 Jul 2003 14:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIa4v8024832 for l2vpn-archive@odin.ietf.org; Wed, 30 Jul 2003 14:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvnw-0006SR-L4 for l2vpn-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 14:36:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12249 for ; Wed, 30 Jul 2003 14:35:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvnu-0002dA-00 for l2vpn-web-archive@ietf.org; Wed, 30 Jul 2003 14:36:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hvnt-0002d7-00 for l2vpn-web-archive@ietf.org; Wed, 30 Jul 2003 14:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvnu-0006Qw-7u; Wed, 30 Jul 2003 14:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvn1-0006QM-54 for l2vpn@optimus.ietf.org; Wed, 30 Jul 2003 14:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12176 for ; Wed, 30 Jul 2003 14:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvmy-0002ce-00 for l2vpn@ietf.org; Wed, 30 Jul 2003 14:35:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hvmx-0002c9-00 for l2vpn@ietf.org; Wed, 30 Jul 2003 14:35:03 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UIYVxc022222; Wed, 30 Jul 2003 14:34:31 -0400 (EDT) Message-Id: <200307301834.h6UIYVxc022222@rtp-core-2.cisco.com> To: Alex Zinin cc: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Wed, 30 Jul 2003 10:11:50 -0700. <152559887826.20030730101150@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 30 Jul 2003 14:34:31 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >> 3. When node A looses the PW to node Z, make sure nodes B..Y >> simulate loss of connectivity to A and Z too, so all CEs >> have a consistent view and VPN routing converges properly. >> I.e. PW failure triggers simulation of 2 node failures. Alex> IF we decide to go this route, the simplest way to do this is for A Alex> and Z to logically put all other PWs they have logically down (stop Alex> sending outgoing and drop incoming traffic on them) when they see a PW Alex> failure. This way, the two-way connectivity of all other CEs with Alex> those attached to A and Z will be broken and VPN routing will Alex> reconverge properly. No extra message exchange, no additional Alex> signaling--everything is a node-local decision. But this doesn't handle the case where A and Z, for some reason, either (a) never find out about each other, or (b) never succeed in setting up PWs to each other in the first place. Also, if node Z happens to go down, doesn't this make all the PWs go down? I really don't think this can be done based on local knowledge. From exim@www1.ietf.org Thu Jul 31 11:07:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00887 for ; Thu, 31 Jul 2003 11:07:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF1E-00051U-NR for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 11:07:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VF74Ha019299 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 11:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF1E-00051C-GE for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00876 for ; Thu, 31 Jul 2003 11:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF1B-0004uq-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 11:07:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iF1B-0004un-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 11:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF1B-0004zN-Pg; Thu, 31 Jul 2003 11:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF0y-0004yq-EF for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 11:06:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00869 for ; Thu, 31 Jul 2003 11:06:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF0v-0004ug-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 11:06:45 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19iF0v-0004ub-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 11:06:45 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 11:06:39 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001061B@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'erosen@cisco.com'" , Alex Zinin Cc: l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Thu, 31 Jul 2003 11:06:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35775.562BB140" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C35775.562BB140 Content-Type: text/plain I don't know if we need to cover those cases. There is a problem only when CEs behind a PE can talk to one sets of CEs and not to others for a given VPLS instance. And so with that logic, if a PE is having a PW problem for a given VPLS instance, it should 'block' the whole VPLS instance (i.e. PW bundle as well as local ports that are member of that VPLS instance). /himanshu > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, July 30, 2003 2:35 PM > To: Alex Zinin > Cc: l2vpn@ietf.org > Subject: Re: On VPLS and Routing Protocols > > > > >> 3. When node A looses the PW to node Z, make sure nodes B..Y > >> simulate loss of connectivity to A and Z too, so all CEs > >> have a consistent view and VPN routing converges properly. > >> I.e. PW failure triggers simulation of 2 node failures. > > Alex> IF we decide to go this route, the simplest way to do > this is for A > Alex> and Z to logically put all other PWs they have > logically down (stop > Alex> sending outgoing and drop incoming traffic on them) > when they see a PW > Alex> failure. This way, the two-way connectivity of all > other CEs with > Alex> those attached to A and Z will be broken and VPN routing will > Alex> reconverge properly. No extra message exchange, no additional > Alex> signaling--everything is a node-local decision. > > But this doesn't handle the case where A and Z, for some > reason, either (a) > never find out about each other, or (b) never succeed in > setting up PWs to > each other in the first place. Also, if node Z happens to > go down, doesn't > this make all the PWs go down? > > I really don't think this can be done based on local knowledge. > > ------_=_NextPart_001_01C35775.562BB140 Content-Type: text/html RE: On VPLS and Routing Protocols

I don't know if we need to cover those cases.
There is a problem only when CEs behind a PE
can talk to one sets of CEs and not to others
for a given VPLS instance. 

And so with that logic, if a PE is having a PW problem
for a given VPLS instance, it should 'block' the whole
VPLS instance (i.e. PW bundle as well as local ports
that are member of that VPLS instance).

/himanshu



> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Wednesday, July 30, 2003 2:35 PM
> To: Alex Zinin
> Cc: l2vpn@ietf.org
> Subject: Re: On VPLS and Routing Protocols
>
>
>
> >> 3. When node A looses the PW to node Z, make sure nodes B..Y
> >> simulate loss of connectivity to A and Z too, so all CEs
> >> have a consistent view and VPN routing converges properly.
> >> I.e. PW failure triggers simulation of 2 node failures.
>
> Alex> IF we decide to go this route, the simplest way to do
> this is for A
> Alex> and Z to logically put all other PWs they have
> logically down (stop
> Alex> sending outgoing and drop incoming traffic on them)
> when they see a PW
> Alex> failure. This way, the two-way connectivity of all
> other CEs with
> Alex> those attached to A and Z will be broken and VPN routing will
> Alex> reconverge properly. No extra message exchange, no additional
> Alex> signaling--everything is a node-local decision.
>
> But this doesn't handle the case where  A and Z, for some
> reason, either (a)
> never find out about  each other, or (b) never succeed in 
> setting up PWs to
> each other in the first place.  Also,  if node Z happens to
> go down, doesn't
> this make all the PWs go down? 
>
> I really don't think this can be done based on local knowledge.
>
>

------_=_NextPart_001_01C35775.562BB140-- From exim@www1.ietf.org Thu Jul 31 11:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01396 for ; Thu, 31 Jul 2003 11:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFDm-00066c-Kv for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 11:20:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFK28Q023464 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 11:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFDm-00066N-FU for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:20:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01392 for ; Thu, 31 Jul 2003 11:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFDl-00052L-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 11:20:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFDl-00052I-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 11:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFDk-00065j-V8; Thu, 31 Jul 2003 11:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFD1-00061W-4h for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 11:19:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01310 for ; Thu, 31 Jul 2003 11:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFD0-00051C-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 11:19:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19iFCz-000512-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 11:19:13 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6VFIOu00110; Thu, 31 Jul 2003 08:18:24 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h6VFIOa76217; Thu, 31 Jul 2003 08:18:24 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 31 Jul 2003 08:18:24 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin cc: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-Reply-To: <152559887826.20030730101150@psg.com> Message-ID: <20030731072840.S75792@kummer.juniper.net> References: <200307251806.h6PI6gMK022838@rtp-core-1.cisco.com> <14408300294.20030728160522@psg.com> <152559887826.20030730101150@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, 30 Jul 2003, Alex Zinin wrote: > Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote: > [...] > > 3. When node A looses the PW to node Z, make sure nodes B..Y > > simulate loss of connectivity to A and Z too, so all CEs > > have a consistent view and VPN routing converges properly. > > I.e. PW failure triggers simulation of 2 node failures. > > IF we decide to go this route, the simplest way to do this is for A > and Z to logically put all other PWs they have logically down (stop > sending outgoing and drop incoming traffic on them) when they see a PW > failure. This way, the two-way connectivity of all other CEs with > those attached to A and Z will be broken and VPN routing will > reconverge properly. No extra message exchange, no additional > signaling--everything is a node-local decision. This might be simpler, but it is a hack. It is cleaner for A and/or Z to withdraw their labels so that B..Y all know that their connections to A and/or Z are down. The "extra message exchange" ensures a) all nodes are in sync about what's going on; b) B..Y can, on learning of the loss of connectivity, signal this change to their CEs, (in the fullness of time, when Ethernet OAM/UNI is defined); c) traffic doesn't transit the PSN only to get dropped at A or Z. Just as a reminder, this was what Norm Finn suggested (Norm, correct me if I misrepresented you.) Kireeti. From exim@www1.ietf.org Thu Jul 31 11:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02070 for ; Thu, 31 Jul 2003 11:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFY7-0007Ws-Or for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 11:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFf3Uv028937 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 11:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFY7-0007We-L4 for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02024 for ; Thu, 31 Jul 2003 11:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFY6-0005CD-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 11:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iFY6-0005C8-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 11:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFY5-0007V8-LR; Thu, 31 Jul 2003 11:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFXR-0007Rm-8d for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 11:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02002 for ; Thu, 31 Jul 2003 11:40:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFXP-0005Bc-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 11:40:19 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19iFXO-0005BZ-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 11:40:18 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 11:40:18 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001061C@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'Kireeti Kompella'" , Alex Zinin Cc: l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Thu, 31 Jul 2003 11:40:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3577A.0899CE30" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C3577A.0899CE30 Content-Type: text/plain Well that may be desirable but wouldn't it be more than what today's interconnected LANs offer? For instance, if a Ethernet switch port goes down, the switch doesn't notify all other switches that its port has gone down. Something to think about.... /himanshu > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, July 31, 2003 11:18 AM > To: Alex Zinin > Cc: l2vpn@ietf.org > Subject: Re: On VPLS and Routing Protocols > > > On Wed, 30 Jul 2003, Alex Zinin wrote: > > > Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote: > > [...] > > > 3. When node A looses the PW to node Z, make sure nodes B..Y > > > simulate loss of connectivity to A and Z too, so all CEs > > > have a consistent view and VPN routing converges properly. > > > I.e. PW failure triggers simulation of 2 node failures. > > > > IF we decide to go this route, the simplest way to do this is for A > > and Z to logically put all other PWs they have logically down (stop > > sending outgoing and drop incoming traffic on them) when > they see a PW > > failure. This way, the two-way connectivity of all other CEs with > > those attached to A and Z will be broken and VPN routing will > > reconverge properly. No extra message exchange, no additional > > signaling--everything is a node-local decision. > > This might be simpler, but it is a hack. It is cleaner for A and/or Z > to withdraw their labels so that B..Y all know that their connections > to A and/or Z are down. The "extra message exchange" ensures > a) all nodes are in sync about what's going on; > b) B..Y can, on learning of the loss of connectivity, signal > this change > to their CEs, (in the fullness of time, when Ethernet OAM/UNI is > defined); > c) traffic doesn't transit the PSN only to get dropped at A or Z. > > Just as a reminder, this was what Norm Finn suggested (Norm, correct > me if I misrepresented you.) > > Kireeti. > > ------_=_NextPart_001_01C3577A.0899CE30 Content-Type: text/html RE: On VPLS and Routing Protocols

Well that may be desirable but wouldn't it be more
than what today's interconnected LANs offer?
For instance, if a Ethernet switch port goes down,
the switch doesn't notify all other switches that
its port has gone down.

Something to think about....

/himanshu

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Thursday, July 31, 2003 11:18 AM
> To: Alex Zinin
> Cc: l2vpn@ietf.org
> Subject: Re: On VPLS and Routing Protocols
>
>
> On Wed, 30 Jul 2003, Alex Zinin wrote:
>
> > Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote:
> > [...]
> > >  3. When node A looses the PW to node Z, make sure nodes B..Y
> > >     simulate loss of connectivity to A and Z too, so all CEs
> > >     have a consistent view and VPN routing converges properly.
> > >     I.e. PW failure triggers simulation of 2 node failures.
> >
> > IF we decide to go this route, the simplest way to do this is for A
> > and Z to logically put all other PWs they have logically down (stop
> > sending outgoing and drop incoming traffic on them) when
> they see a PW
> > failure. This way, the two-way connectivity of all other CEs with
> > those attached to A and Z will be broken and VPN routing will
> > reconverge properly. No extra message exchange, no additional
> > signaling--everything is a node-local decision.
>
> This might be simpler, but it is a hack.  It is cleaner for A and/or Z
> to withdraw their labels so that B..Y all know that their connections
> to A and/or Z are down.  The "extra message exchange" ensures
> a) all nodes are in sync about what's going on;
> b) B..Y can, on learning of the loss of connectivity, signal
> this change
>    to their CEs, (in the fullness of time, when Ethernet OAM/UNI is
>    defined);
> c) traffic doesn't transit the PSN only to get dropped at A or Z.
>
> Just as a reminder, this was what Norm Finn suggested (Norm, correct
> me if I misrepresented you.)
>
> Kireeti.
>
>

------_=_NextPart_001_01C3577A.0899CE30-- From exim@www1.ietf.org Thu Jul 31 12:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04112 for ; Thu, 31 Jul 2003 12:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGgm-0002bK-73 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 12:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGs4aM009992 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 12:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGgm-0002b5-2O for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 12:54:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04086 for ; Thu, 31 Jul 2003 12:53:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGgk-0005gG-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 12:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iGgj-0005gD-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 12:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGgj-0002aS-FZ; Thu, 31 Jul 2003 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGgV-0002a3-Vp for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 12:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04074 for ; Thu, 31 Jul 2003 12:53:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGgU-0005fy-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 12:53:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iGgT-0005fb-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 12:53:45 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 09:56:24 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VGrCXw003405; Thu, 31 Jul 2003 12:53:13 -0400 (EDT) Message-Id: <200307311653.h6VGrCXw003405@rtp-core-1.cisco.com> To: "Shah, Himanshu" cc: Alex Zinin , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Thu, 31 Jul 2003 11:06:36 -0400. <8162DD929D7AD24CAD3FC5317CE41FB001061B@w2kmaexg02.ciena.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 31 Jul 2003 12:53:12 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric> But this doesn't handle the case where A and Z, for some reason, Eric> either (a) never find out about each other, or (b) never succeed in Eric> setting up PWs to each other in the first place. Himanshu> I don't know if we need to cover those cases. There is a problem Himanshu> only when CEs behind a PE can talk to one sets of CEs and not to Himanshu> others for a given VPLS instance. It seems to me that that will happen in these cases. Eric> Also, if node Z happens to go down, doesn't this make all the PWs go Eric> down? I'll keep saying this until someone explains to me why it isn't a fatal flaw. From exim@www1.ietf.org Thu Jul 31 13:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04294 for ; Thu, 31 Jul 2003 13:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGmZ-0002r8-C3 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 13:00:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VH03dA010972 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 13:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGmZ-0002qt-5m for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 13:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04262 for ; Thu, 31 Jul 2003 12:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGmX-0005hp-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 13:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iGmW-0005hm-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 13:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGmX-0002qK-Ie; Thu, 31 Jul 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGlc-0002or-09 for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 12:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04251 for ; Thu, 31 Jul 2003 12:58:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGla-0005hY-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 12:59:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iGlZ-0005hV-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 12:59:01 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 09:58:31 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VGwTxc024285; Thu, 31 Jul 2003 12:58:29 -0400 (EDT) Message-Id: <200307311658.h6VGwTxc024285@rtp-core-2.cisco.com> To: Kireeti Kompella cc: Alex Zinin , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Thu, 31 Jul 2003 08:18:24 -0700. <20030731072840.S75792@kummer.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 31 Jul 2003 12:58:29 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > This might be simpler, but it is a hack. Kireeti, I'm surprised at you, calling something a "hack" ;-) > this was what Norm Finn suggested Norm suggested that a PE not bring up any of its PWs unless it had an operational PW to each other PE that it learns about via the discovery process. This also has the problem that if you don't have a PW to Z, you can't tell locally whether anyone else has a PW to Z. (If no one has a PW to Z, then of course everything is okay as is.) From exim@www1.ietf.org Thu Jul 31 13:45:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05740 for ; Thu, 31 Jul 2003 13:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHU9-00059D-Hk for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 13:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VHj5kO019786 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 13:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHU9-000593-Bw for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 13:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05719 for ; Thu, 31 Jul 2003 13:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHU7-00063i-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 13:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iHU6-00063e-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 13:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHU5-00058L-5g; Thu, 31 Jul 2003 13:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHTY-00054Q-9H for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 13:44:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05686 for ; Thu, 31 Jul 2003 13:44:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHTU-00063C-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 13:44:24 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19iHTU-000639-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 13:44:24 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 13:44:19 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001061F@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'erosen@cisco.com'" Cc: Alex Zinin , l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Thu, 31 Jul 2003 13:44:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3578B.5C7B21F0" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C3578B.5C7B21F0 Content-Type: text/plain; charset="iso-8859-1" you are right that these cases have similar effect. but I don't know if we should entertain a separate mechanism to handle that case. For instance, in case a) if there is misconfiguration or problem in auto-discovery where one or more PE has different VPLS member record set, we have a problem. And only the mechanism you described about synchronizing membership info would work (but perhaps not something easy to accomplish). in case of b) unsuccessful establishment of PW can be treated same as PW present and gone bad. /himanshu > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, July 31, 2003 12:53 PM > To: Shah, Himanshu > Cc: Alex Zinin; l2vpn@ietf.org > Subject: Re: On VPLS and Routing Protocols > > > Eric> But this doesn't handle the case where A and Z, > for some reason, > Eric> either (a) never find out about each other, or (b) > never succeed in > Eric> setting up PWs to each other in the first place. > > Himanshu> I don't know if we need to cover those cases. > There is a problem > Himanshu> only when CEs behind a PE can talk to one sets of > CEs and not to > Himanshu> others for a given VPLS instance. > > It seems to me that that will happen in these cases. > > Eric> Also, if node Z happens to go down, doesn't this make > all the PWs go > Eric> down? > > I'll keep saying this until someone explains to me why it > isn't a fatal > flaw. > > > > ------_=_NextPart_001_01C3578B.5C7B21F0 Content-Type: text/html; charset="iso-8859-1" RE: On VPLS and Routing Protocols

you are right that these cases have similar effect.
but I don't know if we should entertain a separate mechanism
to handle that case.

For instance,
in case a) if there is misconfiguration or problem in
auto-discovery where one or more PE has different
VPLS member record set, we have a problem. And only
the mechanism you described about synchronizing
membership info would work (but perhaps not something
easy to accomplish).

in case of b) unsuccessful establishment of PW can be
treated same as PW present and gone bad.

/himanshu

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Thursday, July 31, 2003 12:53 PM
> To: Shah, Himanshu
> Cc: Alex Zinin; l2vpn@ietf.org
> Subject: Re: On VPLS and Routing Protocols
>
>
> Eric> But  this doesn't  handle the  case where  A and  Z,
> for  some reason,
> Eric> either (a)  never find out about  each other, or (b) 
> never succeed in
> Eric> setting up PWs to each other in the first place.
>
> Himanshu> I don't know if we need  to cover those cases. 
> There is a problem
> Himanshu> only when CEs behind  a PE can talk to one sets  of
> CEs and not to
> Himanshu> others for a given VPLS instance.
>
> It seems to me that that will happen in these cases.
>
> Eric> Also, if node Z  happens to go down, doesn't this make 
> all the PWs go
> Eric> down?
>
> I'll keep  saying this  until someone explains  to me  why it
> isn't  a fatal
> flaw.
>
>
>
>

------_=_NextPart_001_01C3578B.5C7B21F0-- From exim@www1.ietf.org Thu Jul 31 14:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07988 for ; Thu, 31 Jul 2003 14:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIT6-0008Am-It for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 14:48:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIm4SO031411 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 14:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIT6-0008A5-7b for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 14:48:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07955 for ; Thu, 31 Jul 2003 14:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIT3-0006Wp-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 14:48:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iIT2-0006Wl-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 14:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIT2-000887-SQ; Thu, 31 Jul 2003 14:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIS7-000878-BL for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 14:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07905 for ; Thu, 31 Jul 2003 14:46:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIS4-0006WD-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 14:47:00 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19iIS3-0006WA-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 14:46:59 -0400 Received: (qmail 8560 invoked from network); 31 Jul 2003 18:57:42 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 31 Jul 2003 18:57:42 -0000 Received: from alcatel.com ([138.120.62.4]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HIWK6600.4GT; Thu, 31 Jul 2003 14:46:54 -0400 Message-ID: <3F296418.894DDCD1@alcatel.com> Date: Thu, 31 Jul 2003 14:46:48 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: l2vpn@ietf.org, Mick Seaman Subject: Re: On VPLS and Routing Protocols References: <200307251806.h6PI6gMK022838@rtp-core-1.cisco.com> <14408300294.20030728160522@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex et al, Just catching with my email now. Thanks for discussing these issues. I think in choosing any of these options, it may be preferable if the approach chosen works on any device on the emulated LAN e.g. for CE routers, bridges or hosts. Mick Seaman proposed a solution on IEEE 802.1 (or PPVPN?) mailing list prior to this. My understanding of the proposal is - the VPLS entity shall disable the MAC port presented to the 802.1ad bridge if a PW fails. I think Himanshu has described a similar approach ("blocking" VPLS port) in this thread. Also, I think the issue of synching the bringing up of PWs initially and after PW(s) failure need to be considered as well. In the proposal above and in the discussion on (3), PEs may need to agree on which are the currently participating PEs and ensure all other participating PEs have connectivity to each other, i.e. a protocol among PEs may be needed in this approach. Thanks Cheng-Yin Alex Zinin wrote: > > > A better approach would be to see if there is a way to detect that the full > > mesh has failed (say, by having each PE tell all the others "here are the > > other PEs I can talk to in the specified VPLS instance"), and to determine > > what action to take when the full mesh does fail. > > Agreed, though we should keep the complexity as low as possible, I > believe. From a higher perspective, it seems we have the following > potential approaches to PW failures: > > 1. Fix connectivity within the PW mesh so that the VPN > routing layer does not notice. > > 2. Don't fix connectivity and let the VPN routing layer track > all details and reroute appropriately (the p2mp option > I described) > > 3. When node A looses the PW to node Z, make sure nodes B..Y > simulate loss of connectivity to A and Z too, so all CEs > have a consistent view and VPN routing converges properly. > I.e. PW failure triggers simulation of 2 node failures. > > 4. Don't fix connectivity, don't change VPN routing, > just throw an alarm and wait till the admin fixes the problem. > > I'd need to think more if we can do 1) with multiple PW failures > without ending up having to do routing within the PW mesh. Option > 2 seems ok, but only applicable to some routing protocols (we can't > guarantee that OSPF, or IP at all for that matter, will be running > across the VPLS), so it would be ok as a recommendation if we > decide to go with 4). It would be interesting to see what people > think of option 3. Option 4 is the back-up we always have :) > > Alex From exim@www1.ietf.org Thu Jul 31 14:48:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07987 for ; Thu, 31 Jul 2003 14:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIT6-0008Ae-H7 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 14:48:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIm4kN031397 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 14:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIT6-0008AK-Aa for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 14:48:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07957 for ; Thu, 31 Jul 2003 14:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIT3-0006Ws-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 14:48:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iIT2-0006Wm-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 14:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIT3-00088I-5U; Thu, 31 Jul 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIS8-00087E-RB for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 14:47:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07908 for ; Thu, 31 Jul 2003 14:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIS6-0006WJ-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 14:47:02 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19iIS5-0006WG-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 14:47:01 -0400 Received: (qmail 8642 invoked from network); 31 Jul 2003 18:57:49 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 31 Jul 2003 18:57:49 -0000 Received: from alcatel.com ([138.120.62.4]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HIWK6D00.GHY; Thu, 31 Jul 2003 14:47:01 -0400 Message-ID: <3F29641E.ADEB3CB5@alcatel.com> Date: Thu, 31 Jul 2003 14:46:54 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shah Himanshu" CC: "'Alex Zinin'" , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols References: <8162DD929D7AD24CAD3FC5317CE41FB0010615@w2kmaexg02.ciena.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Himanshu, In all the proposals below, I still think A & Z need to tell (may need to be explicit to prevent ambiguity) other PEs that it is not participating in the VPLS anymore. I am not aware of any solutions that does not require some kind of protocol among PEs. Regards Cheng-Yin > "Shah, Himanshu" wrote: > > thats exactly what I was thinking (I had mentioned this to Vach > and cheng-yin at IETF). > > But, I think that 'blocking' VPLS port (consisting of PW bundle > of the affected VPLS instance) of A should be adequate If packet > forwarding capability of A is compromised because PW from A to Z > is down. > > /himanshu > > > -----Original Message----- > > From: Alex Zinin [mailto:zinin@psg.com] > > Sent: Wednesday, July 30, 2003 1:12 PM > > To: l2vpn@ietf.org > > Subject: Re: On VPLS and Routing Protocols > > > > > > Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote: > > [...] > > > 3. When node A looses the PW to node Z, make sure nodes B..Y > > > simulate loss of connectivity to A and Z too, so all CEs > > > have a consistent view and VPN routing converges properly. > > > I.e. PW failure triggers simulation of 2 node failures. > > > > IF we decide to go this route, the simplest way to do this is for A > > and Z to logically put all other PWs they have logically down (stop > > sending outgoing and drop incoming traffic on them) when they see a > PW > > failure. This way, the two-way connectivity of all other CEs with > > those attached to A and Z will be broken and VPN routing will > > reconverge properly. No extra message exchange, no additional > > signaling--everything is a node-local decision. > > > > Alex > > > > > > From exim@www1.ietf.org Thu Jul 31 14:58:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08310 for ; Thu, 31 Jul 2003 14:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIcl-0008RP-0A for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 14:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIw2Bk032441 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 14:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIck-0008RA-RJ for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 14:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08302 for ; Thu, 31 Jul 2003 14:57:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIci-0006bu-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 14:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iIch-0006br-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 14:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIcj-0008Qj-4C; Thu, 31 Jul 2003 14:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIc0-0008QB-Nc for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 14:57:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08293 for ; Thu, 31 Jul 2003 14:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIbx-0006bn-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 14:57:13 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19iIbw-0006bk-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 14:57:13 -0400 Received: (qmail 13108 invoked from network); 31 Jul 2003 19:08:00 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 31 Jul 2003 19:08:00 -0000 Received: from alcatel.com ([138.120.62.4]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HIWKNC00.7KS; Thu, 31 Jul 2003 14:57:12 -0400 Message-ID: <3F296681.1569C271@alcatel.com> Date: Thu, 31 Jul 2003 14:57:05 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Alex Zinin , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols References: <200307301834.h6UIYVxc022222@rtp-core-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Eric Rosen wrote: > > >> 3. When node A looses the PW to node Z, make sure nodes B..Y > >> simulate loss of connectivity to A and Z too, so all CEs > >> have a consistent view and VPN routing converges properly. > >> I.e. PW failure triggers simulation of 2 node failures. > > Alex> IF we decide to go this route, the simplest way to do this is for A > Alex> and Z to logically put all other PWs they have logically down (stop > Alex> sending outgoing and drop incoming traffic on them) when they see a PW > Alex> failure. This way, the two-way connectivity of all other CEs with > Alex> those attached to A and Z will be broken and VPN routing will > Alex> reconverge properly. No extra message exchange, no additional > Alex> signaling--everything is a node-local decision. > > But this doesn't handle the case where A and Z, for some reason, either (a) > never find out about each other, or (b) never succeed in setting up PWs to > each other in the first place. Also, if node Z happens to go down, doesn't > this make all the PWs go down? > I believe so, unless other PEs can figure out node Z is down and no longer participating in the VPLS. Regards Cheng-Yin From exim@www1.ietf.org Thu Jul 31 15:16:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09891 for ; Thu, 31 Jul 2003 15:16:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIuC-0000tY-EG for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 15:16:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJG418003436 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 15:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIuC-0000tL-Ar for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 15:16:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09842 for ; Thu, 31 Jul 2003 15:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIuB-0006hb-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 15:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iIuA-0006hY-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 15:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIuA-0000sI-4m; Thu, 31 Jul 2003 15:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iItW-0000rx-Tm for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 15:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09762 for ; Thu, 31 Jul 2003 15:15:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iItV-0006hN-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 15:15:21 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iItV-0006hG-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 15:15:21 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 12:18:02 -0700 Received: from sajassi-w2k1.cisco.com (dhcp-171-68-147-60.cisco.com [171.68.147.60]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VJEnLI007952; Thu, 31 Jul 2003 12:14:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030731114052.0256cf60@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jul 2003 12:14:48 -0700 To: erosen@cisco.com, l2vpn@ietf.org From: Ali Sajassi Subject: Re: l2vpn framework issue In-Reply-To: <200307291708.h6TH8hAi029759@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Eric, By defining the three models for VPLS-PE, it makes it more clear than what it was before. However, it seems you use the term VPLS instance to refer to a group of PWs as their associated forwarders, right ? Previously, the term VPLS instance was used to refer to a service instance (uni-to-uni) including the portion over IP/MPLS. The figure 2 in framework includes a CE connected to a VPLS-PE over an access network (e.g., QinQ) and the CE is marked to be included in that service instance. And that is consistent with my understanding. In other words, I consider a VPLS instance as a service instance that is between uni to uni and spans across access networks as wells as core MPLS/IP network. We can call, the group of PWs and their associated forwarder an emulated LAN that can correspond to one or more VPLS instances. If it corresponds to a single VPLS instance, then we also refer to it as emulated VLAN because it looks like a VLAN to a bridge module. Besides indicating which of these models a given solution uses, it should also indicated if the bridged module that it uses, is the standard IEEE 802.1 bridged module or not. -Ali At 01:08 PM 7/29/2003 -0400, Eric Rosen wrote: >Awhile back we had a discussion of the VPLS model in this doc, but that >discussion is not reflected in draft-ietf-l2vpn-l2-framework-00.txt which is >now being last called. > >My proposal is to add the following text at the end of section 2.2 (just >before section 2.2.1). I think this text does the proper job for a >framework document, i.e., places the controversial issue in context while >leaving the resolution of the controversy to the solutions work. >------------------------------------------------------------------------------- > > This framework specifies that each "bridge module" has a single > "Emulated LAN interface". It does not specify the number of bridge > modules that a VPLS-PE may contain, nor does it specify the number of > VPLS instances which may attach to a bridge module over a single > "Emulated LAN interface". > > Thus the framework is compatible with at least the following three > models: > > - Model 1 > > A VPLS-PE contains a single bridge module, and supports a single > VPLS instance. The VPLS instance is an Emulated LAN; if that > Emulated LAN contains VLANs, 802.1Q tagging must be used to > indicate which packets are in which VLANs. > > - Model 2 > > A VPLS-PE contains a single bridge module, but supports multiple > VPLS instances. Each VPLS instance is thought of as a VLAN (in > effect, an "Emulated VLAN"), and the set of VPLS instances are > treated as a set of VLANs on a common LAN. > > - Model 3 > > A VPLS-PE contains an arbitrary number of bridge modules, each of > which attaches to a single VPLS instance. > > There may be other models as well, some of which are combinations of > the 3 models above. Different models may have different > characteristics, and different scopes of applicability. > > Each VPLS solution should specify the model or models that it is > supporting. > > This framework does not specify the way in which bridge control > protocols are used on the Emulated LANs. From exim@www1.ietf.org Thu Jul 31 15:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11113 for ; Thu, 31 Jul 2003 15:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJMF-00029d-JE for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 15:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJj3k6008280 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 15:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJMF-00029T-FZ for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 15:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11105 for ; Thu, 31 Jul 2003 15:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJME-0006v3-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 15:45:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iJMD-0006v0-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 15:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJMD-00028s-IZ; Thu, 31 Jul 2003 15:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJLF-00027r-A0 for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 15:44:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11005 for ; Thu, 31 Jul 2003 15:43:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJLD-0006uA-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 15:44:00 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iJLD-0006tu-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 15:43:59 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VJhQxc012117; Thu, 31 Jul 2003 15:43:26 -0400 (EDT) Message-Id: <200307311943.h6VJhQxc012117@rtp-core-2.cisco.com> To: "Busschbach, Peter B (Peter)" cc: "'l2vpn@ietf.org'" Subject: Re: Truly Generalized VPLS (?) In-reply-to: Your message of Mon, 28 Jul 2003 17:19:31 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 31 Jul 2003 15:43:26 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Given your sample topology: U-SRC-PE---N-SRC-PE--------N-DST-PE---U-DST-PE One proposal uses directed LDP to set up three LDP adjacencies between (a) U-SRC-PE and N-SRC-PE, (b) N-SRC-PE and N-DST-PE, and (c) N-DST-PE and U-DST-PE. The other proposal sets up RSVP adjacencies between (a) U-SRC-PE and N-SRC-PE, (b) N-SRC-PE and N-DST-PE, and (c) N-DST-PE and U-DST-PE. So far, the only difference is that the PW setup TLVs and procedures have already been defined for LDP, but for RSVP we'd have to define them. If I may quote you, "why don't we use an existing solution instead of inventing a new one?" ;-) Either proposal needs to be able to carry information between U-SRC-PE and U-DST-PE. Not a problem for either protocol. In LDP, when you receive a particular TLV on one session, you forward the corresponding TLV on the other. That doesn't seem like much of an issue, though the proper behavior would need to be specified. (Note that in an "ordinary" MPLS LSP, there is an independent LDP connection between every adjacent pair of LSRs. The notion of passing attributes along the path, by passing them through the sequence of LDP connections, is well understood; see the "path vector" and the "MTU" attributes.) Peter> Draft-rosen-l2-signaling suggests that you set up all PW segments Peter> independently and then splice them together. Suppose that SRC-U-PE Peter> and SRC-N-PE agree to use a Control Word and DST-N-PE and DST-U-PE Peter> agree not to use a Control Word. In principle this is no different than if SRC-U-PE and DST-U-PE don't agree on whether to use the control word. In that case, you don't get an operational pseudowire. In the splicing case, this would show up as the inability to get an operational pseudowire between SRC-N-PE and DST-N-PE. Peter> Is it the idea that one of the N-PEs inserts and deletes Control Peter> Words? That isn't my proposal, though others have suggested that there if the "splice points" are at SP boundaries, there are some advantages to having the splice points do control word processing. Well, I'm not sure about that, but I can certainly see advantages to breaking out the OAM processing at SP boundaries, for example. Peter> In the RSVP approach, the only information maintained in the Peter> intermediate nodes is related to PW labels. I think you also have to maintain the new objects, so the amount of state to be maintained seems to be the same. Peter> 1) TTL Peter> Does each element in the path set the TTL to 2, or does the SRC-N-PE Peter> set it to 4 and the subsequent nodes decrease the value? As I've said repeatedly, the TTL should not be set to 2. Peter> 2) OAM Peter> If the SRC-U-PE sends a VCCV Ping message, is it terminated by Peter> SRC-N-PE? And is the PW between SRC-N-PE and DST-N-PE tested Peter> independently? Or is the VCCV Ping sent by SRC-U-PE, forwarded by Peter> SRC-N-PE to DST-N-PE, which in turn sends it to DST-U-PE? I think that in either method, the data plane is transparent to the splicing, for any OAM done in the data plane will tend to be edge-to-edge. This may not always be desired; if a splice point is at a provider-provider border, each provider might want to test his piece separately. I don't see that these issues are any different for the two proposals. Peter> 3) Protection switching Peter> Suppose SRC-U-PE is dual-homed but has set up only a single spliced Peter> PW to DST-U-PE. Now suppose that the PW segment between SRC-N-PE and Peter> DST-N-PE goes down and can not be restored. How does SRC-U-PE find Peter> out that it needs to set up another PW through the other N-PE it is Peter> connected to? Does N-PE send an error message that reports a fault on Peter> a segment of the spliced PW? I don't see that these issues are any different for the two proposals. Peter> There are standard protocols for setting up an LSP across multiple Peter> intermediate nodes. Well, yes, that's the typical use of LDP. Peter> If by LDP you mean CR-LDP Yuck. Peter> If by LDP you mean the topology-based flooding of labels No, directed LDP of course. Peter> In a previous email I asked how an N-PE discovers the "local list" Peter> and "remote list" that you mention in section 5.5.1 of Peter> draft-rosen-l2-signaling. From your answer I got the impression that Peter> you envisioned that those lists would be manually provisioned by the Peter> Service Provider. No, the information can be distributed by whatever auto-discovery procedure we are using. From exim@www1.ietf.org Thu Jul 31 17:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14350 for ; Thu, 31 Jul 2003 17:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iKoG-00065e-6y for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 17:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VLI4TR023404 for l2vpn-archive@odin.ietf.org; Thu, 31 Jul 2003 17:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iKoF-00065P-TO for l2vpn-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 17:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14339 for ; Thu, 31 Jul 2003 17:17:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iKoD-0007gT-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 17:18:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iKoD-0007gQ-00 for l2vpn-web-archive@ietf.org; Thu, 31 Jul 2003 17:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iKoD-00064y-9V; Thu, 31 Jul 2003 17:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iKnE-00064W-UI for l2vpn@optimus.ietf.org; Thu, 31 Jul 2003 17:17:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14328 for ; Thu, 31 Jul 2003 17:16:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iKnC-0007g8-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 17:16:58 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19iKnB-0007g5-00 for l2vpn@ietf.org; Thu, 31 Jul 2003 17:16:57 -0400 Received: (qmail 13988 invoked from network); 31 Jul 2003 21:27:44 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx1.ca.alcatel.com with SMTP; 31 Jul 2003 21:27:44 -0000 Received: from alcatel.com ([138.120.62.4]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HIWR4900.LLE; Thu, 31 Jul 2003 17:16:57 -0400 Message-ID: <3F298741.1BE6B5A6@alcatel.com> Date: Thu, 31 Jul 2003 17:16:49 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Kireeti Kompella , Alex Zinin , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols References: <200307311658.h6VGwTxc024285@rtp-core-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Norm suggested that a PE not bring up any of its PWs unless it had an > operational PW to each other PE that it learns about via the discovery > process. This also has the problem that if you don't have a PW to Z, you > can't tell locally whether anyone else has a PW to Z. (If no one has a PW > to Z, then of course everything is okay as is.) Agree VPLS membership info is not sufficient to determine whether MAC/VPLS/PW port should be blocked. An additional mechanism to know about other currently participating PW and PE may be needed then. Having said this, I am not suggesting that this mechanism should be used, merely trying to think what is needed with the approaches being discussed, to get things to work. Regards Cheng-Yin