From l2vpn-bounces@ietf.org Tue Apr 1 10:07:19 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FAE23A6EEA; Tue, 1 Apr 2008 10:07:19 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F201728C4E5 for ; Tue, 1 Apr 2008 10:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgkanVazBy+U for ; Tue, 1 Apr 2008 10:07:06 -0700 (PDT) Received: from audl953.usa.alcatel.com (audl953.usa.alcatel.com [143.209.238.162]) by core3.amsl.com (Postfix) with ESMTP id 2C89F28C513 for ; Tue, 1 Apr 2008 10:05:09 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id m31H4uKo019179; Tue, 1 Apr 2008 11:04:58 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Apr 2008 12:04:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN WG (Re-)charter Date: Tue, 1 Apr 2008 12:04:35 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191956@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN WG (Re-)charter Thread-Index: AciHuyAle6+n/c6qSiqqqGk5IqRo5wLwoU4A From: "BALUS Florin" To: "Shane Amante" , X-OriginalArrivalTime: 01 Apr 2008 17:04:45.0767 (UTC) FILETIME=[7C6D7D70:01C8941A] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi, See below some comments (between FB>) on selected items: The L2VPN WG scope includes the following: [..]=20 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. FB> Suggest we modify the text to include also multi-homing between 2 VPLS domains, see below an example of text: 6. Improved service convergence for multi-homing solutions: CEs to VPLS PEs or between VPLS domains. Specifically, upon failure of a primary path from a between CEs and VPLS PEs or between VPLS domains, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. FB> 7. Enhancements to increase the scalability of the Forwarding Database of VPLS PE nodes. FB> I think we should make this text more generic: i.e. 7. Enhancements to increase VPLS scalability. This will address any issues that might be raised in the future. In the milestones we have anyhow two more generic items that are already looking beyond what the current item 7 is covering: i.e. Nov 2009 Submit scalability solutions for VPLS Control-Plane to IESG Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG FB> The L2VPN WG currently works on the following tasks: [..] - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. FB> Suggest changing this one to the following text: - Identify requirements for different multi-homing solutions: i.e. CEs to VPLS Pes or between VPLS domains. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. FB> Goals and Milestones: [..] FB> We are missing here L2VPN Auto-discovery, Signaling and Inter-AS (see draft-ietf-l2vpn-signaling-08.txt). This was already submitted to IESG and is waiting in the RFC queue. Suggest adding the following item: "Done Submit L2VPN Auto-discovery, Signaling and Inter-AS to IESG" [..] Nov 2008 Submit MAC learning optimization solutions for VPLS to IESG FB> What is this about? [..] Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS)requirements to IESG [..] Nov 2009 Submit Auto-Discovery solution for VPMS to IESG FB> (this comment applies to the 2 previous items) Not sure I understand what are we trying to achieve here? We stated in item 5 of the charter that L2 VPN WG is going to deal with "5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it similar with P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on this just in case we are dealing with a VPN like collection of PWs. Otherwise we should probably address this in PWE3/MPLS to start with. FB> Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG FB> I thought we already have these items addressed in draft-ietf-l2vpn-signaling-08.txt ("Provisioning, Autodiscovery, and Signaling in L2VPNs"), currently in the RFC queue.=20 Regards, Florin > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Sunday, March 16, 2008 4:11 PM > To: l2vpn@ietf.org > Subject: L2VPN WG (Re-)charter >=20 > Hi, >=20 > As mentioned during the WG meeting at IETF 71 in=20 > Philadelphia, below is a proposed draft of a new charter for=20 > the L2VPN WG. Included are the following new items: > - Multicast > - Scalability > - Multi-homing / Service Convergence > - Inter-AS >=20 > Please take a look at the entire text, including suggested=20 > dates for deliverables & milestones. >=20 > Please send any questions, clarifications or suggested=20 > changes to the WG mailing list. If you believe the new=20 > charter (below) is fine "as- is", then please indicate your=20 > support to the WG mailing list, as well. >=20 > We would like to set a time-limit for discussion and=20 > agreement of the =20 > new charter, in order that we can get back to the business at hand. =20 > As such, let me propose that we wrap-up discussion and gauge=20 > (rough) consensus by Friday, April 25, 1700 MDT (UTC -6),=20 > which is a little over 1 month from now. >=20 > Thanks, >=20 > -shane & Vach >=20 > ---cut here--- >=20 > The L2VPN working group is responsible for defining and=20 > specifying a limited number of solutions for supporting=20 > provider-provisioned Layer-2 Virtual Private Networks=20 > (L2VPNs). Layer-2 VPN's comprise the > following: >=20 > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service=20 > that emulates > an Ethernet (V)LAN across an IP or an MPLS-enabled IP=20 > Packet Switched > Network (PSN). >=20 > 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service=20 > that provides > point-to-point connectivity for a variety of link layers,=20 > including > Frame Relay, ATM, Ethernet, PPP, etc., across an IP or=20 > MPLS- enabled IP > PSN. >=20 > 3. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" > service over an IP or MPLS-enabled PSN. This service is=20 > similar to > VPWS because it supports a variety of link-layer protocols on the > Attachment Circuits, including Frame Relay, ATM,=20 > Ethernet, PPP, etc. > IP-only L2VPN's are different from both VPLS and VPWS=20 > because unicast > Layer-2 frames containing IP data packets, either IPv4 or=20 > IPv6, are de- > encapsulated leaving only the IP data packet to be=20 > transmitted over > the PSN. An IP-only L2VPN service also differs from=20 > L3VPN service, > since no routing protocol operates between the PE and CE;=20 > furthermore, > connectivity from CE to CE is provided via an emulated=20 > Layer-2 service > over the PSN, which results in the CE's appearing to be directly > attached to each other at Layer-2. The WG will address=20 > two specific > types of IP-only L2VPN: >=20 > a) Those with Attachment Circuits (ACs) that use the same Layer 2 > framing at all attachment points in the same L2VPN; and, >=20 > b) Those with ACs that use different Layer 2 framing at various > attachment points in the same L2VPN. For (b),=20 > inter-working between > link-layers is strictly out of scope beyond that which is=20 > minimally > necessary to ensure that IP packets are transported from=20 > an AC of one > type, across the IP or MPLS-enabled IP PSN, and to an AC=20 > of another > type in as transparent a manner as possible to the CEs on=20 > both sides > of the service. >=20 > VPLS and VPWS operate over Pseudowires (PWs) as defined by=20 > the PWE3 WG. > As with a single PW, an L2VPN emulates a "native" service=20 > over a PSN that is reasonably faithful to, but may not be=20 > entirely indistinguishable from, the native service itself.=20 > Further, following in the "edge-to- edge" > nature of the PWs that it uses, the L2VPN WG will not define=20 > any new mechanisms which exert control over the underlying=20 > PSN. When necessary it may, however, recommend or require=20 > the use of existing PSN QoS and path control mechanisms=20 > between PW endpoints which make up the L2VPN. >=20 > L2VPN's will make use of existing IETF specified mechanisms=20 > unless there are technical reasons why the existing=20 > mechanisms are insufficient or unnecessary. >=20 > The L2VPN WG is responsible for specification of the=20 > discovery and membership of PE's participating in a VPLS,=20 > VPWS or IP-only L2VPN as well as the membership of CE devices=20 > to a specific instance of a L2VPN. >=20 > The L2VPN WG will provide extensions of existing protocols=20 > that will be discussed in protocol-specific WG's. In=20 > particular, the L2VPN WG will define extensions to pseudowire=20 > management (OAM) mechanisms, specifically Pseudowire Virtual=20 > Circuit Connectivity Verification (VCCV), for VPLS. Those=20 > VCCV extensions will be reviewed by PWE3 to ensure they are=20 > inline with the overall design/architecture of VCCV. >=20 > The L2VPN WG will not define new encapsulations, control=20 > (set-up, configuration, maintenance or tear-down), or=20 > resiliency mechanisms specifically related to pseudowires,=20 > because those must be defined by the > PWE3 WG. Furthermore, the L2VPN WG will not define protocol=20 > inter- working between a VPLS or VPWS and native=20 > service-layer control, OAM or or resiliency mechanisms, as=20 > those will be defined by the PWE3 WG. On the other hand, the=20 > L2VPN WG will define how to operate native service- layer=20 > control, OAM or resiliency mechanisms on top of a VPLS or=20 > VPWS service. >=20 > The L2VPN WG scope includes the following: >=20 > 1. Discovery of PE's participating in a Layer-2 VPN and the associated > topology required for connectivity of the VPLS or VPWS service. >=20 > 2. Signaling of information related to the discovery and membership of > PE's within a L2VPN. These procedures must use PWE3 control and > management procedures, or define requirements for extensions of PWE3 > protocols to suit the needs of an L2VPN. Once those requirements are > reviewed by the L2VPN WG, they should be provided to the PWE3 WG to > derive solutions. >=20 > 3. MIB's for Layer-2 VPN solutions. >=20 > 4. Specification of requirements and framework that will=20 > define Operations Administration and Management (OAM) procedures for VPLS=20 > and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over=20 > IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for > VPLS and VPWS VPN's. >=20 > 5. Mechanisms to permit optimization of multicast data traffic within > a VPLS or VPWS VPN over an IP/MPLS PSN. >=20 > 6. Improved service convergence for multi-homed CE's to VPLS PE's. > Specifically, upon failure of a primary path from a CE to VPLS PE, > initiate a rapid switch-over to an alternate path. If required, > interactions with native service-layer resiliency mechanisms will be > provided via solutions from other IETF WG's such as PWE3. >=20 > 7. Enhancements to increase the scalability of the Forwarding=20 > Database of VPLS PE nodes. >=20 > 8. Definition of requirements and solutions for Inter-AS VPLS and VPWS > services. >=20 > The L2VPN WG currently works on the following tasks: >=20 > - Define MIB's appropriate for each type of Layer-2 VPN. >=20 > - Specification of Operations Administration and Management (OAM) > mechanisms for VPLS, VPWS and IP-only VPN's. >=20 > - Specification of procedures to permit optimization of L2VPN=20 > multicast > data traffic within the PSN. >=20 > - Define enhancements to increase scalability of VPLS PE nodes, to > provide aggregation of learned customer MAC addresses at VPLS PE's. >=20 > - Identify requirements for multi-homing of CE's to VPLS PE's. > elements. Based on these requirements, define solutions=20 > for achieving > fast convergence after a switchover to an alternate path,=20 > for example > through optimized MAC flushing within a VPLS domain. >=20 > - Identify requirements for Inter-AS VPLS and VPWS services. Define > Inter-AS enhancements to VPLS and VPWS based on these requirements. >=20 > Where necessary, the WG will coordinate its activities with=20 > IEEE 802.1. >=20 > Goals and Milestones: >=20 > Done Submit L2 requirements to IESG for publication as=20 > Informational =20 > RFC > Done Identify VPLS and VPWS solutions for the WG > Done Submit L2 framework to IESG for publication as=20 > Informational RFC > Done Submit VPLS solution documents to IESG > Done Submit VPWS solution documents to IESG > Done Submit an I-D on OAM requirements for VPLS > Done Submit an I-D on OAM requirements for VPWS > Done Submit an I-D describing MIB for VPLS > Done Submit an I-D describing MIB for VPWS >=20 > Mar 2008 Submit IP-only L2VPN solution documents to IESG >=20 > Nov 2008 Submit MAC learning optimization solutions for=20 > VPLS to IESG >=20 > Nov 2008 Submit multicast optimization solutions for VPLS to IESG >=20 > Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG >=20 > Mar 2009 Submit OAM solutions for VPWS to IESG > Mar 2009 Submit OAM solutions for VPLS to IESG > Mar 2009 Submit OAM solutions for IP-only L2VPN to IESG >=20 > Jul 2009 Submit MIB for VPLS to IESG > Jul 2009 Submit MIB for VPWS to IESG > Jul 2009 Submit MIB for IP-only L2VPN to IESG >=20 > Nov 2009 Submit Auto-Discovery solution for VPMS to IESG >=20 > Nov 2009 Submit scalability solutions for VPLS=20 > Control-Plane to IESG > Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG >=20 > Jul 2010 Submit VPLS service convergence improvement solutions to =20 > IESG >=20 > Jul 2010 Submit VPLS multi-homing solutions to IESG >=20 > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG >=20 From l2vpn-bounces@ietf.org Tue Apr 1 11:51:00 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F37728C518; Tue, 1 Apr 2008 11:51:00 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D08728C517 for ; Tue, 1 Apr 2008 11:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nayyS-ZvH-fN for ; Tue, 1 Apr 2008 11:50:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 499DA28C463 for ; Tue, 1 Apr 2008 11:50:54 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 11:50:43 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m31IohSD002239; Tue, 1 Apr 2008 11:50:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m31IohBh023420; Tue, 1 Apr 2008 18:50:43 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 11:50:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN WG (Re-)charter Date: Tue, 1 Apr 2008 11:50:41 -0700 Message-ID: <483F121CD2155B43B56DB71228DBAF1501448CB2@xmb-sjc-239.amer.cisco.com> In-Reply-To: <47F13154.6070703@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN WG (Re-)charter Thread-Index: AciTX5xP9M7BTljhRxaNt7IL9E9LfwAwZjvA From: "Ali Sajassi (sajassi)" To: "Shane Amante" , X-OriginalArrivalTime: 01 Apr 2008 18:50:42.0765 (UTC) FILETIME=[497E67D0:01C89429] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14523; t=1207075843; x=1207939843; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20 |Subject:=20RE=3A=20L2VPN=20WG=20(Re-)charter |Sender:=20; bh=QAH11Y6N+Zj7FQIbvy30lQlp+WffxYJ5Q3Y0JCfLCE8=; b=RosDYe4TFea4igxcATcufkZ0xdDFkbkQtAoNSlihK8cWsngbqhCO/6hoj3 OLmpDagkQESfIu9aNayVEA90mE6NESjI1JQ8YTMzLJX8hkWQhf4QFMbCdNxh BwK8/STq7W; Authentication-Results: sj-dkim-4; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, Please note the following comments regarding the re-chartering. i) "L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary." AS> This statement needs further clarification. I would suggest the following text: "L2VPN solutions will make use of existing IETF PWs and PSN specified mechanisms for providing L2VPN services unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. Furthermore, L2VPN solutions will make use of native service mechanisms when applicable for providing L2VPN services - e.g., use of Ethernet OAM for monitoring Ethernet native service. ii) "The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG will define extensions to pseudowire management (OAM) mechanisms, specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV." AS> This statement already assumes that VCCV extensions are needed for VPLS which is not the case. I would prefer to either remove 2nd and 3rd sentences from the above para. If we want to keep these sentences, then we need to change "will" to "may" in 2nd sentence. iii) "Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG will define how to operate native service- layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS service." AS> This statement needs to be refined to indicate that the interworking between the native service-layer and its associated PW for the purpose of control, OAM, or resiliency mechanisms, shall be defined by the PWE3 WG. However, the interworking between the native service-layer and the VPN service, associated with a group of PWs and their forwarding tables, will be defined by the L2VPN WG when needed. iv) "5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN." AS> mcast optimization should only be for VPLS based on VPWS service definition. v) "6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3." AS> We should create another bullet to include multi-homing between two or more VPLS networks. vi) "7. Enhancements to increase the scalability of the Forwarding Database of VPLS PE nodes." AS> I would prefer a more explicit language with respect to scalability such as "scalability of customer MAC addresses and number of PW" vii) "- Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's." AS> should be changed to " Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses and to reduce number of PWs at VPLS PE's." Regards, Ali =20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Monday, March 31, 2008 11:46 AM > To: l2vpn@ietf.org > Subject: Re: L2VPN WG (Re-)charter >=20 > Hi Folks, >=20 > It's been just over two weeks and we haven't heard any=20 > support for or comments on the suggested charter below. This=20 > is just a gentle reminder to speak up in order that=20 > current/in-flight and future projects aren't delayed or dropped. >=20 > -shane >=20 >=20 > Shane Amante wrote: > > Hi, > >=20 > > As mentioned during the WG meeting at IETF 71 in=20 > Philadelphia, below=20 > > is a proposed draft of a new charter for the L2VPN WG. =20 > Included are=20 > > the following new items: > > - Multicast > > - Scalability > > - Multi-homing / Service Convergence > > - Inter-AS > >=20 > > Please take a look at the entire text, including suggested=20 > dates for=20 > > deliverables & milestones. > >=20 > > Please send any questions, clarifications or suggested=20 > changes to the=20 > > WG mailing list. If you believe the new charter (below) is fine=20 > > "as-is", then please indicate your support to the WG=20 > mailing list, as well. > >=20 > > We would like to set a time-limit for discussion and=20 > agreement of the=20 > > new charter, in order that we can get back to the business=20 > at hand. =20 > > As such, let me propose that we wrap-up discussion and=20 > gauge (rough)=20 > > consensus by Friday, April 25, 1700 MDT (UTC -6), which is a little=20 > > over > > 1 month from now. > >=20 > > Thanks, > >=20 > > -shane & Vach > >=20 > > ---cut here--- > >=20 > > The L2VPN working group is responsible for defining and=20 > specifying a=20 > > limited number of solutions for supporting provider-provisioned=20 > > Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's=20 > comprise the following: > >=20 > > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service=20 > that emulates > > an Ethernet (V)LAN across an IP or an MPLS-enabled IP=20 > Packet Switched > > Network (PSN). > >=20 > > 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service=20 > that provides > > point-to-point connectivity for a variety of link=20 > layers, including > > Frame Relay, ATM, Ethernet, PPP, etc., across an IP or=20 > MPLS-enabled IP > > PSN. > >=20 > > 3. IP-only L2VPN -- A point-to-point or point-to-multipoint=20 > "IP-only" > > service over an IP or MPLS-enabled PSN. This service is=20 > similar to > > VPWS because it supports a variety of link-layer protocols on the > > Attachment Circuits, including Frame Relay, ATM,=20 > Ethernet, PPP, etc. > > IP-only L2VPN's are different from both VPLS and VPWS=20 > because unicast > > Layer-2 frames containing IP data packets, either IPv4=20 > or IPv6, are de- > > encapsulated leaving only the IP data packet to be=20 > transmitted over > > the PSN. An IP-only L2VPN service also differs from=20 > L3VPN service, > > since no routing protocol operates between the PE and=20 > CE; furthermore, > > connectivity from CE to CE is provided via an emulated=20 > Layer-2 service > > over the PSN, which results in the CE's appearing to be directly > > attached to each other at Layer-2. The WG will address=20 > two specific > > types of IP-only L2VPN: > >=20 > > a) Those with Attachment Circuits (ACs) that use the same Layer 2 > > framing at all attachment points in the same L2VPN; and, > >=20 > > b) Those with ACs that use different Layer 2 framing at various > > attachment points in the same L2VPN. For (b),=20 > inter-working between > > link-layers is strictly out of scope beyond that which=20 > is minimally > > necessary to ensure that IP packets are transported from=20 > an AC of one > > type, across the IP or MPLS-enabled IP PSN, and to an AC=20 > of another > > type in as transparent a manner as possible to the CEs=20 > on both sides > > of the service. > >=20 > > VPLS and VPWS operate over Pseudowires (PWs) as defined by=20 > the PWE3 WG. > > As with a single PW, an L2VPN emulates a "native" service=20 > over a PSN=20 > > that is reasonably faithful to, but may not be entirely=20 > > indistinguishable from, the native service itself. Further,=20 > following in the "edge-to-edge" > > nature of the PWs that it uses, the L2VPN WG will not=20 > define any new=20 > > mechanisms which exert control over the underlying PSN. When=20 > > necessary it may, however, recommend or require the use of existing=20 > > PSN QoS and path control mechanisms between PW endpoints=20 > which make up the L2VPN. > >=20 > > L2VPN's will make use of existing IETF specified mechanisms unless=20 > > there are technical reasons why the existing mechanisms are=20 > > insufficient or unnecessary. > >=20 > > The L2VPN WG is responsible for specification of the discovery and=20 > > membership of PE's participating in a VPLS, VPWS or IP-only=20 > L2VPN as=20 > > well as the membership of CE devices to a specific instance=20 > of a L2VPN. > >=20 > > The L2VPN WG will provide extensions of existing protocols=20 > that will=20 > > be discussed in protocol-specific WG's. In particular, the=20 > L2VPN WG=20 > > will define extensions to pseudowire management (OAM) mechanisms,=20 > > specifically Pseudowire Virtual Circuit Connectivity Verification=20 > > (VCCV), for VPLS. Those VCCV extensions will be reviewed=20 > by PWE3 to=20 > > ensure they are inline with the overall design/architecture of VCCV. > >=20 > > The L2VPN WG will not define new encapsulations, control (set-up,=20 > > configuration, maintenance or tear-down), or resiliency mechanisms=20 > > specifically related to pseudowires, because those must be=20 > defined by=20 > > the > > PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter-=20 > > working between a VPLS or VPWS and native service-layer=20 > control, OAM=20 > > or or resiliency mechanisms, as those will be defined by=20 > the PWE3 WG. =20 > > On the other hand, the L2VPN WG will define how to operate native=20 > > service- layer control, OAM or resiliency mechanisms on top=20 > of a VPLS=20 > > or VPWS service. > >=20 > > The L2VPN WG scope includes the following: > >=20 > > 1. Discovery of PE's participating in a Layer-2 VPN and the=20 > associated > > topology required for connectivity of the VPLS or VPWS service. > >=20 > > 2. Signaling of information related to the discovery and=20 > membership of > > PE's within a L2VPN. These procedures must use PWE3 control and > > management procedures, or define requirements for=20 > extensions of PWE3 > > protocols to suit the needs of an L2VPN. Once those=20 > requirements are > > reviewed by the L2VPN WG, they should be provided to the=20 > PWE3 WG to > > derive solutions. > >=20 > > 3. MIB's for Layer-2 VPN solutions. > >=20 > > 4. Specification of requirements and framework that will=20 > define Operations > > Administration and Management (OAM) procedures for VPLS=20 > and VPWS VPN's, > > related to the operation of VPLS and VPWS VPN's over=20 > IP/MPLS PSN's. > > In addition, the L2VPN WG will define OAM solutions for=20 > VPLS and VPWS > > VPN's. > >=20 > > 5. Mechanisms to permit optimization of multicast data=20 > traffic within > > a VPLS or VPWS VPN over an IP/MPLS PSN. > >=20 > > 6. Improved service convergence for multi-homed CE's to VPLS PE's. > > Specifically, upon failure of a primary path from a CE=20 > to VPLS PE, > > initiate a rapid switch-over to an alternate path. If required, > > interactions with native service-layer resiliency=20 > mechanisms will be > > provided via solutions from other IETF WG's such as PWE3. > >=20 > > 7. Enhancements to increase the scalability of the=20 > Forwarding Database of > > VPLS PE nodes. > >=20 > > 8. Definition of requirements and solutions for Inter-AS=20 > VPLS and VPWS > > services. > >=20 > > The L2VPN WG currently works on the following tasks: > >=20 > > - Define MIB's appropriate for each type of Layer-2 VPN. > >=20 > > - Specification of Operations Administration and Management (OAM) > > mechanisms for VPLS, VPWS and IP-only VPN's. > >=20 > > - Specification of procedures to permit optimization of=20 > L2VPN multicast > > data traffic within the PSN. > >=20 > > - Define enhancements to increase scalability of VPLS PE nodes, to > > provide aggregation of learned customer MAC addresses at=20 > VPLS PE's. > >=20 > > - Identify requirements for multi-homing of CE's to VPLS PE's. > > elements. Based on these requirements, define solutions=20 > for achieving > > fast convergence after a switchover to an alternate path,=20 > for example > > through optimized MAC flushing within a VPLS domain. > >=20 > > - Identify requirements for Inter-AS VPLS and VPWS services. Define > > Inter-AS enhancements to VPLS and VPWS based on these=20 > requirements. > >=20 > > Where necessary, the WG will coordinate its activities with=20 > IEEE 802.1. > >=20 > > Goals and Milestones: > >=20 > > Done Submit L2 requirements to IESG for publication as=20 > Informational RFC > > Done Identify VPLS and VPWS solutions for the WG > > Done Submit L2 framework to IESG for publication as=20 > Informational RFC > > Done Submit VPLS solution documents to IESG > > Done Submit VPWS solution documents to IESG > > Done Submit an I-D on OAM requirements for VPLS > > Done Submit an I-D on OAM requirements for VPWS > > Done Submit an I-D describing MIB for VPLS > > Done Submit an I-D describing MIB for VPWS > >=20 > > Mar 2008 Submit IP-only L2VPN solution documents to IESG > >=20 > > Nov 2008 Submit MAC learning optimization solutions for=20 > VPLS to IESG > >=20 > > Nov 2008 Submit multicast optimization solutions for VPLS to IESG > >=20 > > Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) > > requirements to IESG > >=20 > > Mar 2009 Submit OAM solutions for VPWS to IESG > > Mar 2009 Submit OAM solutions for VPLS to IESG > > Mar 2009 Submit OAM solutions for IP-only L2VPN to IESG > >=20 > > Jul 2009 Submit MIB for VPLS to IESG > > Jul 2009 Submit MIB for VPWS to IESG > > Jul 2009 Submit MIB for IP-only L2VPN to IESG > >=20 > > Nov 2009 Submit Auto-Discovery solution for VPMS to IESG > >=20 > > Nov 2009 Submit scalability solutions for VPLS=20 > Control-Plane to IESG > > Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG > >=20 > > Jul 2010 Submit VPLS service convergence improvement=20 > solutions to IESG > >=20 > > Jul 2010 Submit VPLS multi-homing solutions to IESG > >=20 > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG >=20 >=20 From l2vpn-bounces@ietf.org Tue Apr 1 14:33:21 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F5D28C5E8; Tue, 1 Apr 2008 14:33:21 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9D228C5DA for ; Tue, 1 Apr 2008 14:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QurYDfn5NEQY for ; Tue, 1 Apr 2008 14:33:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A504D28C60C for ; Tue, 1 Apr 2008 14:30:45 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E2C22268081; Tue, 1 Apr 2008 15:30:44 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Tue, 01 Apr 2008 15:30:44 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=55906; data-bytes=0 Message-ID: <47F2A983.1030008@castlepoint.net> Date: Tue, 01 Apr 2008 15:30:43 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: L2VPN (Re-)charter: VPLS OAM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org All, Since there been a variety of comments about the re-charter, I'm going to attempt to group related comments and respond to them that way. Hopefully, this way people can follow along more easily. See below for the first response related to VPLS OAM. ---snip--- Dinesh, Ali, ------Dinesh wrote------ > "L2VPN's will make use of existing IETF specified mechanisms unless > there are technical reasons why the existing mechanisms are > insufficient or unnecessary." > > DM>> Which IETF mechanisms are we referring to? This statement seems > quite vague, can we offer some guidance around the relevance of this > statement. Actually, this statement was copied from the PWE3 charter. The intent is to state that L2VPN WG will re-use MPLS (or L2TPv3) as defined by the MPLS WG for the PSN, PW's as defined by PWE3 for service-layer encapsulation, SNMP for MIB's, etc. See below for more. > "In particular, the L2VPN WG will define extensions to Pseudowire > management (OAM) mechanisms, specifically Pseudowire Virtual Circuit > Connectivity Verification (VCCV), for VPLS. Those VCCV extensions ' > will be reviewed by PWE3 to ensure they are inline with the overall > design/architecture of VCCV." > > DM>> Is it necessary to include this statement in the charter? This is > presuming solutions that may not have been completely hashed out yet. > Isn't the first statement Sufficient in this para "The L2VPN WG will > provide extensions of existing protocols that will be discussed in > protocol-specific WG's." You raise a fair point. I am willing to change the "will" to a "may" as suggested by Ali, (see below for that change). That leaves open the potential of us extending VCCV within this proposed charter, rather than having to come back and re-charter again or, worse, toss around multiple drafts in both PWE3 and L2VPN if we determine a need to extend VCCV. Plus, given all the recent work on T-MPLS and T-MPLS OAM, our AD's wanted to make it explicit that a portion of VCCV may be worked on within L2VPN, so people/other-SDO's know where to direct liaisons/questions/etc. ------Ali wrote------ > i) "L2VPN's will make use of existing IETF specified mechanisms unless > there are technical reasons why the existing mechanisms are > insufficient or unnecessary." > > AS> This statement needs further clarification. I would suggest the > following text: "L2VPN solutions will make use of existing IETF PWs > and PSN specified mechanisms for providing L2VPN services unless there > are technical reasons why the existing mechanisms are insufficient or > unnecessary. Furthermore, L2VPN solutions will make use of native > service mechanisms when applicable for providing L2VPN services - > e.g., use of Ethernet OAM for monitoring Ethernet native service. First, the intent of the sentence /is not/ to create an exhaustive list of all protocols we may (or may not) end up (re-)using from other WG's, or other SDO's for that matter. Second, the last sentence you suggested appears to be saying that 802.1ag ("native service-layer mechansims") should be the only OAM tool for VPLS. I'm pretty confident we don't have WG consensus to make that statement in the charter, particularly given the "lively" debates that have ensued at WG meetings when discussing the two proposed OAM solutions. However, to bring this back to the charter discussion, I believe the sentence is OK 'as-is', since it leaves room to discuss and make use of alternate mechanisms if "the existing mechansisms are insufficent or unnecessary". Specific to VPLS OAM, Dinesh has already been highlighting (in his presentations at the WG meetings) the areas where .1ag may provide a superior solution for *some* aspects of VPLS OAM. In addition, Olen's draft (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a more in-depth analysis. Unfortunately, the only debate on Olen's draft /on the mailing list/ has been about just one aspect of the draft, specifically the H-VPLS reference model, which has already been acknowledged as incorrect. We need to move on from that and look at the rest of Olen's draft to objectively determine what are the strengths & weaknesses of either or both (i.e. complementary) OAM approaches if we're going to make progress on OAM. > ii) "The L2VPN WG will provide extensions of existing protocols that > will be discussed in protocol-specific WG's. In particular, the L2VPN > WG will define extensions to pseudowire management (OAM) mechanisms, > specifically Pseudowire Virtual Circuit Connectivity Verification > (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to > ensure they are inline with the overall design/architecture of VCCV." > > AS> This statement already assumes that VCCV extensions are needed for > VPLS which is not the case. I would prefer to either remove 2nd and > 3rd sentences from the above para. If we want to keep these sentences, > then we need to change "will" to "may" in 2nd sentence. OK, I'll accept the change in your last sentence, (change from "will" to "may" in the second sentence). Specifically, I'll reword the charter as follows: ---snip--- The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management (OAM) mechanisms, specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV." ---snip--- > iii) "Furthermore, the L2VPN WG will not define protocol inter-working > between a VPLS or VPWS and native service-layer control, OAM or > resiliency mechanisms, as those will be defined by the PWE3 WG. On > the other hand, the L2VPN WG will define how to operate native > service-layer control, OAM or resiliency mechanisms on top of a VPLS > or VPWS service." > > AS> This statement needs to be refined to indicate that the > interworking between the native service-layer and its associated PW > for the purpose of control, OAM, or resiliency mechanisms, shall be > defined by the PWE3 WG. However, the interworking between the native > service-layer and the VPN service, associated with a group of PWs and > their forwarding tables, will be defined by the L2VPN WG when needed. I'm not sure I understand the intent or need for the last sentence you propose. Can you elaborate on it? Specifically, I'm trying to understand what might just be implementation details irrelevant to L2VPN, say specific to the Bridge Module and AC's, vs. some interaction between PW's and the Bridge Module or something else. Thanks, -shane From l2vpn-bounces@ietf.org Tue Apr 1 16:46:51 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3DB3A6E88; Tue, 1 Apr 2008 16:46:51 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9DC3A6D29 for ; Tue, 1 Apr 2008 16:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKLVKjNjmalT for ; Tue, 1 Apr 2008 16:46:48 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id B6DFC28C3A8 for ; Tue, 1 Apr 2008 16:46:48 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 1727B26803D; Tue, 1 Apr 2008 17:46:46 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Tue, 01 Apr 2008 17:46:46 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=37430; data-bytes=0 Message-ID: <47F2C964.7030609@castlepoint.net> Date: Tue, 01 Apr 2008 17:46:44 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: L2VPN (Re-)charter: Scalability Enhancements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Dinesh, Florin & Ali, Please see below. ------Dinesh wrote------ > DM>> We should enhance bullet 7 of scope which currently states "7. > Enhancements to increase the scalability of the Forwarding Database of > VPLS PE nodes." to at least provide some example of current direction, > similar to some other items in the list. As a suggestion "7. > Enhancements to increase the scalability of the Forwarding Database of > VPLS PE nodes. This may include using mechanisms being defined by IEEE > e.g. 802.1ah." First, we didn't want to list every possible protocol throughout the charter that we may end up (re-)using. Second, 802.1ah (at the data plane) is only one direction we're currently headed, there's also Control Plane optimizations as well. In order to "future-proof" the charter, I would prefer that we didn't explicitly list 802.1ah. In fact, I like Florin's suggestion that we abstract it further to account for optimizations to not only the Data Plane, but also Control Plane. Please see below for that. ------Ali wrote------ > vi) "7. Enhancements to increase the scalability of the Forwarding > Database of VPLS PE nodes." > > AS> I would prefer a more explicit language with respect to > scalability such as "scalability of customer MAC addresses and > number of PW" Since this is the "scope" section, how about we keep it slightly more generic than what you suggest? Specifically, what do you think about the language I suggest below in response to Florin? I think it should address your concern here. > vii) "- Define enhancements to increase scalability of VPLS PE nodes, > to provide aggregation of learned customer MAC addresses at > VPLS PE's." > > AS> should be changed to " Define enhancements to increase scalability > of VPLS PE nodes, to provide aggregation of learned customer MAC > addresses and to reduce number of PWs at VPLS PE's." What is your definition of, or goal of, "reduce number of PW's at VPLS PE's"? The number of PWE3 VC labels, the number of tLDP sessions, the number of signaling messages exchanged over a set of tLDP sessions or something else? We possibly need something wrt the benefit we're looking to acheive at the Control Plane, but we probably want to be more precise. With that in mind, can you suggest some more crisp text? ------Florin wrote------ > 7. Enhancements to increase the scalability of the Forwarding Database > of VPLS PE nodes. > > FB> I think we should make this text more generic: i.e. 7. Enhancements > to increase VPLS scalability. > This will address any issues that might be raised in the future. In the > milestones we have anyhow two more generic items that are already > looking beyond what the current item 7 is covering: i.e. > Nov 2009 Submit scalability solutions for VPLS Control-Plane to IESG > Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG > FB> OK, but I think that may be a bit too generic. Can we instead scope it a little bit more as follows: ---cut here--- 7. Enhancements to increase the scalability of the VPLS Control Plane and Data Plane (e.g.: Forwarding Database) of VPLS PE nodes. ---cut here--- Thanks, -shane From l2vpn-bounces@ietf.org Tue Apr 1 22:08:18 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD5B28C182; Tue, 1 Apr 2008 22:08:18 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968323A6A99 for ; Tue, 1 Apr 2008 22:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdmt5rF6aGfm for ; Tue, 1 Apr 2008 22:08:05 -0700 (PDT) Received: from audl952.usa.alcatel.com (audl952.usa.alcatel.com [143.209.238.159]) by core3.amsl.com (Postfix) with ESMTP id 7EC7228C2B6 for ; Tue, 1 Apr 2008 22:06:02 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id m3255u7c019327; Tue, 1 Apr 2008 23:05:56 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 00:05:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: Scalability Enhancements Date: Wed, 2 Apr 2008 00:05:44 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191AA8@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <47F2C964.7030609@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: Scalability Enhancements Thread-Index: AciUUsofVVVY02+2Twe0VL+GLBDnrgAKw+pg From: "BALUS Florin" To: "Shane Amante" , X-OriginalArrivalTime: 02 Apr 2008 05:05:56.0011 (UTC) FILETIME=[3B80BFB0:01C8947F] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, I am ok with your suggestions below. I think the text you proposed (I.e. 7. Enhancements to increase the scalability of the VPLS Control Plane and Data Plane (e.g.: Forwarding Database) of VPLS PE nodes.) addresses also the possibility to reduce the number of PWs which are part of the data plane. Maybe we can add in there the PWs to address Ali's suggestion: i.e. use "(e.g. MAC Forwarding Database, number of PWs)" instead of "(e.g. Forwarding Database)"? There are possibilities to provide reduction in the number of PWs by using a Backbone VPLS infrastructure to carry multiple customer VPNs. Florin > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Tuesday, April 01, 2008 4:47 PM > To: l2vpn@ietf.org > Subject: L2VPN (Re-)charter: Scalability Enhancements >=20 > Hi Dinesh, Florin & Ali, >=20 > Please see below. >=20 > ------Dinesh wrote------ > > DM>> We should enhance bullet 7 of scope which currently states "7. > > Enhancements to increase the scalability of the Forwarding=20 > Database of > VPLS PE nodes." to at least provide some=20 > example of current direction, > similar to some other items=20 > in the list. As a suggestion "7. > > Enhancements to increase the scalability of the Forwarding=20 > Database of > VPLS PE nodes. This may include using=20 > mechanisms being defined by IEEE > e.g. 802.1ah." >=20 > First, we didn't want to list every possible protocol=20 > throughout the charter that we may end up (re-)using. =20 > Second, 802.1ah (at the data > plane) is only one direction we're currently headed, there's=20 > also Control Plane optimizations as well. In order to=20 > "future-proof" the charter, I would prefer that we didn't=20 > explicitly list 802.1ah. In fact, I like Florin's suggestion=20 > that we abstract it further to account for optimizations to=20 > not only the Data Plane, but also Control Plane.=20 > Please see below for that. >=20 >=20 > ------Ali wrote------ > > vi) "7. Enhancements to increase the scalability of the Forwarding > > Database of VPLS PE nodes." > > > > AS> I would prefer a more explicit language with respect=20 > to > scalability such as "scalability of customer MAC=20 > addresses and > number of PW" >=20 > Since this is the "scope" section, how about we keep it=20 > slightly more generic than what you suggest? Specifically,=20 > what do you think about the language I suggest below in=20 > response to Florin? I think it should address your concern here. >=20 >=20 > > vii) "- Define enhancements to increase scalability of=20 > VPLS PE nodes, > > to provide aggregation of learned customer MAC addresses at > > VPLS PE's." > > > > AS> should be changed to " Define enhancements to increase=20 > scalability > of VPLS PE nodes, to provide aggregation of=20 > learned customer MAC > addresses and to reduce number of PWs=20 > at VPLS PE's." >=20 > What is your definition of, or goal of, "reduce number of=20 > PW's at VPLS PE's"? The number of PWE3 VC labels, the number=20 > of tLDP sessions, the number of signaling messages exchanged=20 > over a set of tLDP sessions or something else? We possibly=20 > need something wrt the benefit we're looking to acheive at=20 > the Control Plane, but we probably want to be more precise. =20 > With that in mind, can you suggest some more crisp text? >=20 >=20 >=20 > ------Florin wrote------ > > 7. Enhancements to increase the scalability of the=20 > Forwarding Database > of VPLS PE nodes. > > > > FB> I think we should make this text more generic: i.e. 7.=20 > Enhancements > to increase VPLS scalability. > > This will address any issues that might be raised in the=20 > future. In the > milestones we have anyhow two more generic=20 > items that are already > looking beyond what the current=20 > item 7 is covering: i.e. > > Nov 2009 Submit scalability solutions for VPLS=20 > Control-Plane to IESG > > Nov 2009 Submit scalability solutions for VPLS=20 > Data-Plane to IESG > > FB> >=20 > OK, but I think that may be a bit too generic. Can we=20 > instead scope it a little bit more as follows: > ---cut here--- > 7. Enhancements to increase the scalability of the VPLS=20 > Control Plane and Data Plane (e.g.: Forwarding Database) of=20 > VPLS PE nodes. > ---cut here--- >=20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Wed Apr 2 03:42:25 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BAD3A69D1; Wed, 2 Apr 2008 03:42:25 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6A13A69C8 for ; Wed, 2 Apr 2008 03:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.207 X-Spam-Level: *** X-Spam-Status: No, score=3.207 tagged_above=-999 required=5 tests=[AWL=2.097, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1FceuoO7k4z for ; Wed, 2 Apr 2008 03:42:23 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by core3.amsl.com (Postfix) with ESMTP id 93FD73A69AC for ; Wed, 2 Apr 2008 03:42:23 -0700 (PDT) Received: from mlsv12.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 10CC433CC9 for ; Wed, 2 Apr 2008 19:42:24 +0900 (JST) Received: from mfilter-s3.hitachi.co.jp by mlsv12.hitachi.co.jp (8.13.1/8.13.1) id m32AgNDB010708; Wed, 2 Apr 2008 19:42:24 +0900 Received: from vshuts3.hitachi.co.jp (unverified) by mfilter-s3.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 2 Apr 2008 19:42:23 +0900 Received: from vshuts3.hitachi.co.jp (unknown [127.0.0.1]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id AFCCF3925EA for ; Wed, 2 Apr 2008 19:42:23 +0900 (JST) X-AuditID: 0ac90648-ab975ba0000017b2-b6-47f3630ffb5b Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 8C6653925ED for ; Wed, 2 Apr 2008 19:42:23 +0900 (JST) Received: from P4090 by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id m32AgNC14717146; Wed, 2 Apr 2008 19:42:23 +0900 Message-ID: <012d01c894ae$683c45e0$2204d69e@P4090> From: "Masayuki Takase" To: References: <012501c894ad$e205c0a0$2204d69e@P4090> Subject: RE: Question on the status of Y.1711 and RFC3429 Date: Wed, 2 Apr 2008 19:43:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Loa, Hitachi has implemented Transport Switch chips that support MPLS OAM using the Label 14. Therefore we disagree to the modification of the existing RFC3429 document. So we also suggest using a different label for the new function. Regards, ----------------------------------- Masayuki Takase Hitachi, Communication Technologies, Ltd. 216 Totsuka-cho, Totsuka-ku, Yokohama-shi 244-8567, Japan Tel: +81-45-865-7003(Ext.4094) Email:masayuki.takase.vx@hitachi.com ----- Original Message ----- > Hi, > > Yes we have implemented the Label 14 in our packet processor/switch chips > as > requested by our customers. So we suggest using a different label for the > new function. > > > Regards, > > Shahram Davari | Director, Systems Engineering > T|PACK| 9 King's Inn Trail | Markham | Ontario L3T 1T6| Canada > Direct: +1 905 597 3125 | Mobile: +1 416 371 3139 | Email: > davari at tpack.com > www.tpack.com > > TPACK CONFIDENTIAL > Note: This message and any attachment hereto is intended solely for the > use > of the designated recipient(s) and their appointed delegates and may > contain > confidential information. Any unauthorized use, disclosure, copying, or > distribution of its contents is strictly prohibited. If you have received > this message in error, please destroy it and advise the sender immediately > by phone or email Thank you for your cooperation. > > > > > -----Original Message----- > From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On > Behalf Of > Loa Andersson > Sent: March-28-08 4:50 AM > To: mpls at ietf.org; pwe3; l3vpn at ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 > > All, > > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. > > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. > > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. > > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. > > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. > > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" > > ITU-T has sent out a question along the same lines, see the included > mail below. > > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. > > Loa and George > > > ------------------- included mail ------------------------------------ > > All users/implementers of recommendation Y.1711, > > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. > > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. > > This makes the OAM alert label directly visible at the > sink MEP. > > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. > > The OAM alert label will point to an ?opcode? at the bottom > of the stack. > ------------------------------------------ > > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. > > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? > > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). > > Please send me (or this list) your response ASAP. > > Kind regards, Huub van Helvoort, your rapporteur. > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson at acreo.se > loa at pi.se > > > From l2vpn-bounces@ietf.org Wed Apr 2 05:39:22 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D748928C2E4; Wed, 2 Apr 2008 05:39:22 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBC528C2E4 for ; Wed, 2 Apr 2008 05:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGgpEVA8BJeh for ; Wed, 2 Apr 2008 05:39:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A9EE728C231 for ; Wed, 2 Apr 2008 05:39:19 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2008 05:39:20 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m32CdK0I000808; Wed, 2 Apr 2008 05:39:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m32CdKss018160; Wed, 2 Apr 2008 12:39:20 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 05:39:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: VPLS OAM Date: Wed, 2 Apr 2008 05:39:19 -0700 Message-ID: <483F121CD2155B43B56DB71228DBAF15014D2778@xmb-sjc-239.amer.cisco.com> In-Reply-To: <47F2A983.1030008@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: VPLS OAM Thread-Index: AciUQBkr2Lw0bWAKQRaSd3HT9f9hTQAdt6Ww From: "Ali Sajassi (sajassi)" To: "Shane Amante" , X-OriginalArrivalTime: 02 Apr 2008 12:39:20.0123 (UTC) FILETIME=[926AD0B0:01C894BE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9999; t=1207139960; x=1208003960; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20 |Subject:=20RE=3A=20L2VPN=20(Re-)charter=3A=20VPLS=20OAM |Sender:=20; bh=zYoOdYzq1moVKKcMkBGw7hVEcoTrgMfR6MkIKBjAKqc=; b=JMWC1AJdmyoc1we9RfCA4DUehW2hcMCoYcW/usuF7DkS+tWFGuFsXKIxHk 2e+TphBaVcD84dwkLj5TXM66WJqisUKIx1XN/m4GKf/LQigYKz1ItZAKDWvi 4JHQTBcOb7UG3MrVfE+k2VFoMFo27+p4xTy7qDLww8j/6zZWXHfqA=; Authentication-Results: sj-dkim-1; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org =20 Shane, Please refer to my reply inline ... > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Tuesday, April 01, 2008 2:31 PM > To: l2vpn@ietf.org > Subject: L2VPN (Re-)charter: VPLS OAM >=20 > All, >=20 > Since there been a variety of comments about the re-charter,=20 > I'm going to attempt to group related comments and respond to=20 > them that way.=20 > Hopefully, this way people can follow along more easily. See=20 > below for the first response related to VPLS OAM. >=20 > ---snip--- >=20 > Dinesh, Ali, >=20 > ------Dinesh wrote------ > > "L2VPN's will make use of existing IETF specified=20 > mechanisms unless > there are technical reasons why the=20 > existing mechanisms are > insufficient or unnecessary." > > > > DM>> Which IETF mechanisms are we referring to? This=20 > statement seems > quite vague, can we offer some guidance=20 > around the relevance of this > statement. >=20 > Actually, this statement was copied from the PWE3 charter. =20 > The intent is to state that L2VPN WG will re-use MPLS (or=20 > L2TPv3) as defined by the MPLS WG for the PSN, PW's as=20 > defined by PWE3 for service-layer encapsulation, SNMP for=20 > MIB's, etc. See below for more. >=20 >=20 > > "In particular, the L2VPN WG will define extensions to=20 > Pseudowire > management (OAM) mechanisms, specifically=20 > Pseudowire Virtual Circuit > Connectivity Verification=20 > (VCCV), for VPLS. Those VCCV extensions ' > > will be reviewed by PWE3 to ensure they are inline with=20 > the overall > design/architecture of VCCV." > > > > DM>> Is it necessary to include this statement in the=20 > charter? This is > presuming solutions that may not have=20 > been completely hashed out yet. > > Isn't the first statement Sufficient in this para "The=20 > L2VPN WG will > provide extensions of existing protocols=20 > that will be discussed in > protocol-specific WG's." >=20 > You raise a fair point. I am willing to change the "will" to=20 > a "may" as suggested by Ali, (see below for that change). =20 > That leaves open the potential of us extending VCCV within=20 > this proposed charter, rather than having to come back and=20 > re-charter again or, worse, toss around multiple drafts in=20 > both PWE3 and L2VPN if we determine a need to extend VCCV.=20 > Plus, given all the recent work on T-MPLS and T-MPLS OAM, our=20 > AD's wanted to make it explicit that a portion of VCCV may be=20 > worked on within L2VPN, so people/other-SDO's know where to=20 > direct liaisons/questions/etc. >=20 >=20 > ------Ali wrote------ > > i) "L2VPN's will make use of existing IETF specified=20 > mechanisms unless > there are technical reasons why the=20 > existing mechanisms are > insufficient or unnecessary." > > > > AS> This statement needs further clarification. I would=20 > suggest the > following text: "L2VPN solutions will make use=20 > of existing IETF PWs > and PSN specified mechanisms for=20 > providing L2VPN services unless there > are technical=20 > reasons why the existing mechanisms are insufficient or >=20 > unnecessary. Furthermore, L2VPN solutions will make use of=20 > native > service mechanisms when applicable for providing=20 > L2VPN services - > e.g., use of Ethernet OAM for monitoring=20 > Ethernet native service. >=20 > First, the intent of the sentence /is not/ to create an=20 > exhaustive list of all protocols we may (or may not) end up=20 > (re-)using from other WG's, or other SDO's for that matter. =20 > Second, the last sentence you suggested appears to be saying=20 > that 802.1ag ("native service-layer mechansims") should be=20 > the only OAM tool for VPLS. I'm pretty confident we don't=20 > have WG consensus to make that statement in the charter,=20 > particularly given the "lively" debates that have ensued at=20 > WG meetings when discussing the two proposed OAM solutions. > Yes, because the intent is not to create and exhaustive list, I used "e.g.," rather than listing all the protocols. Also, my intention was not to say "that 802.1ag should be the only OAM tool for VPLS". So, you can change "will" to "should" in my second sentence. Basically, all I am saying is that if there is already a mechanism for a native service, then that mechanism should be considered first before attempting to re-invent the wheel.=20 =20 > However, to bring this back to the charter discussion, I=20 > believe the sentence is OK 'as-is', since it leaves room to=20 > discuss and make use of alternate mechanisms if "the existing=20 > mechansisms are insufficent or unnecessary". Specific to=20 > VPLS OAM, Dinesh has already been highlighting (in his=20 > presentations at the WG meetings) the areas where .1ag may=20 > provide a superior solution for *some* aspects of VPLS OAM. =20 > In addition, Olen's draft=20 > (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a=20 > more in-depth analysis. Unfortunately, the only debate on=20 > Olen's draft /on the mailing list/ has been about just one=20 > aspect of the draft, specifically the H-VPLS reference model,=20 > which has already been acknowledged as incorrect. We need to=20 > move on from that and look at the rest of Olen's draft to=20 > objectively determine what are the strengths & weaknesses of=20 > either or both (i.e. complementary) OAM approaches if we're=20 > going to make progress on OAM. >=20 If the intent of this statement is to say: "that L2VPN WG will re-use MPLS (or L2TPv3) as defined by the MPLS WG for the PSN, PW's as defined by PWE3 for service-layer encapsulation, SNMP for MIB's, etc." As you stated, then, it should be stated as such as the first sentence of my proposed text: "L2VPN solutions will make use of existing IETF PW and PSN specified mechanisms for providing L2VPN services unless there are technical reasons why the existing mechanisms are insufficient or unnecessary" My concern is that by having a vague sentence as such, then it makes it open to interpretation and some people may claim that VCCV-based OAM mechanism for VPLS (and Ethernet services) is the preferred mechanism over native Ethernet OAM (802.1ag/y.1731) because the charter has stated so !!=20 I think we need to select an OAM mechanism for VPLS based on its technical merit as we are progressing in this direction in the WG. So, the charter should state that VPLS OAM work is needed without intentionally/unintentionally favoring one mechanism over the other. =20 >=20 > > ii) "The L2VPN WG will provide extensions of existing=20 > protocols that > will be discussed in protocol-specific=20 > WG's. In particular, the L2VPN > WG will define extensions=20 > to pseudowire management (OAM) mechanisms, > specifically=20 > Pseudowire Virtual Circuit Connectivity Verification >=20 > (VCCV), for VPLS. Those VCCV extensions will be reviewed by=20 > PWE3 to > ensure they are inline with the overall=20 > design/architecture of VCCV." > > > > AS> This statement already assumes that VCCV extensions=20 > are needed for > VPLS which is not the case. I would prefer=20 > to either remove 2nd and > 3rd sentences from the above=20 > para. If we want to keep these sentences, > then we need to=20 > change "will" to "may" in 2nd sentence. >=20 > OK, I'll accept the change in your last sentence, (change=20 > from "will" to "may" in the second sentence). Specifically,=20 > I'll reword the charter as > follows: > ---snip--- > The L2VPN WG will provide extensions of existing protocols=20 > that will be discussed in protocol-specific WG's. In=20 > particular, the L2VPN WG may define extensions to pseudowire=20 > management (OAM) mechanisms, specifically Pseudowire Virtual=20 > Circuit Connectivity Verification (VCCV), for VPLS. Those=20 > VCCV extensions will be reviewed by PWE3 to ensure they are=20 > inline with the overall design/architecture of VCCV." > ---snip--- > O.K. Looks good. =20 >=20 >=20 > > iii) "Furthermore, the L2VPN WG will not define protocol=20 > inter-working > between a VPLS or VPWS and native=20 > service-layer control, OAM or > resiliency mechanisms, as=20 > those will be defined by the PWE3 WG. On > the other hand,=20 > the L2VPN WG will define how to operate native >=20 > service-layer control, OAM or resiliency mechanisms on top of=20 > a VPLS > or VPWS service." > > > > AS> This statement needs to be refined to indicate that=20 > the > interworking between the native service-layer and its=20 > associated PW > for the purpose of control, OAM, or=20 > resiliency mechanisms, shall be > defined by the PWE3 WG.=20 > However, the interworking between the native > service-layer=20 > and the VPN service, associated with a group of PWs and >=20 > their forwarding tables, will be defined by the L2VPN WG when needed. >=20 > I'm not sure I understand the intent or need for the last=20 > sentence you propose. Can you elaborate on it? =20 > Specifically, I'm trying to understand what might just be=20 > implementation details irrelevant to L2VPN, say specific to=20 > the Bridge Module and AC's, vs. some interaction between PW's=20 > and the Bridge Module or something else. >=20 An example of it would be the dual-homing and redundancy support between an 802.1ah access network and a VPLS core; where, 802.1ah access network is running L2GP protocol in order to avoid running its MSTP over VPLS core. In such scenario, upon a topology change, the 802.1ah access network would signal the PE using MVRP message to indicate the VLANs that are affected as the result of topology change and if LDP is used for C-MAC withdraw, then the PE needs to process the MVRP message and generate LDP MAC withdraw messages for the affected service instances. Cheers, Ali =20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Wed Apr 2 05:58:25 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB31028C4D9; Wed, 2 Apr 2008 05:58:25 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B649A28C4D5 for ; Wed, 2 Apr 2008 05:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyz6M5nlT5rn for ; Wed, 2 Apr 2008 05:58:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 258B528C4D9 for ; Wed, 2 Apr 2008 05:58:23 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2008 05:58:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m32CwNoP006893; Wed, 2 Apr 2008 05:58:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m32CwNpr026280; Wed, 2 Apr 2008 12:58:24 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 05:58:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: Scalability Enhancements Date: Wed, 2 Apr 2008 05:58:22 -0700 Message-ID: <483F121CD2155B43B56DB71228DBAF15014D277B@xmb-sjc-239.amer.cisco.com> In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191AA8@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: Scalability Enhancements Thread-Index: AciUUsofVVVY02+2Twe0VL+GLBDnrgAKw+pgABC1/DA= From: "Ali Sajassi (sajassi)" To: "BALUS Florin" , "Shane Amante" , X-OriginalArrivalTime: 02 Apr 2008 12:58:23.0745 (UTC) FILETIME=[3C11AF10:01C894C1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5215; t=1207141103; x=1208005103; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20 |Subject:=20RE=3A=20L2VPN=20(Re-)charter=3A=20Scalability=2 0Enhancements |Sender:=20; bh=MRAbakOzcL7pgeiPuV4Eu6nCueo2IymkRzayIejqJxM=; b=LUj+IqOhkNExXYA8DlrFq/lL7zy2En01F7e/B75lW33gJdOooEAM0sU64A s/EKddPrZbTxSW1R2+hpI+utbbToZ44ARE0qI3GHOo0gnUIj5fghcg4hw/7p MZK7UemSDg; Authentication-Results: sj-dkim-2; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, I am O.K. with the proposed text with a slight modification as suggested by Florin below. Cheers, Ali=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of BALUS Florin > Sent: Tuesday, April 01, 2008 10:06 PM > To: Shane Amante; l2vpn@ietf.org > Subject: RE: L2VPN (Re-)charter: Scalability Enhancements >=20 > Shane, > I am ok with your suggestions below. >=20 > I think the text you proposed (I.e. 7. Enhancements to=20 > increase the scalability of the VPLS Control Plane and Data=20 > Plane (e.g.: Forwarding > Database) of VPLS PE nodes.) addresses also the possibility=20 > to reduce the number of PWs which are part of the data plane.=20 > Maybe we can add in there the PWs to address Ali's=20 > suggestion: i.e. use "(e.g. MAC Forwarding Database, number=20 > of PWs)" instead of "(e.g. Forwarding Database)"? There are=20 > possibilities to provide reduction in the number of PWs by=20 > using a Backbone VPLS infrastructure to carry multiple customer VPNs. > Florin >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org=20 > [mailto:l2vpn-bounces@ietf.org] On Behalf=20 > > Of Shane Amante > > Sent: Tuesday, April 01, 2008 4:47 PM > > To: l2vpn@ietf.org > > Subject: L2VPN (Re-)charter: Scalability Enhancements > >=20 > > Hi Dinesh, Florin & Ali, > >=20 > > Please see below. > >=20 > > ------Dinesh wrote------ > > > DM>> We should enhance bullet 7 of scope which currently=20 > states "7. > > > Enhancements to increase the scalability of the=20 > Forwarding Database=20 > > of > VPLS PE nodes." to at least provide some example of current=20 > > direction, > similar to some other items in the list. As a=20 > suggestion=20 > > "7. > > > Enhancements to increase the scalability of the=20 > Forwarding Database=20 > > of > VPLS PE nodes. This may include using mechanisms=20 > being defined=20 > > by IEEE > e.g. 802.1ah." > >=20 > > First, we didn't want to list every possible protocol=20 > throughout the=20 > > charter that we may end up (re-)using. > > Second, 802.1ah (at the data > > plane) is only one direction we're currently headed, there's also=20 > > Control Plane optimizations as well. In order to=20 > "future-proof" the=20 > > charter, I would prefer that we didn't explicitly list 802.1ah. In=20 > > fact, I like Florin's suggestion that we abstract it further to=20 > > account for optimizations to not only the Data Plane, but=20 > also Control=20 > > Plane. > > Please see below for that. > >=20 > >=20 > > ------Ali wrote------ > > > vi) "7. Enhancements to increase the scalability of the=20 > Forwarding > > > Database of VPLS PE nodes." > > > > > > AS> I would prefer a more explicit language with respect=20 > > to > scalability such as "scalability of customer MAC=20 > > addresses and > number of PW" > >=20 > > Since this is the "scope" section, how about we keep it=20 > > slightly more generic than what you suggest? Specifically,=20 > > what do you think about the language I suggest below in=20 > > response to Florin? I think it should address your concern here. > >=20 > >=20 > > > vii) "- Define enhancements to increase scalability of=20 > > VPLS PE nodes, > > > to provide aggregation of learned customer MAC=20 > addresses at > > > VPLS PE's." > > > > > > AS> should be changed to " Define enhancements to increase=20 > > scalability > of VPLS PE nodes, to provide aggregation of=20 > > learned customer MAC > addresses and to reduce number of PWs=20 > > at VPLS PE's." > >=20 > > What is your definition of, or goal of, "reduce number of=20 > > PW's at VPLS PE's"? The number of PWE3 VC labels, the number=20 > > of tLDP sessions, the number of signaling messages exchanged=20 > > over a set of tLDP sessions or something else? We possibly=20 > > need something wrt the benefit we're looking to acheive at=20 > > the Control Plane, but we probably want to be more precise. =20 > > With that in mind, can you suggest some more crisp text? > >=20 > >=20 > >=20 > > ------Florin wrote------ > > > 7. Enhancements to increase the scalability of the=20 > > Forwarding Database > of VPLS PE nodes. > > > > > > FB> I think we should make this text more generic: i.e. 7.=20 > > Enhancements > to increase VPLS scalability. > > > This will address any issues that might be raised in the=20 > > future. In the > milestones we have anyhow two more generic=20 > > items that are already > looking beyond what the current=20 > > item 7 is covering: i.e. > > > Nov 2009 Submit scalability solutions for VPLS=20 > > Control-Plane to IESG > > > Nov 2009 Submit scalability solutions for VPLS=20 > > Data-Plane to IESG > > > FB> > >=20 > > OK, but I think that may be a bit too generic. Can we=20 > > instead scope it a little bit more as follows: > > ---cut here--- > > 7. Enhancements to increase the scalability of the VPLS=20 > > Control Plane and Data Plane (e.g.: Forwarding Database) of=20 > > VPLS PE nodes. > > ---cut here--- > >=20 > > Thanks, > >=20 > > -shane > >=20 >=20 From l2vpn-bounces@ietf.org Wed Apr 2 06:53:29 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AFB3A6F0E; Wed, 2 Apr 2008 06:53:29 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4E33A6B28 for ; Wed, 2 Apr 2008 06:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.152 X-Spam-Level: * X-Spam-Status: No, score=1.152 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqx0EM7-PsN7 for ; Wed, 2 Apr 2008 06:53:20 -0700 (PDT) Received: from lucidvision.com (static-72-71-250-34.cncdnh.fios.verizon.net [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id C5A7528C572 for ; Wed, 2 Apr 2008 06:53:14 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id DEAC92C89E5; Wed, 2 Apr 2008 06:53:15 -0700 (PDT) Message-Id: From: Thomas Nadeau To: "Ali Sajassi (sajassi)" In-Reply-To: <483F121CD2155B43B56DB71228DBAF15014D2778@xmb-sjc-239.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN (Re-)charter: VPLS OAM Date: Wed, 2 Apr 2008 09:53:09 -0400 References: <483F121CD2155B43B56DB71228DBAF15014D2778@xmb-sjc-239.amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org, Shane Amante X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org On Apr 2, 2008, at 8:39 AM, Ali Sajassi (sajassi) wrote: > > Shane, > > Please refer to my reply inline ... > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Shane Amante >> Sent: Tuesday, April 01, 2008 2:31 PM >> To: l2vpn@ietf.org >> Subject: L2VPN (Re-)charter: VPLS OAM >> >> All, >> >> Since there been a variety of comments about the re-charter, >> I'm going to attempt to group related comments and respond to >> them that way. >> Hopefully, this way people can follow along more easily. See >> below for the first response related to VPLS OAM. >> >> ---snip--- >> >> Dinesh, Ali, >> >> ------Dinesh wrote------ >>> "L2VPN's will make use of existing IETF specified >> mechanisms unless > there are technical reasons why the >> existing mechanisms are > insufficient or unnecessary." >>> >>> DM>> Which IETF mechanisms are we referring to? This >> statement seems > quite vague, can we offer some guidance >> around the relevance of this > statement. >> >> Actually, this statement was copied from the PWE3 charter. >> The intent is to state that L2VPN WG will re-use MPLS (or >> L2TPv3) as defined by the MPLS WG for the PSN, PW's as >> defined by PWE3 for service-layer encapsulation, SNMP for >> MIB's, etc. See below for more. >> >> >>> "In particular, the L2VPN WG will define extensions to >> Pseudowire > management (OAM) mechanisms, specifically >> Pseudowire Virtual Circuit > Connectivity Verification >> (VCCV), for VPLS. Those VCCV extensions ' >>> will be reviewed by PWE3 to ensure they are inline with >> the overall > design/architecture of VCCV." >>> >>> DM>> Is it necessary to include this statement in the >> charter? This is > presuming solutions that may not have >> been completely hashed out yet. >>> Isn't the first statement Sufficient in this para "The >> L2VPN WG will > provide extensions of existing protocols >> that will be discussed in > protocol-specific WG's." >> >> You raise a fair point. I am willing to change the "will" to >> a "may" as suggested by Ali, (see below for that change). >> That leaves open the potential of us extending VCCV within >> this proposed charter, rather than having to come back and >> re-charter again or, worse, toss around multiple drafts in >> both PWE3 and L2VPN if we determine a need to extend VCCV. >> Plus, given all the recent work on T-MPLS and T-MPLS OAM, our >> AD's wanted to make it explicit that a portion of VCCV may be >> worked on within L2VPN, so people/other-SDO's know where to >> direct liaisons/questions/etc. >> >> >> ------Ali wrote------ >>> i) "L2VPN's will make use of existing IETF specified >> mechanisms unless > there are technical reasons why the >> existing mechanisms are > insufficient or unnecessary." >>> >>> AS> This statement needs further clarification. I would >> suggest the > following text: "L2VPN solutions will make use >> of existing IETF PWs > and PSN specified mechanisms for >> providing L2VPN services unless there > are technical >> reasons why the existing mechanisms are insufficient or > >> unnecessary. Furthermore, L2VPN solutions will make use of >> native > service mechanisms when applicable for providing >> L2VPN services - > e.g., use of Ethernet OAM for monitoring >> Ethernet native service. >> >> First, the intent of the sentence /is not/ to create an >> exhaustive list of all protocols we may (or may not) end up >> (re-)using from other WG's, or other SDO's for that matter. >> Second, the last sentence you suggested appears to be saying >> that 802.1ag ("native service-layer mechansims") should be >> the only OAM tool for VPLS. I'm pretty confident we don't >> have WG consensus to make that statement in the charter, >> particularly given the "lively" debates that have ensued at >> WG meetings when discussing the two proposed OAM solutions. >> > > Yes, because the intent is not to create and exhaustive list, I used > "e.g.," rather than listing all the protocols. Also, my intention was > not to say "that 802.1ag should be the only OAM tool for VPLS". So, > you > can change "will" to "should" in my second sentence. Basically, all > I am > saying is that if there is already a mechanism for a native service, > then that mechanism should be considered first before attempting to > re-invent the wheel. > >> However, to bring this back to the charter discussion, I >> believe the sentence is OK 'as-is', since it leaves room to >> discuss and make use of alternate mechanisms if "the existing >> mechansisms are insufficent or unnecessary". Specific to >> VPLS OAM, Dinesh has already been highlighting (in his >> presentations at the WG meetings) the areas where .1ag may >> provide a superior solution for *some* aspects of VPLS OAM. >> In addition, Olen's draft >> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a >> more in-depth analysis. Unfortunately, the only debate on >> Olen's draft /on the mailing list/ has been about just one >> aspect of the draft, specifically the H-VPLS reference model, >> which has already been acknowledged as incorrect. We need to >> move on from that and look at the rest of Olen's draft to >> objectively determine what are the strengths & weaknesses of >> either or both (i.e. complementary) OAM approaches if we're >> going to make progress on OAM. >> > > If the intent of this statement is to say: > "that L2VPN WG will re-use MPLS (or L2TPv3) as defined by the MPLS WG > for the PSN, PW's as defined by PWE3 for service-layer encapsulation, > SNMP for MIB's, etc." > As you stated, then, it should be stated as such as the first sentence > of my proposed text: > "L2VPN solutions will make use of existing IETF PW and PSN specified > mechanisms for providing L2VPN services unless there are technical > reasons why the existing mechanisms are insufficient or unnecessary" > My concern is that by having a vague sentence as such, then it makes > it > open to interpretation and some people may claim that VCCV-based OAM > mechanism for VPLS (and Ethernet services) is the preferred mechanism > over native Ethernet OAM (802.1ag/y.1731) because the charter has > stated > so !! > I think we need to select an OAM mechanism for VPLS based on its > technical merit as we are progressing in this direction in the WG. So, > the charter should state that VPLS OAM work is needed without > intentionally/unintentionally favoring one mechanism over the other. I would agree with Ali here, although I do agree with the text stating that we will reuse existing IEEE, MPLS and PWE3 mechanisms where we can. --Tom >>> >>> ii) "The L2VPN WG will provide extensions of existing >> protocols that > will be discussed in protocol-specific >> WG's. In particular, the L2VPN > WG will define extensions >> to pseudowire management (OAM) mechanisms, > specifically >> Pseudowire Virtual Circuit Connectivity Verification > >> (VCCV), for VPLS. Those VCCV extensions will be reviewed by >> PWE3 to > ensure they are inline with the overall >> design/architecture of VCCV." >>> >>> AS> This statement already assumes that VCCV extensions >> are needed for > VPLS which is not the case. I would prefer >> to either remove 2nd and > 3rd sentences from the above >> para. If we want to keep these sentences, > then we need to >> change "will" to "may" in 2nd sentence. >> >> OK, I'll accept the change in your last sentence, (change >> from "will" to "may" in the second sentence). Specifically, >> I'll reword the charter as >> follows: >> ---snip--- >> The L2VPN WG will provide extensions of existing protocols >> that will be discussed in protocol-specific WG's. In >> particular, the L2VPN WG may define extensions to pseudowire >> management (OAM) mechanisms, specifically Pseudowire Virtual >> Circuit Connectivity Verification (VCCV), for VPLS. Those >> VCCV extensions will be reviewed by PWE3 to ensure they are >> inline with the overall design/architecture of VCCV." >> ---snip--- >> > > O.K. Looks good. > >> >> >>> iii) "Furthermore, the L2VPN WG will not define protocol >> inter-working > between a VPLS or VPWS and native >> service-layer control, OAM or > resiliency mechanisms, as >> those will be defined by the PWE3 WG. On > the other hand, >> the L2VPN WG will define how to operate native > >> service-layer control, OAM or resiliency mechanisms on top of >> a VPLS > or VPWS service." >>> >>> AS> This statement needs to be refined to indicate that >> the > interworking between the native service-layer and its >> associated PW > for the purpose of control, OAM, or >> resiliency mechanisms, shall be > defined by the PWE3 WG. >> However, the interworking between the native > service-layer >> and the VPN service, associated with a group of PWs and > >> their forwarding tables, will be defined by the L2VPN WG when needed. >> >> I'm not sure I understand the intent or need for the last >> sentence you propose. Can you elaborate on it? >> Specifically, I'm trying to understand what might just be >> implementation details irrelevant to L2VPN, say specific to >> the Bridge Module and AC's, vs. some interaction between PW's >> and the Bridge Module or something else. >> > > An example of it would be the dual-homing and redundancy support > between > an 802.1ah access network and a VPLS core; where, 802.1ah access > network > is running L2GP protocol in order to avoid running its MSTP over VPLS > core. In such scenario, upon a topology change, the 802.1ah access > network would signal the PE using MVRP message to indicate the VLANs > that are affected as the result of topology change and if LDP is used > for C-MAC withdraw, then the PE needs to process the MVRP message and > generate LDP MAC withdraw messages for the affected service instances. > > Cheers, > Ali > > >> Thanks, >> >> -shane >> > From l2vpn-bounces@ietf.org Wed Apr 2 07:00:43 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B963A6A61; Wed, 2 Apr 2008 07:00:43 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD0A3A6914 for ; Wed, 2 Apr 2008 07:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyd+nKvDyU7R for ; Wed, 2 Apr 2008 07:00:37 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 16DD53A67D0 for ; Wed, 2 Apr 2008 07:00:37 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 1C9832680CE; Wed, 2 Apr 2008 08:00:38 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 02 Apr 2008 08:00:38 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=44311; data-bytes=0 Message-ID: <47F39185.6010407@castlepoint.net> Date: Wed, 02 Apr 2008 08:00:37 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Frederic, Florin, Dinesh & Ali, ------Frederic wrote------ > Just a comment related to multicast: > In the goals and milestones sections, you are referring to VPMS (Virtual > Private Multicast Servcice), I would suggest to introduce this service in > the charter itself as a new L2VPN to be added to the 3 existing VPLS, VPWS > and IPLS. > > Virtual Private Multicast Service (VPMS) -- A Layer 2 service that > Provides point-to-multipoint connectivity for a variety of link layers, > including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or > MPLS-enabled IP PSN. > > VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the > PWE3 WG. Good point. I'll add the last two paragraphs you've suggested to the charter. And, see below for the contingency on PWE3 successfully chartering P2MP PW's, in order for L2VPN to be able to work on this. ------Dinesh wrote------ > "Nov 2009 Submit Auto-Discovery solution for VPMS to IESG" > DM>> VPMS?? Possibly a typo :-) No, it's not a typo. See above for a more detailed explanation of a new work item (recently) proposed by Frederic, Phillipe & Rahul. ------Florin wrote------ > Mar 2009 Submit I-D on Virtual Private Multicast Service > (VPMS)requirements to IESG > [..] > Nov 2009 Submit Auto-Discovery solution for VPMS to IESG > > FB> (this comment applies to the 2 previous items) Not sure I understand > what are we trying to achieve here? We stated in item 5 of the charter > that L2 VPN WG is going to deal with "5. Mechanisms to permit > optimization of multicast data traffic within a VPLS or VPWS VPN over an > IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it similar with > P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on this just in > case we are dealing with a VPN like collection of PWs. Otherwise we > should probably address this in PWE3/MPLS to start with. > FB> Thanks for pointing this out. To be clear, the L2VPN WG is dependent on the /successful/ chartering of P2MP PW's within the PWE3 WG -- which hasn't happened, yet. Assuming the PWE3 WG does charter P2MP PW's, the way the VPMS work would be split between the PWE3 WG and the L2VPN WG is as follows: 1) Requirements for a unidirectional P2MP PW will be in PWE3; 2) P2MP PW encapsulation solution(s) will be in PWE3; 3) Requirements for a VPMS "service", (Virtual Private P2MP unidirectional service), will be put forth in the the L2VPN WG; 4) BGP Auto-Discovery procedures for VPMS will also be put in L2VPN. In terms of existing drafts that would mean: - draft-raggarwa-l2vpn-p2mp-pw-00: would get split into two drafts. The first draft would define a P2MP PW (#2) and be within the scope of PWE3. The second draft would define BGP Auto-Discovery procedures for VPMS (#4) and be within the L2VPN WG. - draft-jounay-pwe3-p2mp-pw-requirements-01 would be in PWE3 and cover #1. - A new, yet unwritten draft would have to be put forth to cover #3, (or, perhaps, combined with #4). -----Ali wrote----- > iv) "5. Mechanisms to permit optimization of multicast data traffic > within a VPLS or VPWS VPN over an IP/MPLS PSN." > > AS> mcast optimization should only be for VPLS based on VPWS service > definition. So, are you saying you share the same concern as Florin that we need to 'wait to see' if the PWE3 WG will add P2MP PW's to their charter? I've pinged Danny & Stewart to see if they can send out the new PWE3 charter soon, in order that we're not 'waiting to see' if PWE3 WG will or will not take on P2MP PW's. Thanks, -shane From l2vpn-bounces@ietf.org Wed Apr 2 07:02:39 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA3D28C1C9; Wed, 2 Apr 2008 07:02:39 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32D828C218 for ; Wed, 2 Apr 2008 07:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2nytxhmeHDD for ; Wed, 2 Apr 2008 07:02:37 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A85F728C1C9 for ; Wed, 2 Apr 2008 07:02:37 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BAFD92680CE; Wed, 2 Apr 2008 08:02:38 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 02 Apr 2008 08:02:38 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=42820; data-bytes=0 Message-ID: <47F391FE.6040804@castlepoint.net> Date: Wed, 02 Apr 2008 08:02:38 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: L2VPN (Re-)charter: Service Convergence Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Loa, Florin, Ali, ------Loa wrote------ > - I'm a bit uncertain about whether there are one or two multi-homing > scenarios in the text > -- VPLS using multi-homed CEs > -- multi-homed VPLS solutions See Florin's suggested text below. I think Florin is suggesting to clarify that we need both, (if I interpret your 2nd bullet correctly). ------Florin wrote------ > The L2VPN WG scope includes the following: > [..] > 6. Improved service convergence for multi-homed CE's to VPLS PE's. > Specifically, upon failure of a primary path from a CE to VPLS PE, > initiate a rapid switch-over to an alternate path. If required, > interactions with native service-layer resiliency mechanisms will be > provided via solutions from other IETF WG's such as PWE3. > > FB> Suggest we modify the text to include also multi-homing between 2 > VPLS domains, see below an example of text: > 6. Improved service convergence for multi-homing solutions: CEs to VPLS > PEs or between VPLS domains. Can you clarify this further? Specifically, do you mean the following two cases: a) One CE to two different VPLS PE's in a single AS; and, b) One CE to two different VPLS PE's, each in a different AS? Also, correct me if I'm wrong, but PWE3 has already covered multi-homing of a MTU-s to two, different PE-rs'es in draft-muley-pwe3-redundancy-02? Or, is there addt'l work that L2VPN WG needs to take care of specifically for that case? > Specifically, upon failure of a primary > path from a between CEs and VPLS PEs or between VPLS domains, initiate a > rapid switch-over to an alternate path. If required, interactions with > native service-layer resiliency mechanisms will be provided via > solutions from other IETF WG's such as PWE3. > FB> > > > The L2VPN WG currently works on the following tasks: > [..] > - Identify requirements for multi-homing of CE's to VPLS PE's. > elements. Based on these requirements, define solutions for > achieving fast convergence after a switchover to an alternate path, > for example through optimized MAC flushing within a VPLS domain. > > FB> Suggest changing this one to the following text: > - Identify requirements for different multi-homing solutions: i.e. CEs > to VPLS Pes or between VPLS domains. Based on these requirements, define > solutions for achieving fast convergence after a switchover to an > alternate path, for example through optimized MAC flushing within a VPLS > domain. > FB> I have the same question here as I do above. Once we're on the same page, then I think we can tighten the suggested text a little further. ------Ali wrote------ > v) "6. Improved service convergence for multi-homed CE's to VPLS PE's. > Specifically, upon failure of a primary path from a CE to VPLS PE, > initiate a rapid switch-over to an alternate path. If required, > interactions with native service-layer resiliency mechanisms will be > provided via solutions from other IETF WG's such as PWE3." > > AS> We should create another bullet to include multi-homing between two > or more VPLS networks. Ali: I think you're asking for the same thing as Florin, (see above). If not, please clarify further. Thanks, -shane From l2vpn-bounces@ietf.org Wed Apr 2 08:41:08 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830F83A69C8; Wed, 2 Apr 2008 08:41:08 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48ED3A69C8 for ; Wed, 2 Apr 2008 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBpSfXLi2nJI for ; Wed, 2 Apr 2008 08:41:06 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 3940B3A680E for ; Wed, 2 Apr 2008 08:41:05 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m32Ff0BP014124; Wed, 2 Apr 2008 09:41:00 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 10:40:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: VPLS OAM Date: Wed, 2 Apr 2008 10:40:46 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191B56@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: VPLS OAM Thread-Index: AciUyRAeAq68IbHQRgeba6NTvjvLgQADAUtQ From: "BALUS Florin" To: "Thomas Nadeau" , "Ali Sajassi \(sajassi\)" X-OriginalArrivalTime: 02 Apr 2008 15:40:59.0677 (UTC) FILETIME=[F30EC4D0:01C894D7] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: l2vpn@ietf.org, Shane Amante X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org I think the important aspect that Shane is trying to capture in the L2VPN charter is that our focus is to address required extensions to the mechanisms specific to the PSNs (IP/MPLS) and PWE3 infrastructure that is common to both VPLS and VPWS. I do not think we should try to step over other people's toes and work on extending the protocols developed by other organizations (e.g. IEEE) to address needs specific to our PSNs or PWE3 infrastructure.=20 We can write specifications showing applicability of native mechanisms to our services but if changes are required to these protocols and our existing L2VPN mechanisms can't do it then it should be the task of the originating organizations to step in and change their protocols. As much as we do not want people from other organizations stepping in to tell us what to do with PWE3/MPLS OAM, I do not think we should try to do IEEE job.=20 We can write informational RFCs showing how we can re-use the IEEE stuff and then push the required protocol work to them. We do not have anyhow processes aligned to their style of work/document structure to be able to produce extensions consistent with their models. > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Thomas Nadeau > Sent: Wednesday, April 02, 2008 6:53 AM > To: Ali Sajassi (sajassi) > Cc: l2vpn@ietf.org; Shane Amante > Subject: Re: L2VPN (Re-)charter: VPLS OAM >=20 >=20 > On Apr 2, 2008, at 8:39 AM, Ali Sajassi (sajassi) wrote: > > > > Shane, > > > > Please refer to my reply inline ... > > > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 > >> Behalf Of Shane Amante > >> Sent: Tuesday, April 01, 2008 2:31 PM > >> To: l2vpn@ietf.org > >> Subject: L2VPN (Re-)charter: VPLS OAM > >> > >> All, > >> > >> Since there been a variety of comments about the re-charter, I'm=20 > >> going to attempt to group related comments and respond to=20 > them that=20 > >> way. > >> Hopefully, this way people can follow along more easily. =20 > See below=20 > >> for the first response related to VPLS OAM. > >> > >> ---snip--- > >> > >> Dinesh, Ali, > >> > >> ------Dinesh wrote------ > >>> "L2VPN's will make use of existing IETF specified > >> mechanisms unless > there are technical reasons why the existing=20 > >> mechanisms are > insufficient or unnecessary." > >>> > >>> DM>> Which IETF mechanisms are we referring to? This > >> statement seems > quite vague, can we offer some guidance=20 > around the=20 > >> relevance of this > statement. > >> > >> Actually, this statement was copied from the PWE3 charter. > >> The intent is to state that L2VPN WG will re-use MPLS (or > >> L2TPv3) as defined by the MPLS WG for the PSN, PW's as defined by=20 > >> PWE3 for service-layer encapsulation, SNMP for MIB's, etc.=20 > See below=20 > >> for more. > >> > >> > >>> "In particular, the L2VPN WG will define extensions to > >> Pseudowire > management (OAM) mechanisms, specifically Pseudowire=20 > >> Virtual Circuit > Connectivity Verification (VCCV), for=20 > VPLS. Those=20 > >> VCCV extensions ' > >>> will be reviewed by PWE3 to ensure they are inline with > >> the overall > design/architecture of VCCV." > >>> > >>> DM>> Is it necessary to include this statement in the > >> charter? This is > presuming solutions that may not have been=20 > >> completely hashed out yet. > >>> Isn't the first statement Sufficient in this para "The > >> L2VPN WG will > provide extensions of existing protocols=20 > that will=20 > >> be discussed in > protocol-specific WG's." > >> > >> You raise a fair point. I am willing to change the "will"=20 > to a "may"=20 > >> as suggested by Ali, (see below for that change). > >> That leaves open the potential of us extending VCCV within this=20 > >> proposed charter, rather than having to come back and re-charter=20 > >> again or, worse, toss around multiple drafts in both PWE3=20 > and L2VPN=20 > >> if we determine a need to extend VCCV. > >> Plus, given all the recent work on T-MPLS and T-MPLS OAM, our AD's=20 > >> wanted to make it explicit that a portion of VCCV may be worked on=20 > >> within L2VPN, so people/other-SDO's know where to direct=20 > >> liaisons/questions/etc. > >> > >> > >> ------Ali wrote------ > >>> i) "L2VPN's will make use of existing IETF specified > >> mechanisms unless > there are technical reasons why the existing=20 > >> mechanisms are > insufficient or unnecessary." > >>> > >>> AS> This statement needs further clarification. I would > >> suggest the > following text: "L2VPN solutions will make use of=20 > >> existing IETF PWs > and PSN specified mechanisms for=20 > providing L2VPN=20 > >> services unless there > are technical reasons why the existing=20 > >> mechanisms are insufficient or > unnecessary. Furthermore, L2VPN=20 > >> solutions will make use of native > service mechanisms when=20 > >> applicable for providing L2VPN services - > e.g., use of Ethernet=20 > >> OAM for monitoring Ethernet native service. > >> > >> First, the intent of the sentence /is not/ to create an exhaustive=20 > >> list of all protocols we may (or may not) end up (re-)using from=20 > >> other WG's, or other SDO's for that matter. > >> Second, the last sentence you suggested appears to be saying that=20 > >> 802.1ag ("native service-layer mechansims") should be the only OAM=20 > >> tool for VPLS. I'm pretty confident we don't have WG consensus to=20 > >> make that statement in the charter, particularly given the=20 > "lively"=20 > >> debates that have ensued at WG meetings when discussing the two=20 > >> proposed OAM solutions. > >> > > > > Yes, because the intent is not to create and exhaustive=20 > list, I used=20 > > "e.g.," rather than listing all the protocols. Also, my=20 > intention was=20 > > not to say "that 802.1ag should be the only OAM tool for VPLS". So,=20 > > you can change "will" to "should" in my second sentence. Basically,=20 > > all I am saying is that if there is already a mechanism for=20 > a native=20 > > service, then that mechanism should be considered first before=20 > > attempting to re-invent the wheel. > > > >> However, to bring this back to the charter discussion, I=20 > believe the=20 > >> sentence is OK 'as-is', since it leaves room to discuss=20 > and make use=20 > >> of alternate mechanisms if "the existing mechansisms are=20 > insufficent=20 > >> or unnecessary". Specific to VPLS OAM, Dinesh has already been=20 > >> highlighting (in his presentations at the WG meetings) the areas=20 > >> where .1ag may provide a superior solution for *some*=20 > aspects of VPLS=20 > >> OAM. > >> In addition, Olen's draft > >> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a more=20 > >> in-depth analysis. Unfortunately, the only debate on Olen's draft=20 > >> /on the mailing list/ has been about just one aspect of the draft,=20 > >> specifically the H-VPLS reference model, which has already been=20 > >> acknowledged as incorrect. We need to move on from that=20 > and look at=20 > >> the rest of Olen's draft to objectively determine what are the=20 > >> strengths & weaknesses of either or both (i.e. complementary) OAM=20 > >> approaches if we're going to make progress on OAM. > >> > > > > If the intent of this statement is to say: > > "that L2VPN WG will re-use MPLS (or L2TPv3) as defined by=20 > the MPLS WG=20 > > for the PSN, PW's as defined by PWE3 for service-layer=20 > encapsulation,=20 > > SNMP for MIB's, etc." > > As you stated, then, it should be stated as such as the=20 > first sentence=20 > > of my proposed text: > > "L2VPN solutions will make use of existing IETF PW and PSN=20 > specified=20 > > mechanisms for providing L2VPN services unless there are technical=20 > > reasons why the existing mechanisms are insufficient or unnecessary" > > My concern is that by having a vague sentence as such, then=20 > it makes=20 > > it open to interpretation and some people may claim that VCCV-based=20 > > OAM mechanism for VPLS (and Ethernet services) is the preferred=20 > > mechanism over native Ethernet OAM (802.1ag/y.1731) because the=20 > > charter has stated so !! > > I think we need to select an OAM mechanism for VPLS based on its=20 > > technical merit as we are progressing in this direction in=20 > the WG. So,=20 > > the charter should state that VPLS OAM work is needed without=20 > > intentionally/unintentionally favoring one mechanism over the other. >=20 > I would agree with Ali here, although I do agree with=20 > the text stating that we will reuse existing IEEE, MPLS and=20 > PWE3 mechanisms where we can. >=20 > --Tom >=20 >=20 > >>> > >>> ii) "The L2VPN WG will provide extensions of existing > >> protocols that > will be discussed in protocol-specific WG's. In=20 > >> particular, the L2VPN > WG will define extensions to pseudowire=20 > >> management (OAM) mechanisms, > specifically Pseudowire Virtual=20 > >> Circuit Connectivity Verification > (VCCV), for VPLS. Those VCCV=20 > >> extensions will be reviewed by > >> PWE3 to > ensure they are inline with the overall=20 > >> design/architecture of VCCV." > >>> > >>> AS> This statement already assumes that VCCV extensions > >> are needed for > VPLS which is not the case. I would prefer to=20 > >> either remove 2nd and > 3rd sentences from the above para. If we=20 > >> want to keep these sentences, > then we need to change "will" to=20 > >> "may" in 2nd sentence. > >> > >> OK, I'll accept the change in your last sentence, (change=20 > from "will"=20 > >> to "may" in the second sentence). Specifically, I'll reword the=20 > >> charter as > >> follows: > >> ---snip--- > >> The L2VPN WG will provide extensions of existing protocols=20 > that will=20 > >> be discussed in protocol-specific WG's. In particular,=20 > the L2VPN WG=20 > >> may define extensions to pseudowire management (OAM) mechanisms,=20 > >> specifically Pseudowire Virtual Circuit Connectivity Verification=20 > >> (VCCV), for VPLS. Those VCCV extensions will be reviewed=20 > by PWE3 to=20 > >> ensure they are inline with the overall=20 > design/architecture of VCCV." > >> ---snip--- > >> > > > > O.K. Looks good. > > > >> > >> > >>> iii) "Furthermore, the L2VPN WG will not define protocol > >> inter-working > between a VPLS or VPWS and native service-layer=20 > >> control, OAM or > resiliency mechanisms, as those will be=20 > defined by=20 > >> the PWE3 WG. On > the other hand, the L2VPN WG will=20 > define how to=20 > >> operate native > service-layer control, OAM or resiliency=20 > mechanisms=20 > >> on top of a VPLS > or VPWS service." > >>> > >>> AS> This statement needs to be refined to indicate that > >> the > interworking between the native service-layer and its=20 > >> associated PW > for the purpose of control, OAM, or resiliency=20 > >> mechanisms, shall be > defined by the PWE3 WG. > >> However, the interworking between the native >=20 > service-layer and the=20 > >> VPN service, associated with a group of PWs and > their=20 > forwarding=20 > >> tables, will be defined by the L2VPN WG when needed. > >> > >> I'm not sure I understand the intent or need for the last sentence=20 > >> you propose. Can you elaborate on it? > >> Specifically, I'm trying to understand what might just be=20 > >> implementation details irrelevant to L2VPN, say specific to the=20 > >> Bridge Module and AC's, vs. some interaction between PW's and the=20 > >> Bridge Module or something else. > >> > > > > An example of it would be the dual-homing and redundancy support=20 > > between an 802.1ah access network and a VPLS core; where, 802.1ah=20 > > access network is running L2GP protocol in order to avoid=20 > running its=20 > > MSTP over VPLS core. In such scenario, upon a topology change, the=20 > > 802.1ah access network would signal the PE using MVRP message to=20 > > indicate the VLANs that are affected as the result of=20 > topology change=20 > > and if LDP is used for C-MAC withdraw, then the PE needs to process=20 > > the MVRP message and generate LDP MAC withdraw messages for the=20 > > affected service instances. > > > > Cheers, > > Ali > > > > > >> Thanks, > >> > >> -shane > >> > > >=20 >=20 From l2vpn-bounces@ietf.org Wed Apr 2 09:01:26 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D4D28C47C; Wed, 2 Apr 2008 09:01:26 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB963A6EE8 for ; Wed, 2 Apr 2008 09:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzGK-KUSMNXc for ; Wed, 2 Apr 2008 09:01:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 06E523A6D66 for ; Wed, 2 Apr 2008 09:00:24 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2008 09:00:25 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m32G0PEn003249; Wed, 2 Apr 2008 09:00:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m32G0Jke000907; Wed, 2 Apr 2008 16:00:25 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 09:00:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: VPLS OAM Date: Wed, 2 Apr 2008 09:00:21 -0700 Message-ID: <483F121CD2155B43B56DB71228DBAF15014D27E2@xmb-sjc-239.amer.cisco.com> In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191B56@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: VPLS OAM Thread-Index: AciUyRAeAq68IbHQRgeba6NTvjvLgQADAUtQAADI4oA= From: "Ali Sajassi (sajassi)" To: "BALUS Florin" , "Thomas Nadeau" X-OriginalArrivalTime: 02 Apr 2008 16:00:22.0837 (UTC) FILETIME=[A85AE650:01C894DA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14374; t=1207152025; x=1208016025; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20 |Subject:=20RE=3A=20L2VPN=20(Re-)charter=3A=20VPLS=20OAM |Sender:=20; bh=OMbMqnNhEtCH7FTlCGbSf5i5dPF6DbQV6lMJ+kOXEDM=; b=O/laFIi3M2Sm6boJWLm5l8gjLUJq4rrUYLIQuBO/1sJMlj9qcobL+mxCw4 JqkYPE5pi5D4Rwnt4vVqrylhUFWE9JSUShnsSw/Qs+psBAjeKMhlslpYV/W4 YtOwohjuYc; Authentication-Results: sj-dkim-4; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: l2vpn@ietf.org, Shane Amante X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org =20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of BALUS Florin > Sent: Wednesday, April 02, 2008 8:41 AM > To: Thomas Nadeau; Ali Sajassi (sajassi) > Cc: l2vpn@ietf.org; Shane Amante > Subject: RE: L2VPN (Re-)charter: VPLS OAM >=20 >=20 > I think the important aspect that Shane is trying to capture=20 > in the L2VPN charter is that our focus is to address required=20 > extensions to the mechanisms specific to the PSNs (IP/MPLS)=20 > and PWE3 infrastructure that is common to both VPLS and VPWS. So, we should capture it as such as I suggested rather and avoid having a vague statement. >=20 > I do not think we should try to step over other people's toes=20 > and work on extending the protocols developed by other=20 > organizations (e.g. IEEE) to address needs specific to our=20 > PSNs or PWE3 infrastructure.=20 >=20 No body is suggesting that !! specially with respect to PSN and PWs infrastructure. The point that I made was that when it comes to support of native services (e.g., Ethernet in case of VPLS), we should see what is out there and leveraging existing mechanism rather than trying to reinvent the wheel. The comment was made specifically wrt VPLS OAM.=20 > We can write specifications showing applicability of native=20 > mechanisms to our services but if changes are required to=20 > these protocols and our existing L2VPN mechanisms can't do it=20 > then it should be the task of the originating organizations=20 > to step in and change their protocols. As much as we do not=20 > want people from other organizations stepping in to tell us=20 > what to do with PWE3/MPLS OAM, I do not think we should try=20 > to do IEEE job.=20 >=20 No modifications to Ethernet OAM for VPLS application has been identified or required. So lets avoid making presumptive statements. Please take a look at the draft-ietf-l2vpn-oam-req-frmk for better understanding of OAM requirements and framework for VPLS. > We can write informational RFCs showing how we can re-use the=20 > IEEE stuff and then push the required protocol work to them.=20 > We do not have anyhow processes aligned to their style of=20 > work/document structure to be able to produce extensions=20 > consistent with their models. No extensions to the existing model has been identified to support VPLS OAM in the draft-mohan-l2vpn-vpls-oam and I am speaking as one of the editor unless you know something that I don't :-) -Ali >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org=20 > [mailto:l2vpn-bounces@ietf.org] On Behalf=20 > > Of Thomas Nadeau > > Sent: Wednesday, April 02, 2008 6:53 AM > > To: Ali Sajassi (sajassi) > > Cc: l2vpn@ietf.org; Shane Amante > > Subject: Re: L2VPN (Re-)charter: VPLS OAM > >=20 > >=20 > > On Apr 2, 2008, at 8:39 AM, Ali Sajassi (sajassi) wrote: > > > > > > Shane, > > > > > > Please refer to my reply inline ... > > > > > >> -----Original Message----- > > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 > > >> Behalf Of Shane Amante > > >> Sent: Tuesday, April 01, 2008 2:31 PM > > >> To: l2vpn@ietf.org > > >> Subject: L2VPN (Re-)charter: VPLS OAM > > >> > > >> All, > > >> > > >> Since there been a variety of comments about the re-charter, I'm=20 > > >> going to attempt to group related comments and respond to > > them that > > >> way. > > >> Hopefully, this way people can follow along more easily. =20 > > See below > > >> for the first response related to VPLS OAM. > > >> > > >> ---snip--- > > >> > > >> Dinesh, Ali, > > >> > > >> ------Dinesh wrote------ > > >>> "L2VPN's will make use of existing IETF specified > > >> mechanisms unless > there are technical reasons why the=20 > existing=20 > > >> mechanisms are > insufficient or unnecessary." > > >>> > > >>> DM>> Which IETF mechanisms are we referring to? This > > >> statement seems > quite vague, can we offer some guidance > > around the > > >> relevance of this > statement. > > >> > > >> Actually, this statement was copied from the PWE3 charter. > > >> The intent is to state that L2VPN WG will re-use MPLS (or > > >> L2TPv3) as defined by the MPLS WG for the PSN, PW's as defined by > > >> PWE3 for service-layer encapsulation, SNMP for MIB's, etc.=20 > > See below > > >> for more. > > >> > > >> > > >>> "In particular, the L2VPN WG will define extensions to > > >> Pseudowire > management (OAM) mechanisms, specifically=20 > Pseudowire=20 > > >> Virtual Circuit > Connectivity Verification (VCCV), for > > VPLS. Those > > >> VCCV extensions ' > > >>> will be reviewed by PWE3 to ensure they are inline with > > >> the overall > design/architecture of VCCV." > > >>> > > >>> DM>> Is it necessary to include this statement in the > > >> charter? This is > presuming solutions that may not have been=20 > > >> completely hashed out yet. > > >>> Isn't the first statement Sufficient in this para "The > > >> L2VPN WG will > provide extensions of existing protocols > > that will > > >> be discussed in > protocol-specific WG's." > > >> > > >> You raise a fair point. I am willing to change the "will"=20 > > to a "may"=20 > > >> as suggested by Ali, (see below for that change). > > >> That leaves open the potential of us extending VCCV within this=20 > > >> proposed charter, rather than having to come back and re-charter=20 > > >> again or, worse, toss around multiple drafts in both PWE3 > > and L2VPN > > >> if we determine a need to extend VCCV. > > >> Plus, given all the recent work on T-MPLS and T-MPLS=20 > OAM, our AD's=20 > > >> wanted to make it explicit that a portion of VCCV may be=20 > worked on=20 > > >> within L2VPN, so people/other-SDO's know where to direct=20 > > >> liaisons/questions/etc. > > >> > > >> > > >> ------Ali wrote------ > > >>> i) "L2VPN's will make use of existing IETF specified > > >> mechanisms unless > there are technical reasons why the=20 > existing=20 > > >> mechanisms are > insufficient or unnecessary." > > >>> > > >>> AS> This statement needs further clarification. I would > > >> suggest the > following text: "L2VPN solutions will make use of=20 > > >> existing IETF PWs > and PSN specified mechanisms for > > providing L2VPN > > >> services unless there > are technical reasons why the existing=20 > > >> mechanisms are insufficient or > unnecessary.=20 > Furthermore, L2VPN=20 > > >> solutions will make use of native > service mechanisms when=20 > > >> applicable for providing L2VPN services - > e.g., use=20 > of Ethernet=20 > > >> OAM for monitoring Ethernet native service. > > >> > > >> First, the intent of the sentence /is not/ to create an=20 > exhaustive=20 > > >> list of all protocols we may (or may not) end up (re-)using from=20 > > >> other WG's, or other SDO's for that matter. > > >> Second, the last sentence you suggested appears to be=20 > saying that=20 > > >> 802.1ag ("native service-layer mechansims") should be=20 > the only OAM=20 > > >> tool for VPLS. I'm pretty confident we don't have WG=20 > consensus to=20 > > >> make that statement in the charter, particularly given the > > "lively"=20 > > >> debates that have ensued at WG meetings when discussing the two=20 > > >> proposed OAM solutions. > > >> > > > > > > Yes, because the intent is not to create and exhaustive > > list, I used > > > "e.g.," rather than listing all the protocols. Also, my > > intention was > > > not to say "that 802.1ag should be the only OAM tool for=20 > VPLS". So,=20 > > > you can change "will" to "should" in my second sentence.=20 > Basically,=20 > > > all I am saying is that if there is already a mechanism for > > a native > > > service, then that mechanism should be considered first before=20 > > > attempting to re-invent the wheel. > > > > > >> However, to bring this back to the charter discussion, I > > believe the > > >> sentence is OK 'as-is', since it leaves room to discuss > > and make use > > >> of alternate mechanisms if "the existing mechansisms are > > insufficent > > >> or unnecessary". Specific to VPLS OAM, Dinesh has already been=20 > > >> highlighting (in his presentations at the WG meetings) the areas=20 > > >> where .1ag may provide a superior solution for *some* > > aspects of VPLS > > >> OAM. > > >> In addition, Olen's draft > > >> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a more=20 > > >> in-depth analysis. Unfortunately, the only debate on=20 > Olen's draft=20 > > >> /on the mailing list/ has been about just one aspect of=20 > the draft,=20 > > >> specifically the H-VPLS reference model, which has already been=20 > > >> acknowledged as incorrect. We need to move on from that > > and look at > > >> the rest of Olen's draft to objectively determine what are the=20 > > >> strengths & weaknesses of either or both (i.e.=20 > complementary) OAM=20 > > >> approaches if we're going to make progress on OAM. > > >> > > > > > > If the intent of this statement is to say: > > > "that L2VPN WG will re-use MPLS (or L2TPv3) as defined by > > the MPLS WG > > > for the PSN, PW's as defined by PWE3 for service-layer > > encapsulation, > > > SNMP for MIB's, etc." > > > As you stated, then, it should be stated as such as the > > first sentence > > > of my proposed text: > > > "L2VPN solutions will make use of existing IETF PW and PSN > > specified > > > mechanisms for providing L2VPN services unless there are=20 > technical=20 > > > reasons why the existing mechanisms are insufficient or=20 > unnecessary" > > > My concern is that by having a vague sentence as such, then > > it makes > > > it open to interpretation and some people may claim that=20 > VCCV-based=20 > > > OAM mechanism for VPLS (and Ethernet services) is the preferred=20 > > > mechanism over native Ethernet OAM (802.1ag/y.1731) because the=20 > > > charter has stated so !! > > > I think we need to select an OAM mechanism for VPLS based on its=20 > > > technical merit as we are progressing in this direction in > > the WG. So, > > > the charter should state that VPLS OAM work is needed without=20 > > > intentionally/unintentionally favoring one mechanism over=20 > the other. > >=20 > > I would agree with Ali here, although I do agree with the text=20 > > stating that we will reuse existing IEEE, MPLS and > > PWE3 mechanisms where we can. > >=20 > > --Tom > >=20 > >=20 > > >>> > > >>> ii) "The L2VPN WG will provide extensions of existing > > >> protocols that > will be discussed in protocol-specific=20 > WG's. In=20 > > >> particular, the L2VPN > WG will define extensions to pseudowire=20 > > >> management (OAM) mechanisms, > specifically Pseudowire Virtual=20 > > >> Circuit Connectivity Verification > (VCCV), for VPLS. =20 > Those VCCV=20 > > >> extensions will be reviewed by > > >> PWE3 to > ensure they are inline with the overall=20 > > >> design/architecture of VCCV." > > >>> > > >>> AS> This statement already assumes that VCCV extensions > > >> are needed for > VPLS which is not the case. I would prefer to=20 > > >> either remove 2nd and > 3rd sentences from the above=20 > para. If we=20 > > >> want to keep these sentences, > then we need to change=20 > "will" to=20 > > >> "may" in 2nd sentence. > > >> > > >> OK, I'll accept the change in your last sentence, (change > > from "will"=20 > > >> to "may" in the second sentence). Specifically, I'll reword the=20 > > >> charter as > > >> follows: > > >> ---snip--- > > >> The L2VPN WG will provide extensions of existing protocols > > that will > > >> be discussed in protocol-specific WG's. In particular, > > the L2VPN WG > > >> may define extensions to pseudowire management (OAM) mechanisms,=20 > > >> specifically Pseudowire Virtual Circuit Connectivity=20 > Verification=20 > > >> (VCCV), for VPLS. Those VCCV extensions will be reviewed > > by PWE3 to > > >> ensure they are inline with the overall > > design/architecture of VCCV." > > >> ---snip--- > > >> > > > > > > O.K. Looks good. > > > > > >> > > >> > > >>> iii) "Furthermore, the L2VPN WG will not define protocol > > >> inter-working > between a VPLS or VPWS and native service-layer=20 > > >> control, OAM or > resiliency mechanisms, as those will be > > defined by > > >> the PWE3 WG. On > the other hand, the L2VPN WG will > > define how to > > >> operate native > service-layer control, OAM or resiliency > > mechanisms > > >> on top of a VPLS > or VPWS service." > > >>> > > >>> AS> This statement needs to be refined to indicate that > > >> the > interworking between the native service-layer and its=20 > > >> associated PW > for the purpose of control, OAM, or resiliency=20 > > >> mechanisms, shall be > defined by the PWE3 WG. > > >> However, the interworking between the native > > > service-layer and the > > >> VPN service, associated with a group of PWs and > their > > forwarding > > >> tables, will be defined by the L2VPN WG when needed. > > >> > > >> I'm not sure I understand the intent or need for the=20 > last sentence=20 > > >> you propose. Can you elaborate on it? > > >> Specifically, I'm trying to understand what might just be=20 > > >> implementation details irrelevant to L2VPN, say specific to the=20 > > >> Bridge Module and AC's, vs. some interaction between=20 > PW's and the=20 > > >> Bridge Module or something else. > > >> > > > > > > An example of it would be the dual-homing and redundancy support=20 > > > between an 802.1ah access network and a VPLS core; where, 802.1ah=20 > > > access network is running L2GP protocol in order to avoid > > running its > > > MSTP over VPLS core. In such scenario, upon a topology=20 > change, the=20 > > > 802.1ah access network would signal the PE using MVRP message to=20 > > > indicate the VLANs that are affected as the result of > > topology change > > > and if LDP is used for C-MAC withdraw, then the PE needs=20 > to process=20 > > > the MVRP message and generate LDP MAC withdraw messages for the=20 > > > affected service instances. > > > > > > Cheers, > > > Ali > > > > > > > > >> Thanks, > > >> > > >> -shane > > >> > > > > >=20 > >=20 >=20 From l2vpn-bounces@ietf.org Wed Apr 2 10:31:21 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213AB3A6DED; Wed, 2 Apr 2008 10:31:21 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7243A6CA9 for ; Wed, 2 Apr 2008 10:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9gy7hMhf4rY for ; Wed, 2 Apr 2008 10:31:18 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id ADAE93A680E for ; Wed, 2 Apr 2008 10:31:11 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 02 Apr 2008 10:31:12 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 10:30:27 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m32HURD09132; Wed, 2 Apr 2008 10:30:27 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Wed, 2 Apr 2008 10:30:27 -0700 (PDT) From: Rahul Aggarwal To: Shane Amante Subject: Re: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) In-Reply-To: <47F39185.6010407@castlepoint.net> Message-ID: <20080402101648.S556@sapphire.juniper.net> References: <47F39185.6010407@castlepoint.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Apr 2008 17:30:27.0714 (UTC) FILETIME=[3DE9AE20:01C894E7] Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Shane, On Wed, 2 Apr 2008, Shane Amante wrote: > Frederic, Florin, Dinesh & Ali, > > ------Frederic wrote------ > > Just a comment related to multicast: > > In the goals and milestones sections, you are referring to VPMS (Virtual > > Private Multicast Servcice), I would suggest to introduce this > service in > > the charter itself as a new L2VPN to be added to the 3 existing VPLS, > VPWS > > and IPLS. > > > > Virtual Private Multicast Service (VPMS) -- A Layer 2 service that > > Provides point-to-multipoint connectivity for a variety of link layers, > > including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or > > MPLS-enabled IP PSN. > > > > VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the > > PWE3 WG. > > Good point. I'll add the last two paragraphs you've suggested to the > charter. And, see below for the contingency on PWE3 successfully > chartering P2MP PW's, in order for L2VPN to be able to work on this. > Agreed. Clarifying the definition of VPMS in the charter will help. > > ------Dinesh wrote------ > > "Nov 2009 Submit Auto-Discovery solution for VPMS to IESG" > > DM>> VPMS?? Possibly a typo :-) > > No, it's not a typo. See above for a more detailed explanation of a new > work item (recently) proposed by Frederic, Phillipe & Rahul. > > > ------Florin wrote------ > > > Mar 2009 Submit I-D on Virtual Private Multicast Service > > (VPMS)requirements to IESG > > [..] > > Nov 2009 Submit Auto-Discovery solution for VPMS to IESG > > > > FB> (this comment applies to the 2 previous items) Not sure I understand > > what are we trying to achieve here? We stated in item 5 of the charter > > that L2 VPN WG is going to deal with "5. Mechanisms to permit > > optimization of multicast data traffic within a VPLS or VPWS VPN over an > > IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it similar with > > P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on this just in > > case we are dealing with a VPN like collection of PWs. Otherwise we > > should probably address this in PWE3/MPLS to start with. > > FB> > > Thanks for pointing this out. To be clear, the L2VPN WG is dependent on > the /successful/ chartering of P2MP PW's within the PWE3 WG -- which > hasn't happened, yet. > > Assuming the PWE3 WG does charter P2MP PW's, the way the VPMS work would > be split between the PWE3 WG and the L2VPN WG is as follows: > 1) Requirements for a unidirectional P2MP PW will be in PWE3; > 2) P2MP PW encapsulation solution(s) will be in PWE3; > 3) Requirements for a VPMS "service", (Virtual Private P2MP > unidirectional service), will be put forth in the the L2VPN WG; > 4) BGP Auto-Discovery procedures for VPMS will also be put in L2VPN. > > In terms of existing drafts that would mean: > - draft-raggarwa-l2vpn-p2mp-pw-00: would get split into two drafts. The > first draft would define a P2MP PW (#2) and be within the scope of PWE3. > The second draft would define BGP Auto-Discovery procedures for VPMS > (#4) and be within the L2VPN WG. > - draft-jounay-pwe3-p2mp-pw-requirements-01 would be in PWE3 and cover #1. > - A new, yet unwritten draft would have to be put forth to cover #3, > (or, perhaps, combined with #4). > > That seems consistant with how VPWS related mechanisms are split between PWE3 and L2VPN WG today. rahul > > -----Ali wrote----- > > iv) "5. Mechanisms to permit optimization of multicast data traffic > > within a VPLS or VPWS VPN over an IP/MPLS PSN." > > > > AS> mcast optimization should only be for VPLS based on VPWS service > > definition. > > So, are you saying you share the same concern as Florin that we need to > 'wait to see' if the PWE3 WG will add P2MP PW's to their charter? > > I've pinged Danny & Stewart to see if they can send out the new PWE3 > charter soon, in order that we're not 'waiting to see' if PWE3 WG will > or will not take on P2MP PW's. > > Thanks, > > -shane > From l2vpn-bounces@ietf.org Wed Apr 2 12:15:23 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD8328C698; Wed, 2 Apr 2008 12:15:23 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3A528C6C0 for ; Wed, 2 Apr 2008 12:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDC3eKJersiA for ; Wed, 2 Apr 2008 12:15:19 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 85EC53A684F for ; Wed, 2 Apr 2008 12:11:39 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m32JBYAw007008; Wed, 2 Apr 2008 13:11:34 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 14:10:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: VPLS OAM Date: Wed, 2 Apr 2008 14:10:16 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191C2A@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <483F121CD2155B43B56DB71228DBAF15014D27E2@xmb-sjc-239.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: VPLS OAM Thread-Index: AciUyRAeAq68IbHQRgeba6NTvjvLgQADAUtQAADI4oAABjjAMA== From: "BALUS Florin" To: "Ali Sajassi \(sajassi\)" , "Thomas Nadeau" X-OriginalArrivalTime: 02 Apr 2008 19:10:30.0875 (UTC) FILETIME=[38135AB0:01C894F5] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: l2vpn@ietf.org, Shane Amante X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org My comments were directed at some suggestions I heard during IETF-71 where people were considering adding new TLVs to IEEE 802.1ag to address mis-connectivity in the PWE3/PSN infrastructure, in the quest to do everything with Ethernet OAM.=20 In L2VPN WG we should start from the premise that PWE3 and IP/MPLS PSN infrastructure is in place so the effort should be focused on extending the available tools - e.g. PW3 or IP/MPLS OAM, VPLS LDP MAC Withdraw - not on adapting native services to do the job. We need to make sure this is clearly reflected in the charter. Ali, I was not suggesting anything about the content of your existing drafts, we're talking about the future text for the charter that is supposed to focus our efforts in L2VPN WG. Glad to hear we are on the same page on the distribution of work I mentioned below.=20 Florin=20 > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 > Sent: Wednesday, April 02, 2008 9:00 AM > To: BALUS Florin; Thomas Nadeau > Cc: l2vpn@ietf.org; Shane Amante > Subject: RE: L2VPN (Re-)charter: VPLS OAM >=20 > =20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org=20 > [mailto:l2vpn-bounces@ietf.org] On Behalf=20 > > Of BALUS Florin > > Sent: Wednesday, April 02, 2008 8:41 AM > > To: Thomas Nadeau; Ali Sajassi (sajassi) > > Cc: l2vpn@ietf.org; Shane Amante > > Subject: RE: L2VPN (Re-)charter: VPLS OAM > >=20 > >=20 > > I think the important aspect that Shane is trying to capture in the=20 > > L2VPN charter is that our focus is to address required=20 > extensions to=20 > > the mechanisms specific to the PSNs (IP/MPLS) and PWE3=20 > infrastructure=20 > > that is common to both VPLS and VPWS. >=20 > So, we should capture it as such as I suggested rather and=20 > avoid having a vague statement. >=20 > >=20 > > I do not think we should try to step over other people's=20 > toes and work=20 > > on extending the protocols developed by other organizations (e.g.=20 > > IEEE) to address needs specific to our PSNs or PWE3 infrastructure. > >=20 >=20 > No body is suggesting that !! specially with respect to PSN=20 > and PWs infrastructure. The point that I made was that when=20 > it comes to support of native services (e.g., Ethernet in=20 > case of VPLS), we should see what is out there and leveraging=20 > existing mechanism rather than trying to reinvent the wheel.=20 > The comment was made specifically wrt VPLS OAM.=20 >=20 > > We can write specifications showing applicability of native=20 > mechanisms=20 > > to our services but if changes are required to these=20 > protocols and our=20 > > existing L2VPN mechanisms can't do it then it should be the task of=20 > > the originating organizations to step in and change their=20 > protocols.=20 > > As much as we do not want people from other organizations=20 > stepping in=20 > > to tell us what to do with PWE3/MPLS OAM, I do not think we=20 > should try=20 > > to do IEEE job. > >=20 >=20 > No modifications to Ethernet OAM for VPLS application has=20 > been identified or required. So lets avoid making presumptive=20 > statements. > Please take a look at the draft-ietf-l2vpn-oam-req-frmk for=20 > better understanding of OAM requirements and framework for VPLS. >=20 > > We can write informational RFCs showing how we can re-use the IEEE=20 > > stuff and then push the required protocol work to them. > > We do not have anyhow processes aligned to their style of=20 > > work/document structure to be able to produce extensions consistent=20 > > with their models. >=20 > No extensions to the existing model has been identified to=20 > support VPLS OAM in the draft-mohan-l2vpn-vpls-oam and I am=20 > speaking as one of the editor unless you know something that=20 > I don't :-) >=20 > -Ali >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org > > [mailto:l2vpn-bounces@ietf.org] On Behalf > > > Of Thomas Nadeau > > > Sent: Wednesday, April 02, 2008 6:53 AM > > > To: Ali Sajassi (sajassi) > > > Cc: l2vpn@ietf.org; Shane Amante > > > Subject: Re: L2VPN (Re-)charter: VPLS OAM > > >=20 > > >=20 > > > On Apr 2, 2008, at 8:39 AM, Ali Sajassi (sajassi) wrote: > > > > > > > > Shane, > > > > > > > > Please refer to my reply inline ... > > > > > > > >> -----Original Message----- > > > >> From: l2vpn-bounces@ietf.org=20 > [mailto:l2vpn-bounces@ietf.org] On=20 > > > >> Behalf Of Shane Amante > > > >> Sent: Tuesday, April 01, 2008 2:31 PM > > > >> To: l2vpn@ietf.org > > > >> Subject: L2VPN (Re-)charter: VPLS OAM > > > >> > > > >> All, > > > >> > > > >> Since there been a variety of comments about the=20 > re-charter, I'm=20 > > > >> going to attempt to group related comments and respond to > > > them that > > > >> way. > > > >> Hopefully, this way people can follow along more easily. =20 > > > See below > > > >> for the first response related to VPLS OAM. > > > >> > > > >> ---snip--- > > > >> > > > >> Dinesh, Ali, > > > >> > > > >> ------Dinesh wrote------ > > > >>> "L2VPN's will make use of existing IETF specified > > > >> mechanisms unless > there are technical reasons why the > > existing > > > >> mechanisms are > insufficient or unnecessary." > > > >>> > > > >>> DM>> Which IETF mechanisms are we referring to? This > > > >> statement seems > quite vague, can we offer some guidance > > > around the > > > >> relevance of this > statement. > > > >> > > > >> Actually, this statement was copied from the PWE3 charter. > > > >> The intent is to state that L2VPN WG will re-use MPLS (or > > > >> L2TPv3) as defined by the MPLS WG for the PSN, PW's as=20 > defined by > > > >> PWE3 for service-layer encapsulation, SNMP for MIB's, etc.=20 > > > See below > > > >> for more. > > > >> > > > >> > > > >>> "In particular, the L2VPN WG will define extensions to > > > >> Pseudowire > management (OAM) mechanisms, specifically > > Pseudowire > > > >> Virtual Circuit > Connectivity Verification (VCCV), for > > > VPLS. Those > > > >> VCCV extensions ' > > > >>> will be reviewed by PWE3 to ensure they are inline with > > > >> the overall > design/architecture of VCCV." > > > >>> > > > >>> DM>> Is it necessary to include this statement in the > > > >> charter? This is > presuming solutions that may not have been=20 > > > >> completely hashed out yet. > > > >>> Isn't the first statement Sufficient in this para "The > > > >> L2VPN WG will > provide extensions of existing protocols > > > that will > > > >> be discussed in > protocol-specific WG's." > > > >> > > > >> You raise a fair point. I am willing to change the "will"=20 > > > to a "may"=20 > > > >> as suggested by Ali, (see below for that change). > > > >> That leaves open the potential of us extending VCCV=20 > within this=20 > > > >> proposed charter, rather than having to come back and=20 > re-charter=20 > > > >> again or, worse, toss around multiple drafts in both PWE3 > > > and L2VPN > > > >> if we determine a need to extend VCCV. > > > >> Plus, given all the recent work on T-MPLS and T-MPLS > > OAM, our AD's > > > >> wanted to make it explicit that a portion of VCCV may be > > worked on > > > >> within L2VPN, so people/other-SDO's know where to direct=20 > > > >> liaisons/questions/etc. > > > >> > > > >> > > > >> ------Ali wrote------ > > > >>> i) "L2VPN's will make use of existing IETF specified > > > >> mechanisms unless > there are technical reasons why the > > existing > > > >> mechanisms are > insufficient or unnecessary." > > > >>> > > > >>> AS> This statement needs further clarification. I would > > > >> suggest the > following text: "L2VPN solutions will=20 > make use of=20 > > > >> existing IETF PWs > and PSN specified mechanisms for > > > providing L2VPN > > > >> services unless there > are technical reasons why the=20 > existing=20 > > > >> mechanisms are insufficient or > unnecessary. > > Furthermore, L2VPN > > > >> solutions will make use of native > service mechanisms when=20 > > > >> applicable for providing L2VPN services - > e.g., use > > of Ethernet > > > >> OAM for monitoring Ethernet native service. > > > >> > > > >> First, the intent of the sentence /is not/ to create an > > exhaustive > > > >> list of all protocols we may (or may not) end up=20 > (re-)using from=20 > > > >> other WG's, or other SDO's for that matter. > > > >> Second, the last sentence you suggested appears to be > > saying that > > > >> 802.1ag ("native service-layer mechansims") should be > > the only OAM > > > >> tool for VPLS. I'm pretty confident we don't have WG > > consensus to > > > >> make that statement in the charter, particularly given the > > > "lively"=20 > > > >> debates that have ensued at WG meetings when=20 > discussing the two=20 > > > >> proposed OAM solutions. > > > >> > > > > > > > > Yes, because the intent is not to create and exhaustive > > > list, I used > > > > "e.g.," rather than listing all the protocols. Also, my > > > intention was > > > > not to say "that 802.1ag should be the only OAM tool for > > VPLS". So, > > > > you can change "will" to "should" in my second sentence.=20 > > Basically, > > > > all I am saying is that if there is already a mechanism for > > > a native > > > > service, then that mechanism should be considered first before=20 > > > > attempting to re-invent the wheel. > > > > > > > >> However, to bring this back to the charter discussion, I > > > believe the > > > >> sentence is OK 'as-is', since it leaves room to discuss > > > and make use > > > >> of alternate mechanisms if "the existing mechansisms are > > > insufficent > > > >> or unnecessary". Specific to VPLS OAM, Dinesh has=20 > already been=20 > > > >> highlighting (in his presentations at the WG meetings)=20 > the areas=20 > > > >> where .1ag may provide a superior solution for *some* > > > aspects of VPLS > > > >> OAM. > > > >> In addition, Olen's draft > > > >> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a more=20 > > > >> in-depth analysis. Unfortunately, the only debate on > > Olen's draft > > > >> /on the mailing list/ has been about just one aspect of > > the draft, > > > >> specifically the H-VPLS reference model, which has=20 > already been=20 > > > >> acknowledged as incorrect. We need to move on from that > > > and look at > > > >> the rest of Olen's draft to objectively determine what are the=20 > > > >> strengths & weaknesses of either or both (i.e. > > complementary) OAM > > > >> approaches if we're going to make progress on OAM. > > > >> > > > > > > > > If the intent of this statement is to say: > > > > "that L2VPN WG will re-use MPLS (or L2TPv3) as defined by > > > the MPLS WG > > > > for the PSN, PW's as defined by PWE3 for service-layer > > > encapsulation, > > > > SNMP for MIB's, etc." > > > > As you stated, then, it should be stated as such as the > > > first sentence > > > > of my proposed text: > > > > "L2VPN solutions will make use of existing IETF PW and PSN > > > specified > > > > mechanisms for providing L2VPN services unless there are > > technical > > > > reasons why the existing mechanisms are insufficient or > > unnecessary" > > > > My concern is that by having a vague sentence as such, then > > > it makes > > > > it open to interpretation and some people may claim that > > VCCV-based > > > > OAM mechanism for VPLS (and Ethernet services) is the preferred=20 > > > > mechanism over native Ethernet OAM (802.1ag/y.1731) because the=20 > > > > charter has stated so !! > > > > I think we need to select an OAM mechanism for VPLS=20 > based on its=20 > > > > technical merit as we are progressing in this direction in > > > the WG. So, > > > > the charter should state that VPLS OAM work is needed without=20 > > > > intentionally/unintentionally favoring one mechanism over > > the other. > > >=20 > > > I would agree with Ali here, although I do agree with the text=20 > > > stating that we will reuse existing IEEE, MPLS and > > > PWE3 mechanisms where we can. > > >=20 > > > --Tom > > >=20 > > >=20 > > > >>> > > > >>> ii) "The L2VPN WG will provide extensions of existing > > > >> protocols that > will be discussed in protocol-specific > > WG's. In > > > >> particular, the L2VPN > WG will define extensions to=20 > pseudowire=20 > > > >> management (OAM) mechanisms, > specifically=20 > Pseudowire Virtual=20 > > > >> Circuit Connectivity Verification > (VCCV), for VPLS. > > Those VCCV > > > >> extensions will be reviewed by > > > >> PWE3 to > ensure they are inline with the overall=20 > > > >> design/architecture of VCCV." > > > >>> > > > >>> AS> This statement already assumes that VCCV extensions > > > >> are needed for > VPLS which is not the case. I would=20 > prefer to=20 > > > >> either remove 2nd and > 3rd sentences from the above > > para. If we > > > >> want to keep these sentences, > then we need to change > > "will" to > > > >> "may" in 2nd sentence. > > > >> > > > >> OK, I'll accept the change in your last sentence, (change > > > from "will"=20 > > > >> to "may" in the second sentence). Specifically, I'll=20 > reword the=20 > > > >> charter as > > > >> follows: > > > >> ---snip--- > > > >> The L2VPN WG will provide extensions of existing protocols > > > that will > > > >> be discussed in protocol-specific WG's. In particular, > > > the L2VPN WG > > > >> may define extensions to pseudowire management (OAM)=20 > mechanisms,=20 > > > >> specifically Pseudowire Virtual Circuit Connectivity > > Verification > > > >> (VCCV), for VPLS. Those VCCV extensions will be reviewed > > > by PWE3 to > > > >> ensure they are inline with the overall > > > design/architecture of VCCV." > > > >> ---snip--- > > > >> > > > > > > > > O.K. Looks good. > > > > > > > >> > > > >> > > > >>> iii) "Furthermore, the L2VPN WG will not define protocol > > > >> inter-working > between a VPLS or VPWS and native=20 > service-layer=20 > > > >> control, OAM or > resiliency mechanisms, as those will be > > > defined by > > > >> the PWE3 WG. On > the other hand, the L2VPN WG will > > > define how to > > > >> operate native > service-layer control, OAM or resiliency > > > mechanisms > > > >> on top of a VPLS > or VPWS service." > > > >>> > > > >>> AS> This statement needs to be refined to indicate that > > > >> the > interworking between the native service-layer and its=20 > > > >> associated PW > for the purpose of control, OAM, or=20 > resiliency=20 > > > >> mechanisms, shall be > defined by the PWE3 WG. > > > >> However, the interworking between the native > > > > service-layer and the > > > >> VPN service, associated with a group of PWs and > their > > > forwarding > > > >> tables, will be defined by the L2VPN WG when needed. > > > >> > > > >> I'm not sure I understand the intent or need for the > > last sentence > > > >> you propose. Can you elaborate on it? > > > >> Specifically, I'm trying to understand what might just be=20 > > > >> implementation details irrelevant to L2VPN, say=20 > specific to the=20 > > > >> Bridge Module and AC's, vs. some interaction between > > PW's and the > > > >> Bridge Module or something else. > > > >> > > > > > > > > An example of it would be the dual-homing and=20 > redundancy support=20 > > > > between an 802.1ah access network and a VPLS core;=20 > where, 802.1ah=20 > > > > access network is running L2GP protocol in order to avoid > > > running its > > > > MSTP over VPLS core. In such scenario, upon a topology > > change, the > > > > 802.1ah access network would signal the PE using MVRP=20 > message to=20 > > > > indicate the VLANs that are affected as the result of > > > topology change > > > > and if LDP is used for C-MAC withdraw, then the PE needs > > to process > > > > the MVRP message and generate LDP MAC withdraw messages for the=20 > > > > affected service instances. > > > > > > > > Cheers, > > > > Ali > > > > > > > > > > > >> Thanks, > > > >> > > > >> -shane > > > >> > > > > > > >=20 > > >=20 > >=20 >=20 From l2vpn-bounces@ietf.org Wed Apr 2 14:05:59 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE193A6A0A; Wed, 2 Apr 2008 14:05:59 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6323A6A0A for ; Wed, 2 Apr 2008 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI5UJnCpEHpd for ; Wed, 2 Apr 2008 14:05:55 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 113363A6C2C for ; Wed, 2 Apr 2008 14:05:52 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C863B268496; Wed, 2 Apr 2008 15:05:53 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Wed, 02 Apr 2008 15:05:53 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=48991; data-bytes=0 Message-ID: <47F3F530.1050009@castlepoint.net> Date: Wed, 02 Apr 2008 15:05:52 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Loa Andersson Subject: Re: L2VPN WG (Re-)charter References: <47F211E5.50606@pi.se> In-Reply-To: <47F211E5.50606@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Loa, I couldn't find a good place to respond to some of the items you raised, so I'm responding directly to those here. Please see below. Loa Andersson wrote: > Shane, > > just a few smaller issues > > - for discovery specifiactions > -- does this include automated Inter-AS discovery I'll follow-up on this in the response to Inter-AS comments. > -- to discover PEs that participates in a particular > VPMS, how different is this from discovery for PEs > participating in a VPLS? It's my understanding that VPMS Auto-Discovery should be very similar to what is already specified in draft-ietf-l2vpn-vpls-mcast-03. I would refer you to Section 4.2, "Auto-Discovery and Signaling", of draft-raggarwa-l2vpn-p2mp-pw-00 for more details. > -- how different is L2VPN discovery from L3VPN discovery? Is this question also related to multicast? If so, then in my understanding the procedures are very much the same. Again, I'd refer you to draft-ietf-l2vpn-vpls-mcast-03 for more details on multicast and Auto-Discovery. > - I would split the > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > milestone into two different mailstones I'll follow-up on this in the response to Inter-AS comments. > - I'm a bit uncertain about whether there are one or two multi-homing > scenarios in the text > -- VPLS using multi-homed CEs > -- multi-homed VPLS solutions I've responded to this in the 'Service Convergence' comments. Thanks, -shane From l2vpn-bounces@ietf.org Wed Apr 2 14:40:29 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701633A6C81; Wed, 2 Apr 2008 14:40:28 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AED93A6B9A for ; Wed, 2 Apr 2008 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU-+nLQlKf-c for ; Wed, 2 Apr 2008 14:40:26 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 02AC83A6E34 for ; Wed, 2 Apr 2008 14:40:09 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id m32Le4lI007402; Wed, 2 Apr 2008 15:40:05 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 16:40:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: Service Convergence Date: Wed, 2 Apr 2008 16:39:48 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191CA9@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <47F391FE.6040804@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: Service Convergence Thread-Index: AciUyjnco50Kf+MXSm2ROsoYmz54kgANZbeg From: "BALUS Florin" To: "Shane Amante" , X-OriginalArrivalTime: 02 Apr 2008 21:40:04.0745 (UTC) FILETIME=[1CEB3F90:01C8950A] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, See in-line...=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Wednesday, April 02, 2008 7:03 AM > To: l2vpn@ietf.org > Subject: L2VPN (Re-)charter: Service Convergence >=20 > Loa, Florin, Ali, >=20 > ------Loa wrote------ > > - I'm a bit uncertain about whether there are one or two=20 > multi-homing > > scenarios in the text > > -- VPLS using multi-homed CEs > > -- multi-homed VPLS solutions >=20 > See Florin's suggested text below. I think Florin is=20 > suggesting to clarify that we need both, (if I interpret your=20 > 2nd bullet correctly). >=20 >=20 > ------Florin wrote------ > > The L2VPN WG scope includes the following: > > [..] > > 6. Improved service convergence for multi-homed CE's to VPLS PE's. > > Specifically, upon failure of a primary path from a CE=20 > to VPLS PE, > > initiate a rapid switch-over to an alternate path. If required, > > interactions with native service-layer resiliency=20 > mechanisms will be > > provided via solutions from other IETF WG's such as PWE3. > > > > FB> Suggest we modify the text to include also=20 > multi-homing between 2 > > VPLS domains, see below an example of text: > > 6. Improved service convergence for multi-homing=20 > solutions: CEs to VPLS > > PEs or between VPLS domains. >=20 > Can you clarify this further? Specifically, do you mean the=20 > following=20 > two cases: > a) One CE to two different VPLS PE's in a single AS; and, > b) One CE to two different VPLS PE's, each in a different AS? >=20 Not really. What I had in mind was more along the following: a) CEs multi-homed to different VPLS PEs=20 b) a VPLS domain multi-homed to another VPLS domain: e.g. a VPLS mesh in domain 1 multihomed to a VPLS mesh in domain 2. =20 Examples of criteria that may define what a VPLS domain is: geographical (metro, national, international), administrative different organizations/providers) etc... > Also, correct me if I'm wrong, but PWE3 has already covered=20 > multi-homing of a MTU-s to two, different PE-rs'es in=20 > draft-muley-pwe3-redundancy-02?=20 > Or, is there addt'l work that L2VPN WG needs to take care of=20 > specifically for that case? draft-muley-pwe3-redundancy (adopted as PWE3 draft-ietf-pwe3-redundancy-00.txt) can be definitely applied to optimize the procedures described in section 10.2 of RFC 4762 (VPLS MTU-s to PE-rs resiliency). Still I think there is a need to have a discussion about usage in a VPLS context to ensure interoperability, including an update on how to reflect the PW transitions in LDP MAC Flush. Also this sort of resiliency (1 MTU-s to 2 PE-rs, triangle like) might not be enough for the interconnection of two VPLS mesh domains: i.e. the MTU-s will be a single point of failure. More like a square interconnection is required here where 2 VPLS PEs in domain 1 are connected to 2 VPLS PEs in domain 2. >=20 >=20 > > Specifically, upon failure of a primary > > path from a between CEs and VPLS PEs or between VPLS=20 > domains, initiate a > > rapid switch-over to an alternate path. If required,=20 > interactions with > > native service-layer resiliency mechanisms will be provided via > > solutions from other IETF WG's such as PWE3. > > FB> > > > > > > The L2VPN WG currently works on the following tasks: > > [..] > > - Identify requirements for multi-homing of CE's to VPLS PE's. > > elements. Based on these requirements, define solutions for > > achieving fast convergence after a switchover to an=20 > alternate path, > > for example through optimized MAC flushing within a VPLS domain. > > > > FB> Suggest changing this one to the following text: > > - Identify requirements for different multi-homing=20 > solutions: i.e. CEs > > to VPLS Pes or between VPLS domains. Based on these=20 > requirements, define > > solutions for achieving fast convergence after a switchover to an > > alternate path, for example through optimized MAC flushing=20 > within a VPLS > > domain. > > FB> >=20 > I have the same question here as I do above. Once we're on the same=20 > page, then I think we can tighten the suggested text a little further. > I hope the above answer addressed this one too. >=20 >=20 > ------Ali wrote------ > > v) "6. Improved service convergence for multi-homed CE's=20 > to VPLS PE's. > > Specifically, upon failure of a primary path from a CE=20 > to VPLS PE, > > initiate a rapid switch-over to an alternate path. If required, > > interactions with native service-layer resiliency=20 > mechanisms will be > > provided via solutions from other IETF WG's such as PWE3." > > > > AS> We should create another bullet to include=20 > multi-homing between two > > or more VPLS networks. >=20 > Ali: I think you're asking for the same thing as Florin, (see above).=20 > If not, please clarify further. >=20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Wed Apr 2 14:56:56 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E32B3A6B1E; Wed, 2 Apr 2008 14:56:56 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBCF3A6B65 for ; Wed, 2 Apr 2008 14:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn0qH+QaRZ-v for ; Wed, 2 Apr 2008 14:56:54 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 758E53A6A8A for ; Wed, 2 Apr 2008 14:56:54 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m32LunvP015221; Wed, 2 Apr 2008 15:56:49 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 16:56:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) Date: Wed, 2 Apr 2008 16:56:34 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191CB7@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <47F39185.6010407@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) Thread-Index: AciUyfaZPc9JAiyiR0CC2o9AJz+ZpQAQDKhg From: "BALUS Florin" To: "Shane Amante" , X-OriginalArrivalTime: 02 Apr 2008 21:56:49.0685 (UTC) FILETIME=[73E8EC50:01C8950C] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org [..] - cutting the previous text to make it for an easier read > ------Florin wrote------ >=20 > > Mar 2009 Submit I-D on Virtual Private Multicast Service > > (VPMS)requirements to IESG > > [..] > > Nov 2009 Submit Auto-Discovery solution for VPMS to IESG > > > > FB> (this comment applies to the 2 previous items) Not=20 > sure I understand > > what are we trying to achieve here? We stated in item 5 of=20 > the charter > > that L2 VPN WG is going to deal with "5. Mechanisms to permit > > optimization of multicast data traffic within a VPLS or=20 > VPWS VPN over an > > IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it=20 > similar with > > P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on=20 > this just in > > case we are dealing with a VPN like collection of PWs. Otherwise we > > should probably address this in PWE3/MPLS to start with. > > FB> >=20 > Thanks for pointing this out. To be clear, the L2VPN WG is=20 > dependent on=20 > the /successful/ chartering of P2MP PW's within the PWE3 WG -- which=20 > hasn't happened, yet. >=20 > Assuming the PWE3 WG does charter P2MP PW's, the way the VPMS=20 > work would=20 > be split between the PWE3 WG and the L2VPN WG is as follows: > 1) Requirements for a unidirectional P2MP PW will be in PWE3; > 2) P2MP PW encapsulation solution(s) will be in PWE3; > 3) Requirements for a VPMS "service", (Virtual Private P2MP=20 > unidirectional service), will be put forth in the the L2VPN WG; > 4) BGP Auto-Discovery procedures for VPMS will also be put in L2VPN. >=20 I agree that P2MP PW has to be discussed and included in the PWE3 charter first. Then the requirements and the solution components (e.g. encapsulation(s), signaling) need to be addressed in PWE3 WG.=20 Isn't it too early though to talk about a VPMS charter item for L2VPN WG? It might be better to wait for PWE3 WG to make a decision on this and then decide how much and what kind of work we need to do in L2VPN WG?=20 > In terms of existing drafts that would mean: > - draft-raggarwa-l2vpn-p2mp-pw-00: would get split into two=20 > drafts. The=20 > first draft would define a P2MP PW (#2) and be within the=20 > scope of PWE3.=20 > The second draft would define BGP Auto-Discovery procedures=20 > for VPMS=20 > (#4) and be within the L2VPN WG. > - draft-jounay-pwe3-p2mp-pw-requirements-01 would be in PWE3=20 > and cover #1. > - A new, yet unwritten draft would have to be put forth to cover #3,=20 > (or, perhaps, combined with #4). >=20 >=20 >=20 > -----Ali wrote----- > > iv) "5. Mechanisms to permit optimization of multicast data traffic > > within a VPLS or VPWS VPN over an IP/MPLS PSN." > > > > AS> mcast optimization should only be for VPLS based on=20 > VPWS service > > definition. >=20 > So, are you saying you share the same concern as Florin that=20 > we need to=20 > 'wait to see' if the PWE3 WG will add P2MP PW's to their charter? >=20 > I've pinged Danny & Stewart to see if they can send out the new PWE3=20 > charter soon, in order that we're not 'waiting to see' if=20 > PWE3 WG will=20 > or will not take on P2MP PW's. >=20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Wed Apr 2 15:46:49 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8F43A695E; Wed, 2 Apr 2008 15:46:49 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB93F3A68EE for ; Wed, 2 Apr 2008 15:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzPaJDvZQVX6 for ; Wed, 2 Apr 2008 15:46:47 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0A9333A6951 for ; Wed, 2 Apr 2008 15:46:47 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DF423268496; Wed, 2 Apr 2008 16:46:45 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 02 Apr 2008 16:46:45 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=34230; data-bytes=0 Message-ID: <47F40CD5.3000003@castlepoint.net> Date: Wed, 02 Apr 2008 16:46:45 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: L2VPN (Re-)charter: Inter-AS (+ multicast) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Loa, Florin, ------Loa wrote------ > - for discovery specifiactions > -- does this include automated Inter-AS discovery I'm not sure I understand what part of the charter you're asking about. Can you point out what section(s) you referring to, (scope, tasks worked on, etc.)? > - I would split the > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > milestone into two different mailstones This may not be necessary. See below. ------Florin wrote------ > Goals and Milestones: > [..] > FB> We are missing here L2VPN Auto-discovery, Signaling and Inter-AS > (see draft-ietf-l2vpn-signaling-08.txt). This was already submitted to > IESG and is waiting in the RFC queue. Suggest adding the following item: > > "Done Submit L2VPN Auto-discovery, Signaling and Inter-AS to IESG" > [..] > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > FB> I thought we already have these items addressed in > draft-ietf-l2vpn-signaling-08.txt ("Provisioning, Autodiscovery, and > Signaling in L2VPNs"), currently in the RFC queue. Good point, however that draft largely only covers signaling for Inter-AS unicast L2VPN's. It does not cover optimized forwarding of multicast within Inter-AS VPLS or VPMS. What about the following suggestion? In "Scope", we change #8 to be as follows: ---cut here--- 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS unicast VPLS and VPWS L2VPN's, in addition to Inter-AS multicast VPLS and VPMS Layer-2 VPN's. ---cut here--- The above would capture the existing, completed work in draft-ietf-l2vpn-signaling-08 for Auto-Discovery and Signaling of Intra- and Inter-AS VPWS and VPLS L2VPN's. In addition, it should also capture the in-flight work on optimized multicast, both Intra- and Inter-AS, for VPLS and VPMS in the following drafts: - draft-ietf-l2vpn-vpls-mcast-reqts-05 - draft-ietf-l2vpn-vpls-mcast-03 - draft-raggarwa-l2vpn-p2mp-pw-00 -- assuming PWE3 & L2VPN successfully charter work on p2mp PW's and l2vpn's - TBD draft for VPMS l2vpn requirements I really don't think it's necessary to create separate goals/milestones for every solution calling out that it's specific for Intra- or Inter-AS, since most (all?) existing work has included Inter-AS anyway. (Of course, I am making a minor exception for the l2vpn-signaling draft down below). In "Goals and Milestones": ---cut here--- As you suggested, add this: Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPN's [..] Also, as you suggested, delete this milestone: Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG ---cut here--- The Intra- and Inter-AS multicast work should already be reflected in these milestones, (no changes to these): ---cut here--- Nov 2008 Submit multicast optimization solutions for VPLS to IESG Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2009 Submit Auto-Discovery solution for VPMS to IESG ---cut here--- Thanks, -shane From l2vpn-bounces@ietf.org Wed Apr 2 20:29:07 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10EA3A6D27; Wed, 2 Apr 2008 20:29:07 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE3B3A6BF7 for ; Wed, 2 Apr 2008 20:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttzrnyLAFJ9E for ; Wed, 2 Apr 2008 20:29:05 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 5EB6E3A688B for ; Wed, 2 Apr 2008 20:29:05 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D20AC268496; Wed, 2 Apr 2008 21:29:07 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-65-140.hlrn.qwest.net [71.215.65.140]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 02 Apr 2008 21:29:07 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.65.140; client-port=4257; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <04158B82-E770-4E72-BAC3-4BBFB28D5641@castlepoint.net> From: Shane Amante To: Ali Sajassi (sajassi) In-Reply-To: <483F121CD2155B43B56DB71228DBAF15014D2778@xmb-sjc-239.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN (Re-)charter: VPLS OAM Date: Wed, 2 Apr 2008 21:28:51 -0600 References: <483F121CD2155B43B56DB71228DBAF15014D2778@xmb-sjc-239.amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Ali, In order to address your concern, I think we are likely focusing on the wrong part of the charter. So, if you don't mind, let's address that text first. The following is the proposed text in the first draft of the charter. Please pay attention to the last sentence: ---snip--- The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On ^^ the other hand, the L2VPN WG will define how to operate native service- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ service. ^^^^^^^^ ---snip--- The intent with that sentence was specifically to capture use of "native service-layer ... OAM" (i.e.: 802.1ag) "/on top of/ a VPLS or VPWS service", (i.e.: at the service-layer). Does the originally proposed sentence address your concern? If not, how can we modify it to address your concern? Thanks, -shane On Apr 2, 2008, at 6:39 AM, Ali Sajassi (sajassi) wrote: > > Shane, > > Please refer to my reply inline ... > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Shane Amante >> Sent: Tuesday, April 01, 2008 2:31 PM >> To: l2vpn@ietf.org >> Subject: L2VPN (Re-)charter: VPLS OAM >> >> All, >> >> Since there been a variety of comments about the re-charter, >> I'm going to attempt to group related comments and respond to >> them that way. >> Hopefully, this way people can follow along more easily. See >> below for the first response related to VPLS OAM. >> >> ---snip--- >> >> Dinesh, Ali, >> >> ------Dinesh wrote------ >>> "L2VPN's will make use of existing IETF specified >> mechanisms unless > there are technical reasons why the >> existing mechanisms are > insufficient or unnecessary." >>> >>> DM>> Which IETF mechanisms are we referring to? This >> statement seems > quite vague, can we offer some guidance >> around the relevance of this > statement. >> >> Actually, this statement was copied from the PWE3 charter. >> The intent is to state that L2VPN WG will re-use MPLS (or >> L2TPv3) as defined by the MPLS WG for the PSN, PW's as >> defined by PWE3 for service-layer encapsulation, SNMP for >> MIB's, etc. See below for more. >> >> >>> "In particular, the L2VPN WG will define extensions to >> Pseudowire > management (OAM) mechanisms, specifically >> Pseudowire Virtual Circuit > Connectivity Verification >> (VCCV), for VPLS. Those VCCV extensions ' >>> will be reviewed by PWE3 to ensure they are inline with >> the overall > design/architecture of VCCV." >>> >>> DM>> Is it necessary to include this statement in the >> charter? This is > presuming solutions that may not have >> been completely hashed out yet. >>> Isn't the first statement Sufficient in this para "The >> L2VPN WG will > provide extensions of existing protocols >> that will be discussed in > protocol-specific WG's." >> >> You raise a fair point. I am willing to change the "will" to >> a "may" as suggested by Ali, (see below for that change). >> That leaves open the potential of us extending VCCV within >> this proposed charter, rather than having to come back and >> re-charter again or, worse, toss around multiple drafts in >> both PWE3 and L2VPN if we determine a need to extend VCCV. >> Plus, given all the recent work on T-MPLS and T-MPLS OAM, our >> AD's wanted to make it explicit that a portion of VCCV may be >> worked on within L2VPN, so people/other-SDO's know where to >> direct liaisons/questions/etc. >> >> >> ------Ali wrote------ >>> i) "L2VPN's will make use of existing IETF specified >> mechanisms unless > there are technical reasons why the >> existing mechanisms are > insufficient or unnecessary." >>> >>> AS> This statement needs further clarification. I would >> suggest the > following text: "L2VPN solutions will make use >> of existing IETF PWs > and PSN specified mechanisms for >> providing L2VPN services unless there > are technical >> reasons why the existing mechanisms are insufficient or > >> unnecessary. Furthermore, L2VPN solutions will make use of >> native > service mechanisms when applicable for providing >> L2VPN services - > e.g., use of Ethernet OAM for monitoring >> Ethernet native service. >> >> First, the intent of the sentence /is not/ to create an >> exhaustive list of all protocols we may (or may not) end up >> (re-)using from other WG's, or other SDO's for that matter. >> Second, the last sentence you suggested appears to be saying >> that 802.1ag ("native service-layer mechansims") should be >> the only OAM tool for VPLS. I'm pretty confident we don't >> have WG consensus to make that statement in the charter, >> particularly given the "lively" debates that have ensued at >> WG meetings when discussing the two proposed OAM solutions. >> > > Yes, because the intent is not to create and exhaustive list, I used > "e.g.," rather than listing all the protocols. Also, my intention was > not to say "that 802.1ag should be the only OAM tool for VPLS". So, > you > can change "will" to "should" in my second sentence. Basically, all > I am > saying is that if there is already a mechanism for a native service, > then that mechanism should be considered first before attempting to > re-invent the wheel. > >> However, to bring this back to the charter discussion, I >> believe the sentence is OK 'as-is', since it leaves room to >> discuss and make use of alternate mechanisms if "the existing >> mechansisms are insufficent or unnecessary". Specific to >> VPLS OAM, Dinesh has already been highlighting (in his >> presentations at the WG meetings) the areas where .1ag may >> provide a superior solution for *some* aspects of VPLS OAM. >> In addition, Olen's draft >> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a >> more in-depth analysis. Unfortunately, the only debate on >> Olen's draft /on the mailing list/ has been about just one >> aspect of the draft, specifically the H-VPLS reference model, >> which has already been acknowledged as incorrect. We need to >> move on from that and look at the rest of Olen's draft to >> objectively determine what are the strengths & weaknesses of >> either or both (i.e. complementary) OAM approaches if we're >> going to make progress on OAM. >> > > If the intent of this statement is to say: > "that L2VPN WG will re-use MPLS (or L2TPv3) as defined by the MPLS WG > for the PSN, PW's as defined by PWE3 for service-layer encapsulation, > SNMP for MIB's, etc." > As you stated, then, it should be stated as such as the first sentence > of my proposed text: > "L2VPN solutions will make use of existing IETF PW and PSN specified > mechanisms for providing L2VPN services unless there are technical > reasons why the existing mechanisms are insufficient or unnecessary" > My concern is that by having a vague sentence as such, then it makes > it > open to interpretation and some people may claim that VCCV-based OAM > mechanism for VPLS (and Ethernet services) is the preferred mechanism > over native Ethernet OAM (802.1ag/y.1731) because the charter has > stated > so !! > I think we need to select an OAM mechanism for VPLS based on its > technical merit as we are progressing in this direction in the WG. So, > the charter should state that VPLS OAM work is needed without > intentionally/unintentionally favoring one mechanism over the other. > >> >>> ii) "The L2VPN WG will provide extensions of existing >> protocols that > will be discussed in protocol-specific >> WG's. In particular, the L2VPN > WG will define extensions >> to pseudowire management (OAM) mechanisms, > specifically >> Pseudowire Virtual Circuit Connectivity Verification > >> (VCCV), for VPLS. Those VCCV extensions will be reviewed by >> PWE3 to > ensure they are inline with the overall >> design/architecture of VCCV." >>> >>> AS> This statement already assumes that VCCV extensions >> are needed for > VPLS which is not the case. I would prefer >> to either remove 2nd and > 3rd sentences from the above >> para. If we want to keep these sentences, > then we need to >> change "will" to "may" in 2nd sentence. >> >> OK, I'll accept the change in your last sentence, (change >> from "will" to "may" in the second sentence). Specifically, >> I'll reword the charter as >> follows: >> ---snip--- >> The L2VPN WG will provide extensions of existing protocols >> that will be discussed in protocol-specific WG's. In >> particular, the L2VPN WG may define extensions to pseudowire >> management (OAM) mechanisms, specifically Pseudowire Virtual >> Circuit Connectivity Verification (VCCV), for VPLS. Those >> VCCV extensions will be reviewed by PWE3 to ensure they are >> inline with the overall design/architecture of VCCV." >> ---snip--- >> > > O.K. Looks good. > >> >> >>> iii) "Furthermore, the L2VPN WG will not define protocol >> inter-working > between a VPLS or VPWS and native >> service-layer control, OAM or > resiliency mechanisms, as >> those will be defined by the PWE3 WG. On > the other hand, >> the L2VPN WG will define how to operate native > >> service-layer control, OAM or resiliency mechanisms on top of >> a VPLS > or VPWS service." >>> >>> AS> This statement needs to be refined to indicate that >> the > interworking between the native service-layer and its >> associated PW > for the purpose of control, OAM, or >> resiliency mechanisms, shall be > defined by the PWE3 WG. >> However, the interworking between the native > service-layer >> and the VPN service, associated with a group of PWs and > >> their forwarding tables, will be defined by the L2VPN WG when needed. >> >> I'm not sure I understand the intent or need for the last >> sentence you propose. Can you elaborate on it? >> Specifically, I'm trying to understand what might just be >> implementation details irrelevant to L2VPN, say specific to >> the Bridge Module and AC's, vs. some interaction between PW's >> and the Bridge Module or something else. >> > > An example of it would be the dual-homing and redundancy support > between > an 802.1ah access network and a VPLS core; where, 802.1ah access > network > is running L2GP protocol in order to avoid running its MSTP over VPLS > core. In such scenario, upon a topology change, the 802.1ah access > network would signal the PE using MVRP message to indicate the VLANs > that are affected as the result of topology change and if LDP is used > for C-MAC withdraw, then the PE needs to process the MVRP message and > generate LDP MAC withdraw messages for the affected service instances. > > Cheers, > Ali > > >> Thanks, >> >> -shane >> From l2vpn-bounces@ietf.org Wed Apr 2 20:33:15 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527F83A6AB2; Wed, 2 Apr 2008 20:33:15 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835443A688B for ; Wed, 2 Apr 2008 20:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be7+birQgmKI for ; Wed, 2 Apr 2008 20:33:13 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 455F13A6B1E for ; Wed, 2 Apr 2008 20:33:12 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BA8D9268496; Wed, 2 Apr 2008 21:33:14 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-65-140.hlrn.qwest.net [71.215.65.140]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 02 Apr 2008 21:33:14 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.65.140; client-port=1797; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <3C06F693-E020-4A25-AE31-1FF10005C75D@castlepoint.net> From: Shane Amante To: Ali Sajassi (sajassi) In-Reply-To: <483F121CD2155B43B56DB71228DBAF15014D277B@xmb-sjc-239.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN (Re-)charter: Scalability Enhancements Date: Wed, 2 Apr 2008 21:32:58 -0600 References: <483F121CD2155B43B56DB71228DBAF15014D277B@xmb-sjc-239.amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org, BALUS Florin X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Ali, Florin, OK. Based on your input, I've modified #7 as follows: ---cut here--- 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. ---cut here--- -shane On Apr 2, 2008, at 6:58 AM, Ali Sajassi (sajassi) wrote: > > Shane, > > I am O.K. with the proposed text with a slight modification as > suggested > by Florin below. > > Cheers, > Ali > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of BALUS Florin >> Sent: Tuesday, April 01, 2008 10:06 PM >> To: Shane Amante; l2vpn@ietf.org >> Subject: RE: L2VPN (Re-)charter: Scalability Enhancements >> >> Shane, >> I am ok with your suggestions below. >> >> I think the text you proposed (I.e. 7. Enhancements to >> increase the scalability of the VPLS Control Plane and Data >> Plane (e.g.: Forwarding >> Database) of VPLS PE nodes.) addresses also the possibility >> to reduce the number of PWs which are part of the data plane. >> Maybe we can add in there the PWs to address Ali's >> suggestion: i.e. use "(e.g. MAC Forwarding Database, number >> of PWs)" instead of "(e.g. Forwarding Database)"? There are >> possibilities to provide reduction in the number of PWs by >> using a Backbone VPLS infrastructure to carry multiple customer VPNs. >> Florin >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org >> [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Shane Amante >>> Sent: Tuesday, April 01, 2008 4:47 PM >>> To: l2vpn@ietf.org >>> Subject: L2VPN (Re-)charter: Scalability Enhancements >>> >>> Hi Dinesh, Florin & Ali, >>> >>> Please see below. >>> >>> ------Dinesh wrote------ >>>> DM>> We should enhance bullet 7 of scope which currently >> states "7. >>>> Enhancements to increase the scalability of the >> Forwarding Database >>> of > VPLS PE nodes." to at least provide some example of current >>> direction, > similar to some other items in the list. As a >> suggestion >>> "7. >>>> Enhancements to increase the scalability of the >> Forwarding Database >>> of > VPLS PE nodes. This may include using mechanisms >> being defined >>> by IEEE > e.g. 802.1ah." >>> >>> First, we didn't want to list every possible protocol >> throughout the >>> charter that we may end up (re-)using. >>> Second, 802.1ah (at the data >>> plane) is only one direction we're currently headed, there's also >>> Control Plane optimizations as well. In order to >> "future-proof" the >>> charter, I would prefer that we didn't explicitly list 802.1ah. In >>> fact, I like Florin's suggestion that we abstract it further to >>> account for optimizations to not only the Data Plane, but >> also Control >>> Plane. >>> Please see below for that. >>> >>> >>> ------Ali wrote------ >>>> vi) "7. Enhancements to increase the scalability of the >> Forwarding >>>> Database of VPLS PE nodes." >>>> >>>> AS> I would prefer a more explicit language with respect >>> to > scalability such as "scalability of customer MAC >>> addresses and > number of PW" >>> >>> Since this is the "scope" section, how about we keep it >>> slightly more generic than what you suggest? Specifically, >>> what do you think about the language I suggest below in >>> response to Florin? I think it should address your concern here. >>> >>> >>>> vii) "- Define enhancements to increase scalability of >>> VPLS PE nodes, >>>> to provide aggregation of learned customer MAC >> addresses at >>>> VPLS PE's." >>>> >>>> AS> should be changed to " Define enhancements to increase >>> scalability > of VPLS PE nodes, to provide aggregation of >>> learned customer MAC > addresses and to reduce number of PWs >>> at VPLS PE's." >>> >>> What is your definition of, or goal of, "reduce number of >>> PW's at VPLS PE's"? The number of PWE3 VC labels, the number >>> of tLDP sessions, the number of signaling messages exchanged >>> over a set of tLDP sessions or something else? We possibly >>> need something wrt the benefit we're looking to acheive at >>> the Control Plane, but we probably want to be more precise. >>> With that in mind, can you suggest some more crisp text? >>> >>> >>> >>> ------Florin wrote------ >>>> 7. Enhancements to increase the scalability of the >>> Forwarding Database > of VPLS PE nodes. >>>> >>>> FB> I think we should make this text more generic: i.e. 7. >>> Enhancements > to increase VPLS scalability. >>>> This will address any issues that might be raised in the >>> future. In the > milestones we have anyhow two more generic >>> items that are already > looking beyond what the current >>> item 7 is covering: i.e. >>>> Nov 2009 Submit scalability solutions for VPLS >>> Control-Plane to IESG >>>> Nov 2009 Submit scalability solutions for VPLS >>> Data-Plane to IESG >>>> FB> >>> >>> OK, but I think that may be a bit too generic. Can we >>> instead scope it a little bit more as follows: >>> ---cut here--- >>> 7. Enhancements to increase the scalability of the VPLS >>> Control Plane and Data Plane (e.g.: Forwarding Database) of >>> VPLS PE nodes. >>> ---cut here--- >>> >>> Thanks, >>> >>> -shane >>> >> From l2vpn-bounces@ietf.org Wed Apr 2 20:48:30 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA963A6818; Wed, 2 Apr 2008 20:48:30 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E3D3A6768 for ; Wed, 2 Apr 2008 20:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8eFldl2HGaD for ; Wed, 2 Apr 2008 20:48:28 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 695BB3A6818 for ; Wed, 2 Apr 2008 20:48:28 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BD46F268496; Wed, 2 Apr 2008 21:48:30 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-65-140.hlrn.qwest.net [71.215.65.140]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 02 Apr 2008 21:48:30 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.65.140; client-port=2293; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <7ACD3BF0-6608-46BC-9658-CABEF0299DB1@castlepoint.net> From: Shane Amante To: BALUS Florin In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191CA9@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN (Re-)charter: Service Convergence Date: Wed, 2 Apr 2008 21:48:15 -0600 References: <4A5028372622294A99B8FFF6BD06EB7B04191CA9@USDALSMBS03.ad3.ad.alcatel.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Florin, Please see below. On Apr 2, 2008, at 3:39 PM, BALUS Florin wrote: [--snip--] >> ------Florin wrote------ >>> The L2VPN WG scope includes the following: >>> [..] >>> 6. Improved service convergence for multi-homed CE's to VPLS PE's. >>> Specifically, upon failure of a primary path from a CE >> to VPLS PE, >>> initiate a rapid switch-over to an alternate path. If required, >>> interactions with native service-layer resiliency >> mechanisms will be >>> provided via solutions from other IETF WG's such as PWE3. >>> >>> FB> Suggest we modify the text to include also >> multi-homing between 2 >>> VPLS domains, see below an example of text: >>> 6. Improved service convergence for multi-homing >> solutions: CEs to VPLS >>> PEs or between VPLS domains. >> >> Can you clarify this further? Specifically, do you mean the >> following >> two cases: >> a) One CE to two different VPLS PE's in a single AS; and, >> b) One CE to two different VPLS PE's, each in a different AS? >> > > Not really. What I had in mind was more along the following: > a) CEs multi-homed to different VPLS PEs > b) a VPLS domain multi-homed to another VPLS domain: e.g. a VPLS > mesh in > domain 1 multihomed to a VPLS mesh in domain 2. > Examples of criteria that may define what a VPLS domain is: > geographical > (metro, national, international), administrative different > organizations/providers) etc... With respect to (b), isn't one (major?) aspect an Inter-AS use case? If so, hasn't that already been addressed by Sections 4.1 & 4.2 of draft-ietf-l2vpn-signaling-08? From Section 4.2 of that draft, (see second sentence): ---cut here--- Note that the procedures described here will result in the splicing points (S-PEs in the terminology of [I-D.ietf-pwe3-ms-pw-arch]) being co-located with the ASBRs. It is of course possible to have multiple ASBR-ASBR connections between a given pair of ASes. In this case a given PE could choose among the available ASBRs based on a range of criteria, such as IGP metric, local configuration, etc., analogous to choosing an exit point in normal IP routing. The use of multiple ASBRs would lead to greater resiliency (at the timescale of BGP routing convergence) since a PE could select a new ASBR in the event of the failure of the one currently in use. ---cut here--- >> Also, correct me if I'm wrong, but PWE3 has already covered >> multi-homing of a MTU-s to two, different PE-rs'es in >> draft-muley-pwe3-redundancy-02? >> Or, is there addt'l work that L2VPN WG needs to take care of >> specifically for that case? > > draft-muley-pwe3-redundancy (adopted as PWE3 > draft-ietf-pwe3-redundancy-00.txt) can be definitely applied to > optimize > the procedures described in section 10.2 of RFC 4762 (VPLS MTU-s to > PE-rs resiliency). Still I think there is a need to have a discussion > about usage in a VPLS context to ensure interoperability, including an > update on how to reflect the PW transitions in LDP MAC Flush. The current draft-muley already discusses that. Are you suggesting the VPLS use-cases be pulled out into a separate draft and put in L2VPN, (which we'd add a goal/milestone for)? > Also this sort of resiliency (1 MTU-s to 2 PE-rs, triangle like) might > not be enough for the interconnection of two VPLS mesh domains: i.e. > the > MTU-s will be a single point of failure. More like a square > interconnection is required here where 2 VPLS PEs in domain 1 are > connected to 2 VPLS PEs in domain 2. Same question as above, specifically: hasn't l2vpn-signaling already addressed this? >>> Specifically, upon failure of a primary >>> path from a between CEs and VPLS PEs or between VPLS >> domains, initiate a >>> rapid switch-over to an alternate path. If required, >> interactions with >>> native service-layer resiliency mechanisms will be provided via >>> solutions from other IETF WG's such as PWE3. >>> FB> >>> >>> >>> The L2VPN WG currently works on the following tasks: >>> [..] >>> - Identify requirements for multi-homing of CE's to VPLS PE's. >>> elements. Based on these requirements, define solutions for >>> achieving fast convergence after a switchover to an >> alternate path, >>> for example through optimized MAC flushing within a VPLS domain. >>> >>> FB> Suggest changing this one to the following text: >>> - Identify requirements for different multi-homing >> solutions: i.e. CEs >>> to VPLS Pes or between VPLS domains. Based on these >> requirements, define >>> solutions for achieving fast convergence after a switchover to an >>> alternate path, for example through optimized MAC flushing >> within a VPLS >>> domain. >>> FB> >> >> I have the same question here as I do above. Once we're on the same >> page, then I think we can tighten the suggested text a little >> further. >> > > I hope the above answer addressed this one too. Not yet, but we're getting there. :-) Thanks, -shane From l2vpn-bounces@ietf.org Thu Apr 3 02:08:18 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD023A6A6A; Thu, 3 Apr 2008 02:08:18 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C1C3A6F53 for ; Thu, 3 Apr 2008 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh4iaepfX5aE for ; Thu, 3 Apr 2008 02:08:16 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 133963A6BF7 for ; Thu, 3 Apr 2008 02:08:15 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id m3398BUh031662; Thu, 3 Apr 2008 03:08:11 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 04:07:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: Service Convergence Date: Thu, 3 Apr 2008 04:07:08 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191D00@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <7ACD3BF0-6608-46BC-9658-CABEF0299DB1@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: Service Convergence Thread-Index: AciVPZcBZH6EgD6OS8msgw5QRQJgQgAK2jJA From: "BALUS Florin" To: "Shane Amante" X-OriginalArrivalTime: 03 Apr 2008 09:07:22.0371 (UTC) FILETIME=[20759D30:01C8956A] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, See below..=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Wednesday, April 02, 2008 8:48 PM > To: BALUS Florin > Cc: l2vpn@ietf.org > Subject: Re: L2VPN (Re-)charter: Service Convergence >=20 > Florin, >=20 > Please see below. >=20 > On Apr 2, 2008, at 3:39 PM, BALUS Florin wrote: > [--snip--] > >> ------Florin wrote------ > >>> The L2VPN WG scope includes the following: > >>> [..] > >>> 6. Improved service convergence for multi-homed CE's to VPLS PE's. > >>> Specifically, upon failure of a primary path from a CE > >> to VPLS PE, > >>> initiate a rapid switch-over to an alternate path. If required, > >>> interactions with native service-layer resiliency > >> mechanisms will be > >>> provided via solutions from other IETF WG's such as PWE3. > >>> > >>> FB> Suggest we modify the text to include also > >> multi-homing between 2 > >>> VPLS domains, see below an example of text: > >>> 6. Improved service convergence for multi-homing > >> solutions: CEs to VPLS > >>> PEs or between VPLS domains. > >> > >> Can you clarify this further? Specifically, do you mean the=20 > >> following two cases: > >> a) One CE to two different VPLS PE's in a single AS; and, > >> b) One CE to two different VPLS PE's, each in a different AS? > >> > > > > Not really. What I had in mind was more along the following: > > a) CEs multi-homed to different VPLS PEs > > b) a VPLS domain multi-homed to another VPLS domain: e.g. a VPLS =20 > > mesh in > > domain 1 multihomed to a VPLS mesh in domain 2. > > Examples of criteria that may define what a VPLS domain is: =20 > > geographical > > (metro, national, international), administrative different > > organizations/providers) etc... >=20 > With respect to (b), isn't one (major?) aspect an Inter-AS=20 > use case? =20 > If so, hasn't that already been addressed by Sections 4.1 & 4.2 of =20 > draft-ietf-l2vpn-signaling-08? From Section 4.2 of that draft, (see =20 > second sentence): > ---cut here--- > Note that the procedures described here will result in the splicing =20 > points (S-PEs in the terminology of=20 > [I-D.ietf-pwe3-ms-pw-arch]) being =20 > co-located with the ASBRs. It is of course possible to have multiple =20 > ASBR-ASBR connections between a given pair of ASes. In this case a =20 > given PE could choose among the available ASBRs based on a range of =20 > criteria, such as IGP metric, local configuration, etc.,=20 > analogous to =20 > choosing an exit point in normal IP routing. The use of=20 > multiple ASBRs =20 > would lead to greater resiliency (at the timescale of BGP routing =20 > convergence) since a PE could select a new ASBR in the event of the =20 > failure of the one currently in use. > ---cut here--- >=20 >=20 This addresses the case of redundant MS-PW path between two VPLS PEs. Assume you have the following scenario: VPLS Mesh 1 - PE1 - redundant MS-PW path as in l2vpn signaling - PE2 - VPLS Mesh 2. If PE1 or PE2 fails there is no way to communicate between the 2 meshes, it does not matter how many paths you have in between them. We need to have at least other 2 gateway Pes - e.g. PE1' and PE2' - to totally eliminate single point of failure at both sides. > >> Also, correct me if I'm wrong, but PWE3 has already covered > >> multi-homing of a MTU-s to two, different PE-rs'es in > >> draft-muley-pwe3-redundancy-02? > >> Or, is there addt'l work that L2VPN WG needs to take care of > >> specifically for that case? > > > > draft-muley-pwe3-redundancy (adopted as PWE3 > > draft-ietf-pwe3-redundancy-00.txt) can be definitely applied to =20 > > optimize > > the procedures described in section 10.2 of RFC 4762 (VPLS MTU-s to > > PE-rs resiliency). Still I think there is a need to have a=20 > discussion > > about usage in a VPLS context to ensure interoperability,=20 > including an > > update on how to reflect the PW transitions in LDP MAC Flush. >=20 > The current draft-muley already discusses that. Are you suggesting =20 > the VPLS use-cases be pulled out into a separate draft and put in =20 > L2VPN, (which we'd add a goal/milestone for)? >=20 >=20 > > Also this sort of resiliency (1 MTU-s to 2 PE-rs, triangle=20 > like) might > > not be enough for the interconnection of two VPLS mesh=20 > domains: i.e. =20 > > the > > MTU-s will be a single point of failure. More like a square > > interconnection is required here where 2 VPLS PEs in domain 1 are > > connected to 2 VPLS PEs in domain 2. >=20 > Same question as above, specifically: hasn't l2vpn-signaling already =20 > addressed this? >=20 >=20 >=20 > >>> Specifically, upon failure of a primary > >>> path from a between CEs and VPLS PEs or between VPLS > >> domains, initiate a > >>> rapid switch-over to an alternate path. If required, > >> interactions with > >>> native service-layer resiliency mechanisms will be provided via > >>> solutions from other IETF WG's such as PWE3. > >>> FB> > >>> > >>> > >>> The L2VPN WG currently works on the following tasks: > >>> [..] > >>> - Identify requirements for multi-homing of CE's to VPLS PE's. > >>> elements. Based on these requirements, define solutions for > >>> achieving fast convergence after a switchover to an > >> alternate path, > >>> for example through optimized MAC flushing within a VPLS domain. > >>> > >>> FB> Suggest changing this one to the following text: > >>> - Identify requirements for different multi-homing > >> solutions: i.e. CEs > >>> to VPLS Pes or between VPLS domains. Based on these > >> requirements, define > >>> solutions for achieving fast convergence after a switchover to an > >>> alternate path, for example through optimized MAC flushing > >> within a VPLS > >>> domain. > >>> FB> > >> > >> I have the same question here as I do above. Once we're=20 > on the same > >> page, then I think we can tighten the suggested text a little =20 > >> further. > >> > > > > I hope the above answer addressed this one too. >=20 > Not yet, but we're getting there. :-) >=20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Thu Apr 3 04:38:36 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63CC28C614; Thu, 3 Apr 2008 04:38:36 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98FE28C149; Thu, 3 Apr 2008 04:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fceOgAdv8viz; Thu, 3 Apr 2008 04:38:30 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 27D5528C614; Thu, 3 Apr 2008 04:38:28 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 03 Apr 2008 15:17:37 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 14:38:31 +0300 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.263.0; Thu, 3 Apr 2008 14:38:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on the status of Y.1711 and RFC3429 Date: Thu, 3 Apr 2008 14:38:30 +0300 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> In-Reply-To: <47ECB132.7090200@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on the status of Y.1711 and RFC3429 Thread-Index: AciQsMzOn/guAnfHTHCRQvl2K2wxvAEzhEzw References: <47ECB132.7090200@pi.se> From: Alexander Vainshtein To: "Loa Andersson" , , X-OriginalArrivalTime: 03 Apr 2008 11:38:31.0350 (UTC) FILETIME=[3DFDFD60:01C8957F] Cc: L2VPN , l3vpn@ietf.org, ccamp , pwe3 , David Ward , Ross Callon X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Loa, George and all, ECI Telecom has implemented ITU-T recommendation Y.1711 using=20 Label 14 as defined in RFC 3429 in its XDM (TM) products family.=20 The corresponding products have been deployed in live=20 networks, and their Y.1711-related functionality is now in=20 operational use. Based on this, we (ECI) object to deprecation of the Label 14=20 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Sasha=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 11:50 AM > To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 >=20 > All, >=20 > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. >=20 > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. >=20 > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. >=20 > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. >=20 > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. >=20 > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" >=20 > ITU-T has sent out a question along the same lines, see the included > mail below. >=20 > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. >=20 > Loa and George >=20 >=20 > ------------------- included mail ------------------------------------ >=20 > All users/implementers of recommendation Y.1711, >=20 > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. >=20 > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. >=20 > This makes the OAM alert label directly visible at the > sink MEP. >=20 > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. >=20 > The OAM alert label will point to an "opcode" at the bottom > of the stack. > ------------------------------------------ >=20 > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. >=20 > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? >=20 > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). >=20 > Please send me (or this list) your response ASAP. >=20 > Kind regards, Huub van Helvoort, your rapporteur. >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 From l2vpn-bounces@ietf.org Thu Apr 3 05:15:54 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD79128C5C9; Thu, 3 Apr 2008 05:15:54 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD08B3A6F87 for ; Thu, 3 Apr 2008 05:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMMQKrOHSfBF for ; Thu, 3 Apr 2008 05:15:49 -0700 (PDT) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id 395C928C6AE for ; Thu, 3 Apr 2008 05:15:46 -0700 (PDT) Received: (qmail 92569 invoked from network); 3 Apr 2008 12:15:49 -0000 Received: from unknown (HELO ShahramPC) (davari@rogers.com@99.238.119.231 with login) by smtp113.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2008 12:15:48 -0000 X-YMail-OSG: hhGjG10VM1kOm_OkMcCxHUZifwfG1XXhUPAA4Bh55BdkAYGxvi1X1eejm9jQYfKoKg-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: "'Loa Andersson'" , , References: <47ECB132.7090200@pi.se> <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> Subject: RE: [PWE3] Question on the status of Y.1711 and RFC3429 Date: Thu, 3 Apr 2008 08:15:47 -0400 Message-ID: <001301c89584$7402a050$5c07e0f0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQsMzOn/guAnfHTHCRQvl2K2wxvAEzhEzwAAE/PFA= Content-Language: en-ca Cc: 'L2VPN' , 'ccamp' , 'pwe3' , l3vpn@ietf.org, 'David Ward' X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Loa, George and all, TPACK has implemented Y.1711 using label 14 and TPACK's customers have reported Y.1711 has been deployed and in operation by the network operators using their products. Therefore TPACK objects to deprecation of the Label 14 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Shahram Davari TPACK -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: April-03-08 7:39 AM To: Loa Andersson; swallow@cisco.com; mpls@ietf.org Cc: L2VPN; l3vpn@ietf.org; ccamp; pwe3; David Ward Subject: Re: [PWE3] Question on the status of Y.1711 and RFC3429 Loa, George and all, ECI Telecom has implemented ITU-T recommendation Y.1711 using Label 14 as defined in RFC 3429 in its XDM (TM) products family. The corresponding products have been deployed in live networks, and their Y.1711-related functionality is now in operational use. Based on this, we (ECI) object to deprecation of the Label 14 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] > On Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 11:50 AM > To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 > > All, > > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. > > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. > > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. > > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. > > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. > > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" > > ITU-T has sent out a question along the same lines, see the included > mail below. > > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. > > Loa and George > > > ------------------- included mail ------------------------------------ > > All users/implementers of recommendation Y.1711, > > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. > > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. > > This makes the OAM alert label directly visible at the > sink MEP. > > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. > > The OAM alert label will point to an "opcode" at the bottom > of the stack. > ------------------------------------------ > > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. > > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? > > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). > > Please send me (or this list) your response ASAP. > > Kind regards, Huub van Helvoort, your rapporteur. > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From l2vpn-bounces@ietf.org Thu Apr 3 15:11:29 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA01C3A6D54; Thu, 3 Apr 2008 15:11:29 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4953A6D54 for ; Thu, 3 Apr 2008 15:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3VLI2CSwCPo for ; Thu, 3 Apr 2008 15:11:28 -0700 (PDT) Received: from audl952.usa.alcatel.com (audl952.usa.alcatel.com [143.209.238.159]) by core3.amsl.com (Postfix) with ESMTP id 2CD7E3A6CEF for ; Thu, 3 Apr 2008 15:11:28 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id m33MBP3q010112; Thu, 3 Apr 2008 16:11:25 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.11]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 17:11:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: Inter-AS (+ multicast) Date: Thu, 3 Apr 2008 17:11:10 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04191EDC@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <47F40CD5.3000003@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: Inter-AS (+ multicast) Thread-Index: AciVE3ak75OQJSzPRbe7495Do/w8NAAv8SZg From: "BALUS Florin" To: "Shane Amante" , X-OriginalArrivalTime: 03 Apr 2008 22:11:25.0298 (UTC) FILETIME=[A83A9D20:01C895D7] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Shane, Your suggestions below look good, I just have a comment on the following text: "8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS unicast VPLS and VPWS L2VPN's, in addition to Inter-AS multicast VPLS and VPMS Layer-2 VPN's."=20 It is understood that there may be other use cases or VPLS solutions where additional multicast optimizations may be required as described in the drafts you listed below.=20 Still "Inter-AS unicast VPLS" suggests that the VPLS solutions developed up to now where not able to transport multicast at all. Or I am aware of some large HVPLS deployments handling multicast applications, including heavy ones like IP TV. Will it be possible to use instead the following text for 8: "8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's."=20 Thanks, Florin > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Wednesday, April 02, 2008 3:47 PM > To: l2vpn@ietf.org > Subject: L2VPN (Re-)charter: Inter-AS (+ multicast) >=20 > Hi Loa, Florin, >=20 > ------Loa wrote------ > > - for discovery specifiactions > > -- does this include automated Inter-AS discovery >=20 > I'm not sure I understand what part of the charter you're=20 > asking about.=20 > Can you point out what section(s) you referring to, (scope,=20 > tasks worked on, etc.)? >=20 >=20 > > - I would split the > > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > > milestone into two different mailstones >=20 > This may not be necessary. See below. >=20 >=20 > ------Florin wrote------ > > Goals and Milestones: > > [..] > > FB> We are missing here L2VPN Auto-discovery, Signaling=20 > and Inter-AS > > (see draft-ietf-l2vpn-signaling-08.txt). This was already=20 > submitted to > > IESG and is waiting in the RFC queue. Suggest adding the=20 > following item: > > > > "Done Submit L2VPN Auto-discovery, Signaling and Inter-AS to IESG" > > [..] > > > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > > FB> I thought we already have these items addressed in > > draft-ietf-l2vpn-signaling-08.txt ("Provisioning,=20 > Autodiscovery, and > > Signaling in L2VPNs"), currently in the RFC queue. >=20 > Good point, however that draft largely only covers signaling for=20 > Inter-AS unicast L2VPN's. It does not cover optimized forwarding of=20 > multicast within Inter-AS VPLS or VPMS. What about the following=20 > suggestion? >=20 > In "Scope", we change #8 to be as follows: > ---cut here--- > 8. Define requirements and solutions for Auto-Discovery and Signaling > of Inter-AS unicast VPLS and VPWS L2VPN's, in addition=20 > to Inter-AS > multicast VPLS and VPMS Layer-2 VPN's. > ---cut here--- >=20 > The above would capture the existing, completed work in=20 > draft-ietf-l2vpn-signaling-08 for Auto-Discovery and=20 > Signaling of Intra-=20 > and Inter-AS VPWS and VPLS L2VPN's. In addition, it should=20 > also capture=20 > the in-flight work on optimized multicast, both Intra- and=20 > Inter-AS, for=20 > VPLS and VPMS in the following drafts: > - draft-ietf-l2vpn-vpls-mcast-reqts-05 > - draft-ietf-l2vpn-vpls-mcast-03 > - draft-raggarwa-l2vpn-p2mp-pw-00 -- assuming PWE3 & L2VPN=20 > successfully=20 > charter work on p2mp PW's and l2vpn's > - TBD draft for VPMS l2vpn requirements >=20 > I really don't think it's necessary to create separate=20 > goals/milestones=20 > for every solution calling out that it's specific for Intra- or=20 > Inter-AS, since most (all?) existing work has included=20 > Inter-AS anyway.=20 > (Of course, I am making a minor exception for the l2vpn-signaling=20 > draft down below). >=20 > In "Goals and Milestones": > ---cut here--- > As you suggested, add this: > Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS > VPLS and VPWS Layer-2 VPN's > [..] > Also, as you suggested, delete this milestone: > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > ---cut here--- >=20 > The Intra- and Inter-AS multicast work should already be reflected in=20 > these milestones, (no changes to these): > ---cut here--- > Nov 2008 Submit multicast optimization solutions for VPLS to IESG >=20 > Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) > requirements to IESG >=20 > Nov 2009 Submit Auto-Discovery solution for VPMS to IESG > ---cut here--- >=20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Thu Apr 3 16:03:28 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9F128C29C; Thu, 3 Apr 2008 16:03:28 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C8D3A6D03 for ; Thu, 3 Apr 2008 16:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY1TqcZYV4qL for ; Thu, 3 Apr 2008 16:03:24 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 64F4428C29C for ; Thu, 3 Apr 2008 16:03:23 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id CD1CA2680CE; Thu, 3 Apr 2008 17:03:27 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Thu, 03 Apr 2008 17:03:27 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=54198; data-bytes=0 Message-ID: <47F5623E.9010907@castlepoint.net> Date: Thu, 03 Apr 2008 17:03:26 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: BALUS Florin Subject: Re: L2VPN (Re-)charter: Inter-AS (+ multicast) References: <4A5028372622294A99B8FFF6BD06EB7B04191EDC@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191EDC@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Florin, Your suggestion of rewording #8 looks OK to me. Accepted. -shane BALUS Florin wrote: > Hi Shane, > > Your suggestions below look good, I just have a comment on the following > text: > "8. Define requirements and solutions for Auto-Discovery and Signaling > of Inter-AS unicast VPLS and VPWS L2VPN's, in addition to Inter-AS > multicast VPLS and VPMS Layer-2 VPN's." > > It is understood that there may be other use cases or VPLS solutions > where additional multicast optimizations may be required as described in > the drafts you listed below. > > Still "Inter-AS unicast VPLS" suggests that the VPLS solutions developed > up to now where not able to transport multicast at all. Or I am aware of > some large HVPLS deployments handling multicast applications, including > heavy ones like IP TV. Will it be possible to use instead the following > text for 8: > > "8. Define requirements and solutions for Auto-Discovery and Signaling > of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for > multicast-optimized VPLS and VPMS Layer-2 VPN's." > > Thanks, > Florin > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Shane Amante >> Sent: Wednesday, April 02, 2008 3:47 PM >> To: l2vpn@ietf.org >> Subject: L2VPN (Re-)charter: Inter-AS (+ multicast) >> >> Hi Loa, Florin, >> >> ------Loa wrote------ >> > - for discovery specifiactions >> > -- does this include automated Inter-AS discovery >> >> I'm not sure I understand what part of the charter you're >> asking about. >> Can you point out what section(s) you referring to, (scope, >> tasks worked on, etc.)? >> >> >> > - I would split the >> > > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG >> > milestone into two different mailstones >> >> This may not be necessary. See below. >> >> >> ------Florin wrote------ >> > Goals and Milestones: >> > [..] >> > FB> We are missing here L2VPN Auto-discovery, Signaling >> and Inter-AS >> > (see draft-ietf-l2vpn-signaling-08.txt). This was already >> submitted to >> > IESG and is waiting in the RFC queue. Suggest adding the >> following item: >> > >> > "Done Submit L2VPN Auto-discovery, Signaling and Inter-AS to IESG" >> > [..] >> > >> > Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG >> > FB> I thought we already have these items addressed in >> > draft-ietf-l2vpn-signaling-08.txt ("Provisioning, >> Autodiscovery, and >> > Signaling in L2VPNs"), currently in the RFC queue. >> >> Good point, however that draft largely only covers signaling for >> Inter-AS unicast L2VPN's. It does not cover optimized forwarding of >> multicast within Inter-AS VPLS or VPMS. What about the following >> suggestion? >> >> In "Scope", we change #8 to be as follows: >> ---cut here--- >> 8. Define requirements and solutions for Auto-Discovery and Signaling >> of Inter-AS unicast VPLS and VPWS L2VPN's, in addition >> to Inter-AS >> multicast VPLS and VPMS Layer-2 VPN's. >> ---cut here--- >> >> The above would capture the existing, completed work in >> draft-ietf-l2vpn-signaling-08 for Auto-Discovery and >> Signaling of Intra- >> and Inter-AS VPWS and VPLS L2VPN's. In addition, it should >> also capture >> the in-flight work on optimized multicast, both Intra- and >> Inter-AS, for >> VPLS and VPMS in the following drafts: >> - draft-ietf-l2vpn-vpls-mcast-reqts-05 >> - draft-ietf-l2vpn-vpls-mcast-03 >> - draft-raggarwa-l2vpn-p2mp-pw-00 -- assuming PWE3 & L2VPN >> successfully >> charter work on p2mp PW's and l2vpn's >> - TBD draft for VPMS l2vpn requirements >> >> I really don't think it's necessary to create separate >> goals/milestones >> for every solution calling out that it's specific for Intra- or >> Inter-AS, since most (all?) existing work has included >> Inter-AS anyway. >> (Of course, I am making a minor exception for the l2vpn-signaling >> draft down below). >> >> In "Goals and Milestones": >> ---cut here--- >> As you suggested, add this: >> Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS >> VPLS and VPWS Layer-2 VPN's >> [..] >> Also, as you suggested, delete this milestone: >> Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG >> ---cut here--- >> >> The Intra- and Inter-AS multicast work should already be reflected in >> these milestones, (no changes to these): >> ---cut here--- >> Nov 2008 Submit multicast optimization solutions for VPLS to IESG >> >> Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) >> requirements to IESG >> >> Nov 2009 Submit Auto-Discovery solution for VPMS to IESG >> ---cut here--- >> >> Thanks, >> >> -shane >> From l2vpn-bounces@ietf.org Fri Apr 4 02:42:46 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EE628C6F3; Fri, 4 Apr 2008 02:42:46 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B7F28C6D1 for ; Fri, 4 Apr 2008 02:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2LwVl4vEw8t for ; Fri, 4 Apr 2008 02:42:42 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id ED14B28C6CF for ; Fri, 4 Apr 2008 02:42:39 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JhiRX-0001h8-8O for l2vpn@ietf.org; Fri, 04 Apr 2008 11:42:43 +0200 Received: from h4n2fls31o874.telia.com ([213.66.236.4]:60737 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JhiRV-0001gi-Od; Fri, 04 Apr 2008 11:42:41 +0200 Message-ID: <47F5F7EF.5030906@pi.se> Date: Fri, 04 Apr 2008 11:42:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org, ccamp , l1vpn@ietf.org, pwe3 , L2VPN Subject: conclusion on the status of Y.1711 and RFC3429 X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , David Ward X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org All, on March 28 the MPLS WG chairs polled the several working group mailing lists about the state of Y.1711 and RFC3429 implementations and deployments. Our conclusion is that there is enough implementations and deployments of Y.1711 and hence it is not possible to, for time being, deprecate label 14 or obsolete RFC3429. This conclusion however leaves with the issue of investigating if Y.1711, other ITU-T documents and RFC3429 is well enough aligned or if updates is needed. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From l2vpn-bounces@ietf.org Fri Apr 4 08:16:34 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432303A6A21; Fri, 4 Apr 2008 08:16:34 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5035A3A6A21 for ; Fri, 4 Apr 2008 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgI3JHeW1foD for ; Fri, 4 Apr 2008 08:16:29 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 8028E3A68BA for ; Fri, 4 Apr 2008 08:16:29 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m34FGQJq027685 for ; Fri, 4 Apr 2008 09:16:29 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.11]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 4 Apr 2008 10:16:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt Date: Fri, 4 Apr 2008 10:16:26 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04192006@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt Thread-Index: AciWZtmi0HmMvDNDR2yw3B0lM3AsYg== From: "AISSAOUI Mustapha" To: X-OriginalArrivalTime: 04 Apr 2008 15:16:28.0194 (UTC) FILETIME=[DACFC820:01C89666] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Himanshu and all, I am sorry I am bringing this late in the game but I believe there is an issue with the signaling procedures of the IP PW in this draft. Specifically, Section 6.2 states the following: " As defined in [RFC4447], when processing a received PW FEC, the=20 PE matches the PW ID and PW type with the locally configured PW=20 ID and PW Type. If there is a match, and if the PW Type is IP=20 Layer2 Transport the PE further checks for the presence of an=20 Address List TLV (as specified in [RFC 3036]) in the optional=20 parameter TLVs. If absent, a Label Release message is issued=20 with a Status Code meaning "IP Address of the CE is absent"=20 [note: Status Code 0x0000002D is pending IANA allocation] to=20 reject the PW establishment. " I do not think we can mandate that if the Address List TLV was not present, the label must be released. I am saying this as the IP PW type has been defined in RFC 4447 and there is no such a constraint on the setup of this type of PW in this RFC.=20 There are deployed implementations which use the IP PW with static CE address configurations and which will just not check for the address list TLV. Yet, these implementations are compliant to RFC 4447. I can think of one way of addressing the backward compatibility with RFC 4447 and that is to follow what we have done for the PW Status TLV. This TLV is included in the Label Mapping Message with the I-bit (ignore bit) set. Only if both PEs have included the Address List TLV in the Label Mapping message that it can be used subsequently inside a Notification message. This issue also exists in the IPLS draft. Regards, Mustapha.=20 From l2vpn-bounces@ietf.org Sun Apr 6 21:03:15 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83D43A6B66; Sun, 6 Apr 2008 21:03:15 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6153A6E48 for ; Sun, 6 Apr 2008 21:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C97Br1hya5c7 for ; Sun, 6 Apr 2008 21:03:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 208B53A6E4D for ; Sun, 6 Apr 2008 21:03:01 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Sun, 06 Apr 2008 21:02:36 PDT Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 21:02:44 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 21:01:04 -0700 Received: from 172.23.4.253 ([172.23.4.253]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 7 Apr 2008 04:01:04 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Sun, 06 Apr 2008 21:02:11 -0700 Subject: Re: L2VPN (Re-)charter: VPLS OAM From: Nitin Bahadur To: BALUS Florin , "Ali Sajassi (sajassi)" Message-ID: Thread-Topic: L2VPN (Re-)charter: VPLS OAM Thread-Index: AciYZCev7ppLqQARUEOlcyglULF3pA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Apr 2008 04:01:04.0479 (UTC) FILETIME=[0008D6F0:01C89864] Cc: l2vpn@ietf.org, Shane Amante X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Florin/Ali, Good to know that there is agreement here :-) The goal for VPLS-OAM should be to start from where we are today, see what is needed, identify the best solution and then proceed to make enhancements (Ethernet OAM/MPLS-OAM) based on solutions identified. Note that in some cases multiple OAM mechanisms can *peacefully* co-exist....like today...some customers use Ethernet OAM (802.3ah/802.1ag) and some use BFD (Ethernet OAM is L2 while BFD is application layer). Not looking to start a debate here, but when (in the future) we go ahead and start looking at solutions, we should look at things from not only an architectural perspective, but also from a service provider's perspective as what kind of an OAM solution helps them most. At times we have seen that service providers come up and say that the OAM solutions do not meet their needs...which translates to a "call-for-action for service providers" to participate in solutions development and raise their concerns earlier than later. Thanks Nitin On 4/2/08 12:10 PM, "BALUS Florin" wrote: > In L2VPN WG we should start from the premise that PWE3 and IP/MPLS PSN > infrastructure is in place so the effort should be focused on extending > the available tools - e.g. PW3 or IP/MPLS OAM, VPLS LDP MAC Withdraw - > not on adapting native services to do the job. We need to make sure this > is clearly reflected in the charter. >>> I think the important aspect that Shane is trying to capture in the >>> L2VPN charter is that our focus is to address required >> extensions to >>> the mechanisms specific to the PSNs (IP/MPLS) and PWE3 >> infrastructure >>> that is common to both VPLS and VPWS. >> >> So, we should capture it as such as I suggested rather and >> avoid having a vague statement. From l2vpn-bounces@ietf.org Mon Apr 7 07:51:05 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A4D28C325; Mon, 7 Apr 2008 07:51:05 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2ED3A6937 for ; Mon, 7 Apr 2008 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+rlzbFECdL4 for ; Mon, 7 Apr 2008 07:51:03 -0700 (PDT) Received: from napoleon.monoski.com (black.monoski.com [63.227.123.238]) by core3.amsl.com (Postfix) with ESMTP id 054D628C0E4 for ; Mon, 7 Apr 2008 07:51:02 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id m37EovPU027043; Mon, 7 Apr 2008 08:50:58 -0600 (MDT) Message-ID: <47FA34D1.6030502@cisco.com> Date: Mon, 07 Apr 2008 08:50:57 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: Shane Amante Subject: Re: L2VPN WG (Re-)charter References: <47F13154.6070703@castlepoint.net> In-Reply-To: <47F13154.6070703@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, The charter looks good , but I would like to propose the following small change: OLD: The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG will define extensions to pseudowire management (OAM) mechanisms, specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV. NEW: The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG will define extensions to pseudowire management (OAM) mechanisms, specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. ^^^^^^^^^ The concern here is that in order to do some convoluted OAM method, somebody will come along, and try to do something that is not in the MPLS architecture. Thanks. Luca Shane Amante wrote: > Hi Folks, > > It's been just over two weeks and we haven't heard any support for or > comments on the suggested charter below. This is just a gentle > reminder to speak up in order that current/in-flight and future > projects aren't delayed or dropped. > > -shane > > > Shane Amante wrote: >> Hi, >> >> As mentioned during the WG meeting at IETF 71 in Philadelphia, below >> is a proposed draft of a new charter for the L2VPN WG. Included are >> the following new items: >> - Multicast >> - Scalability >> - Multi-homing / Service Convergence >> - Inter-AS >> >> Please take a look at the entire text, including suggested dates for >> deliverables & milestones. >> >> Please send any questions, clarifications or suggested changes to the >> WG mailing list. If you believe the new charter (below) is fine >> "as-is", then please indicate your support to the WG mailing list, as >> well. >> >> We would like to set a time-limit for discussion and agreement of the >> new charter, in order that we can get back to the business at hand. >> As such, let me propose that we wrap-up discussion and gauge (rough) >> consensus by Friday, April 25, 1700 MDT (UTC -6), which is a little >> over 1 month from now. >> >> Thanks, >> >> -shane & Vach >> >> ---cut here--- >> >> The L2VPN working group is responsible for defining and specifying a >> limited number of solutions for supporting provider-provisioned Layer-2 >> Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the >> following: >> >> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates >> an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched >> Network (PSN). >> >> 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that >> provides >> point-to-point connectivity for a variety of link layers, including >> Frame Relay, ATM, Ethernet, PPP, etc., across an IP or >> MPLS-enabled IP >> PSN. >> >> 3. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" >> service over an IP or MPLS-enabled PSN. This service is similar to >> VPWS because it supports a variety of link-layer protocols on the >> Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. >> IP-only L2VPN's are different from both VPLS and VPWS because unicast >> Layer-2 frames containing IP data packets, either IPv4 or IPv6, >> are de- >> encapsulated leaving only the IP data packet to be transmitted over >> the PSN. An IP-only L2VPN service also differs from L3VPN service, >> since no routing protocol operates between the PE and CE; >> furthermore, >> connectivity from CE to CE is provided via an emulated Layer-2 >> service >> over the PSN, which results in the CE's appearing to be directly >> attached to each other at Layer-2. The WG will address two specific >> types of IP-only L2VPN: >> >> a) Those with Attachment Circuits (ACs) that use the same Layer 2 >> framing at all attachment points in the same L2VPN; and, >> >> b) Those with ACs that use different Layer 2 framing at various >> attachment points in the same L2VPN. For (b), inter-working between >> link-layers is strictly out of scope beyond that which is minimally >> necessary to ensure that IP packets are transported from an AC of one >> type, across the IP or MPLS-enabled IP PSN, and to an AC of another >> type in as transparent a manner as possible to the CEs on both sides >> of the service. >> >> VPLS and VPWS operate over Pseudowires (PWs) as defined by the PWE3 WG. >> As with a single PW, an L2VPN emulates a "native" service over a PSN >> that >> is reasonably faithful to, but may not be entirely indistinguishable >> from, the native service itself. Further, following in the >> "edge-to-edge" >> nature of the PWs that it uses, the L2VPN WG will not define any new >> mechanisms which exert control over the underlying PSN. When necessary >> it may, however, recommend or require the use of existing PSN QoS and >> path control mechanisms between PW endpoints which make up the L2VPN. >> >> L2VPN's will make use of existing IETF specified mechanisms unless there >> are technical reasons why the existing mechanisms are insufficient or >> unnecessary. >> >> The L2VPN WG is responsible for specification of the discovery and >> membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as >> well >> as the membership of CE devices to a specific instance of a L2VPN. >> >> The L2VPN WG will provide extensions of existing protocols that will be >> discussed in protocol-specific WG's. In particular, the L2VPN WG >> will define extensions to pseudowire management (OAM) mechanisms, >> specifically Pseudowire Virtual Circuit Connectivity Verification >> (VCCV), >> for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they >> are inline with the overall design/architecture of VCCV. >> >> The L2VPN WG will not define new encapsulations, control (set-up, >> configuration, maintenance or tear-down), or resiliency mechanisms >> specifically related to pseudowires, because those must be defined by >> the >> PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- >> working between a VPLS or VPWS and native service-layer control, OAM or >> or resiliency mechanisms, as those will be defined by the PWE3 WG. On >> the other hand, the L2VPN WG will define how to operate native service- >> layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS >> service. >> >> The L2VPN WG scope includes the following: >> >> 1. Discovery of PE's participating in a Layer-2 VPN and the associated >> topology required for connectivity of the VPLS or VPWS service. >> >> 2. Signaling of information related to the discovery and membership of >> PE's within a L2VPN. These procedures must use PWE3 control and >> management procedures, or define requirements for extensions of PWE3 >> protocols to suit the needs of an L2VPN. Once those requirements are >> reviewed by the L2VPN WG, they should be provided to the PWE3 WG to >> derive solutions. >> >> 3. MIB's for Layer-2 VPN solutions. >> >> 4. Specification of requirements and framework that will define >> Operations >> Administration and Management (OAM) procedures for VPLS and VPWS >> VPN's, >> related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. >> In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS >> VPN's. >> >> 5. Mechanisms to permit optimization of multicast data traffic within >> a VPLS or VPWS VPN over an IP/MPLS PSN. >> >> 6. Improved service convergence for multi-homed CE's to VPLS PE's. >> Specifically, upon failure of a primary path from a CE to VPLS PE, >> initiate a rapid switch-over to an alternate path. If required, >> interactions with native service-layer resiliency mechanisms will be >> provided via solutions from other IETF WG's such as PWE3. >> >> 7. Enhancements to increase the scalability of the Forwarding >> Database of >> VPLS PE nodes. >> >> 8. Definition of requirements and solutions for Inter-AS VPLS and VPWS >> services. >> >> The L2VPN WG currently works on the following tasks: >> >> - Define MIB's appropriate for each type of Layer-2 VPN. >> >> - Specification of Operations Administration and Management (OAM) >> mechanisms for VPLS, VPWS and IP-only VPN's. >> >> - Specification of procedures to permit optimization of L2VPN multicast >> data traffic within the PSN. >> >> - Define enhancements to increase scalability of VPLS PE nodes, to >> provide aggregation of learned customer MAC addresses at VPLS PE's. >> >> - Identify requirements for multi-homing of CE's to VPLS PE's. >> elements. Based on these requirements, define solutions for achieving >> fast convergence after a switchover to an alternate path, for example >> through optimized MAC flushing within a VPLS domain. >> >> - Identify requirements for Inter-AS VPLS and VPWS services. Define >> Inter-AS enhancements to VPLS and VPWS based on these requirements. >> >> Where necessary, the WG will coordinate its activities with IEEE 802.1. >> >> Goals and Milestones: >> >> Done Submit L2 requirements to IESG for publication as >> Informational RFC >> Done Identify VPLS and VPWS solutions for the WG >> Done Submit L2 framework to IESG for publication as Informational RFC >> Done Submit VPLS solution documents to IESG >> Done Submit VPWS solution documents to IESG >> Done Submit an I-D on OAM requirements for VPLS >> Done Submit an I-D on OAM requirements for VPWS >> Done Submit an I-D describing MIB for VPLS >> Done Submit an I-D describing MIB for VPWS >> >> Mar 2008 Submit IP-only L2VPN solution documents to IESG >> >> Nov 2008 Submit MAC learning optimization solutions for VPLS to IESG >> >> Nov 2008 Submit multicast optimization solutions for VPLS to IESG >> >> Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) >> requirements to IESG >> >> Mar 2009 Submit OAM solutions for VPWS to IESG >> Mar 2009 Submit OAM solutions for VPLS to IESG >> Mar 2009 Submit OAM solutions for IP-only L2VPN to IESG >> >> Jul 2009 Submit MIB for VPLS to IESG >> Jul 2009 Submit MIB for VPWS to IESG >> Jul 2009 Submit MIB for IP-only L2VPN to IESG >> >> Nov 2009 Submit Auto-Discovery solution for VPMS to IESG >> >> Nov 2009 Submit scalability solutions for VPLS Control-Plane to IESG >> Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG >> >> Jul 2010 Submit VPLS service convergence improvement solutions to >> IESG >> >> Jul 2010 Submit VPLS multi-homing solutions to IESG >> >> Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG > From l2vpn-bounces@ietf.org Mon Apr 7 21:19:37 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A3A28C2BF; Mon, 7 Apr 2008 21:19:37 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDB33A6BC5 for ; Mon, 7 Apr 2008 21:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii+TwHawB4jq for ; Mon, 7 Apr 2008 21:19:35 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id DD03828C258 for ; Mon, 7 Apr 2008 21:19:34 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id CB3E026803D; Mon, 7 Apr 2008 22:19:49 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-86-203.hlrn.qwest.net [71.215.86.203]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 07 Apr 2008 22:19:49 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.86.203; client-port=4801; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: From: Shane Amante To: BALUS Florin In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191CB7@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) Date: Mon, 7 Apr 2008 22:19:34 -0600 References: <4A5028372622294A99B8FFF6BD06EB7B04191CB7@USDALSMBS03.ad3.ad.alcatel.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Florin, Sorry for the delayed reply. Please see below. On Apr 2, 2008, at 3:56 PM, BALUS Florin wrote: > > [..] - cutting the previous text to make it for an easier read > >> ------Florin wrote------ >> >>> Mar 2009 Submit I-D on Virtual Private Multicast Service >>> (VPMS)requirements to IESG >>> [..] >>> Nov 2009 Submit Auto-Discovery solution for VPMS to IESG >>> >>> FB> (this comment applies to the 2 previous items) Not >> sure I understand >>> what are we trying to achieve here? We stated in item 5 of >> the charter >>> that L2 VPN WG is going to deal with "5. Mechanisms to permit >>> optimization of multicast data traffic within a VPLS or >> VPWS VPN over an >>> IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it >> similar with >>> P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on >> this just in >>> case we are dealing with a VPN like collection of PWs. Otherwise we >>> should probably address this in PWE3/MPLS to start with. >>> FB> >> >> Thanks for pointing this out. To be clear, the L2VPN WG is >> dependent on >> the /successful/ chartering of P2MP PW's within the PWE3 WG -- which >> hasn't happened, yet. >> >> Assuming the PWE3 WG does charter P2MP PW's, the way the VPMS >> work would >> be split between the PWE3 WG and the L2VPN WG is as follows: >> 1) Requirements for a unidirectional P2MP PW will be in PWE3; >> 2) P2MP PW encapsulation solution(s) will be in PWE3; >> 3) Requirements for a VPMS "service", (Virtual Private P2MP >> unidirectional service), will be put forth in the the L2VPN WG; >> 4) BGP Auto-Discovery procedures for VPMS will also be put in L2VPN. >> > I agree that P2MP PW has to be discussed and included in the PWE3 > charter first. Then the requirements and the solution components (e.g. > encapsulation(s), signaling) need to be addressed in PWE3 WG. > > Isn't it too early though to talk about a VPMS charter item for L2VPN > WG? It might be better to wait for PWE3 WG to make a decision on this > and then decide how much and what kind of work we need to do in L2VPN > WG? I agree it was a little early to discuss this, but I was counting on the new PWE3 WG charter to have been sent out by now so P2MP PW's would be discussed over there at the same time. Ultimately, if there is no decision in PWE3 on P2MP PW's by the time we close down discussing the new L2VPN charter, (in 3 more weeks on 4/25/2008), then I see no choice but to pull VPMS from the L2VPN charter. -shane >> In terms of existing drafts that would mean: >> - draft-raggarwa-l2vpn-p2mp-pw-00: would get split into two >> drafts. The >> first draft would define a P2MP PW (#2) and be within the >> scope of PWE3. >> The second draft would define BGP Auto-Discovery procedures >> for VPMS >> (#4) and be within the L2VPN WG. >> - draft-jounay-pwe3-p2mp-pw-requirements-01 would be in PWE3 >> and cover #1. >> - A new, yet unwritten draft would have to be put forth to cover #3, >> (or, perhaps, combined with #4). >> >> >> >> -----Ali wrote----- >>> iv) "5. Mechanisms to permit optimization of multicast data traffic >>> within a VPLS or VPWS VPN over an IP/MPLS PSN." >>> >>> AS> mcast optimization should only be for VPLS based on >> VPWS service >>> definition. >> >> So, are you saying you share the same concern as Florin that >> we need to >> 'wait to see' if the PWE3 WG will add P2MP PW's to their charter? >> >> I've pinged Danny & Stewart to see if they can send out the new PWE3 >> charter soon, in order that we're not 'waiting to see' if >> PWE3 WG will >> or will not take on P2MP PW's. >> >> Thanks, >> >> -shane >> From l2vpn-bounces@ietf.org Mon Apr 7 22:20:51 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAA13A694F; Mon, 7 Apr 2008 22:20:51 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7A53A694F for ; Mon, 7 Apr 2008 22:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klMP6lUiJ1Q8 for ; Mon, 7 Apr 2008 22:20:49 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 06C733A68F5 for ; Mon, 7 Apr 2008 22:20:48 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DD5D126803D; Mon, 7 Apr 2008 23:21:03 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-86-203.hlrn.qwest.net [71.215.86.203]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 07 Apr 2008 23:21:03 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.86.203; client-port=2424; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: From: Shane Amante To: BALUS Florin In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04191D00@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN (Re-)charter: Service Convergence Date: Mon, 7 Apr 2008 23:20:48 -0600 References: <4A5028372622294A99B8FFF6BD06EB7B04191D00@USDALSMBS03.ad3.ad.alcatel.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Florin, Please see below. On Apr 3, 2008, at 3:07 AM, BALUS Florin wrote: > Shane, > See below.. > >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Wednesday, April 02, 2008 8:48 PM >> To: BALUS Florin >> Cc: l2vpn@ietf.org >> Subject: Re: L2VPN (Re-)charter: Service Convergence >> >> Florin, >> >> Please see below. >> >> On Apr 2, 2008, at 3:39 PM, BALUS Florin wrote: >> [--snip--] >>>> ------Florin wrote------ >>>>> The L2VPN WG scope includes the following: >>>>> [..] >>>>> 6. Improved service convergence for multi-homed CE's to VPLS PE's. >>>>> Specifically, upon failure of a primary path from a CE >>>> to VPLS PE, >>>>> initiate a rapid switch-over to an alternate path. If required, >>>>> interactions with native service-layer resiliency >>>> mechanisms will be >>>>> provided via solutions from other IETF WG's such as PWE3. >>>>> >>>>> FB> Suggest we modify the text to include also >>>> multi-homing between 2 >>>>> VPLS domains, see below an example of text: >>>>> 6. Improved service convergence for multi-homing >>>> solutions: CEs to VPLS >>>>> PEs or between VPLS domains. >>>> >>>> Can you clarify this further? Specifically, do you mean the >>>> following two cases: >>>> a) One CE to two different VPLS PE's in a single AS; and, >>>> b) One CE to two different VPLS PE's, each in a different AS? >>>> >>> >>> Not really. What I had in mind was more along the following: >>> a) CEs multi-homed to different VPLS PEs >>> b) a VPLS domain multi-homed to another VPLS domain: e.g. a VPLS >>> mesh in >>> domain 1 multihomed to a VPLS mesh in domain 2. >>> Examples of criteria that may define what a VPLS domain is: >>> geographical >>> (metro, national, international), administrative different >>> organizations/providers) etc... >> >> With respect to (b), isn't one (major?) aspect an Inter-AS >> use case? >> If so, hasn't that already been addressed by Sections 4.1 & 4.2 of >> draft-ietf-l2vpn-signaling-08? From Section 4.2 of that draft, (see >> second sentence): >> ---cut here--- >> Note that the procedures described here will result in the splicing >> points (S-PEs in the terminology of >> [I-D.ietf-pwe3-ms-pw-arch]) being >> co-located with the ASBRs. It is of course possible to have multiple >> ASBR-ASBR connections between a given pair of ASes. In this case a >> given PE could choose among the available ASBRs based on a range of >> criteria, such as IGP metric, local configuration, etc., >> analogous to >> choosing an exit point in normal IP routing. The use of >> multiple ASBRs >> would lead to greater resiliency (at the timescale of BGP routing >> convergence) since a PE could select a new ASBR in the event of the >> failure of the one currently in use. >> ---cut here--- >> >> > This addresses the case of redundant MS-PW path between two VPLS PEs. > Assume you have the following scenario: > VPLS Mesh 1 - PE1 - redundant MS-PW path as in l2vpn signaling - PE2 - > VPLS Mesh 2. > If PE1 or PE2 fails there is no way to communicate between the 2 > meshes, > it does not matter how many paths you have in between them. > > We need to have at least other 2 gateway Pes - e.g. PE1' and PE2' - to > totally eliminate single point of failure at both sides. So, you're thinking of something similar to what's illustrated in Section 11.3 and/or 11.4 of draft-ietf-pwe3-redundancy-bit-00? I think this raises the complexity vs. today's architecture of a full- mesh of only active PW's between a set of VPLS PE's with l2vpn- signaling to resolve a backup path when there is a failure of the primary path over the PSN. It would be useful to hear from others if there is a need for this or, instead, it can be solved for with multi-homed CE's to two, different PE's. For now, I'm still leaning toward the original text (which doesn't include multi-homed VPLS meshes), unless we hear from others on the need to add redundant meshes between VPLS domains. Here's the original text. ---cut here--- 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. ---cut here--- Thanks, -shane >>>> Also, correct me if I'm wrong, but PWE3 has already covered >>>> multi-homing of a MTU-s to two, different PE-rs'es in >>>> draft-muley-pwe3-redundancy-02? >>>> Or, is there addt'l work that L2VPN WG needs to take care of >>>> specifically for that case? >>> >>> draft-muley-pwe3-redundancy (adopted as PWE3 >>> draft-ietf-pwe3-redundancy-00.txt) can be definitely applied to >>> optimize >>> the procedures described in section 10.2 of RFC 4762 (VPLS MTU-s to >>> PE-rs resiliency). Still I think there is a need to have a >> discussion >>> about usage in a VPLS context to ensure interoperability, >> including an >>> update on how to reflect the PW transitions in LDP MAC Flush. >> >> The current draft-muley already discusses that. Are you suggesting >> the VPLS use-cases be pulled out into a separate draft and put in >> L2VPN, (which we'd add a goal/milestone for)? >> >> >>> Also this sort of resiliency (1 MTU-s to 2 PE-rs, triangle >> like) might >>> not be enough for the interconnection of two VPLS mesh >> domains: i.e. >>> the >>> MTU-s will be a single point of failure. More like a square >>> interconnection is required here where 2 VPLS PEs in domain 1 are >>> connected to 2 VPLS PEs in domain 2. >> >> Same question as above, specifically: hasn't l2vpn-signaling already >> addressed this? >> >> >> >>>>> Specifically, upon failure of a primary >>>>> path from a between CEs and VPLS PEs or between VPLS >>>> domains, initiate a >>>>> rapid switch-over to an alternate path. If required, >>>> interactions with >>>>> native service-layer resiliency mechanisms will be provided via >>>>> solutions from other IETF WG's such as PWE3. >>>>> FB> >>>>> >>>>> >>>>> The L2VPN WG currently works on the following tasks: >>>>> [..] >>>>> - Identify requirements for multi-homing of CE's to VPLS PE's. >>>>> elements. Based on these requirements, define solutions for >>>>> achieving fast convergence after a switchover to an >>>> alternate path, >>>>> for example through optimized MAC flushing within a VPLS domain. >>>>> >>>>> FB> Suggest changing this one to the following text: >>>>> - Identify requirements for different multi-homing >>>> solutions: i.e. CEs >>>>> to VPLS Pes or between VPLS domains. Based on these >>>> requirements, define >>>>> solutions for achieving fast convergence after a switchover to an >>>>> alternate path, for example through optimized MAC flushing >>>> within a VPLS >>>>> domain. >>>>> FB> >>>> >>>> I have the same question here as I do above. Once we're >> on the same >>>> page, then I think we can tighten the suggested text a little >>>> further. >>>> >>> >>> I hope the above answer addressed this one too. >> >> Not yet, but we're getting there. :-) >> >> Thanks, >> >> -shane >> From l2vpn-bounces@ietf.org Mon Apr 7 22:21:31 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941923A6DF9; Mon, 7 Apr 2008 22:21:31 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED0928C12F for ; Mon, 7 Apr 2008 22:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM+kif29Nd2l for ; Mon, 7 Apr 2008 22:21:28 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 8AD7F3A6DF9 for ; Mon, 7 Apr 2008 22:21:28 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m385LY37030439; Tue, 8 Apr 2008 00:21:34 -0500 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.11]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Apr 2008 00:21:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) Date: Tue, 8 Apr 2008 00:21:05 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B042126D1@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN (Re-)charter: VPMS (Virtual Private P2MP unidirectional Service) Thread-Index: AciZL8o94y5oKx/PSFKh6mH5alJozAACCcQQ From: "BALUS Florin" To: "Shane Amante" X-OriginalArrivalTime: 08 Apr 2008 05:21:17.0448 (UTC) FILETIME=[5F336080:01C89938] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Thanks Shane, sounds like a good plan. > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Monday, April 07, 2008 9:20 PM > To: BALUS Florin > Cc: l2vpn@ietf.org > Subject: Re: L2VPN (Re-)charter: VPMS (Virtual Private P2MP=20 > unidirectional Service) >=20 > Hi Florin, >=20 > Sorry for the delayed reply. Please see below. >=20 > On Apr 2, 2008, at 3:56 PM, BALUS Florin wrote: > > > > [..] - cutting the previous text to make it for an easier read > > > >> ------Florin wrote------ > >> > >>> Mar 2009 Submit I-D on Virtual Private Multicast Service > >>> (VPMS)requirements to IESG > >>> [..] > >>> Nov 2009 Submit Auto-Discovery solution for VPMS to IESG > >>> > >>> FB> (this comment applies to the 2 previous items) Not > >> sure I understand > >>> what are we trying to achieve here? We stated in item 5 of > >> the charter > >>> that L2 VPN WG is going to deal with "5. Mechanisms to permit=20 > >>> optimization of multicast data traffic within a VPLS or > >> VPWS VPN over an > >>> IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it > >> similar with > >>> P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on > >> this just in > >>> case we are dealing with a VPN like collection of PWs.=20 > Otherwise we=20 > >>> should probably address this in PWE3/MPLS to start with. > >>> FB> > >> > >> Thanks for pointing this out. To be clear, the L2VPN WG=20 > is dependent=20 > >> on the /successful/ chartering of P2MP PW's within the PWE3 WG --=20 > >> which hasn't happened, yet. > >> > >> Assuming the PWE3 WG does charter P2MP PW's, the way the VPMS work=20 > >> would be split between the PWE3 WG and the L2VPN WG is as follows: > >> 1) Requirements for a unidirectional P2MP PW will be in PWE3; > >> 2) P2MP PW encapsulation solution(s) will be in PWE3; > >> 3) Requirements for a VPMS "service", (Virtual Private P2MP=20 > >> unidirectional service), will be put forth in the the L2VPN WG; > >> 4) BGP Auto-Discovery procedures for VPMS will also be=20 > put in L2VPN. > >> > > I agree that P2MP PW has to be discussed and included in the PWE3=20 > > charter first. Then the requirements and the solution=20 > components (e.g. > > encapsulation(s), signaling) need to be addressed in PWE3 WG. > > > > Isn't it too early though to talk about a VPMS charter item=20 > for L2VPN=20 > > WG? It might be better to wait for PWE3 WG to make a=20 > decision on this=20 > > and then decide how much and what kind of work we need to=20 > do in L2VPN=20 > > WG? >=20 > I agree it was a little early to discuss this, but I was=20 > counting on the new PWE3 WG charter to have been sent out by=20 > now so P2MP PW's would be discussed over there at the same=20 > time. Ultimately, if there is no decision in PWE3 on P2MP=20 > PW's by the time we close down discussing the new L2VPN=20 > charter, (in 3 more weeks on 4/25/2008), then I see no choice=20 > but to pull VPMS from the L2VPN charter. >=20 > -shane >=20 >=20 >=20 >=20 > >> In terms of existing drafts that would mean: > >> - draft-raggarwa-l2vpn-p2mp-pw-00: would get split into=20 > two drafts. =20 > >> The first draft would define a P2MP PW (#2) and be within=20 > the scope=20 > >> of PWE3. > >> The second draft would define BGP Auto-Discovery=20 > procedures for VPMS > >> (#4) and be within the L2VPN WG. > >> - draft-jounay-pwe3-p2mp-pw-requirements-01 would be in PWE3 and=20 > >> cover #1. > >> - A new, yet unwritten draft would have to be put forth to=20 > cover #3,=20 > >> (or, perhaps, combined with #4). > >> > >> > >> > >> -----Ali wrote----- > >>> iv) "5. Mechanisms to permit optimization of multicast=20 > data traffic=20 > >>> within a VPLS or VPWS VPN over an IP/MPLS PSN." > >>> > >>> AS> mcast optimization should only be for VPLS based on > >> VPWS service > >>> definition. > >> > >> So, are you saying you share the same concern as Florin=20 > that we need=20 > >> to 'wait to see' if the PWE3 WG will add P2MP PW's to=20 > their charter? > >> > >> I've pinged Danny & Stewart to see if they can send out=20 > the new PWE3=20 > >> charter soon, in order that we're not 'waiting to see' if > >> PWE3 WG will > >> or will not take on P2MP PW's. > >> > >> Thanks, > >> > >> -shane > >> >=20 >=20 From l2vpn-bounces@ietf.org Mon Apr 7 22:24:20 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1046A28C2F4; Mon, 7 Apr 2008 22:24:20 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3850528C2F4 for ; Mon, 7 Apr 2008 22:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEB0qAX4JBBi for ; Mon, 7 Apr 2008 22:24:17 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id B8B1428C2F1 for ; Mon, 7 Apr 2008 22:24:17 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D918A26803D; Mon, 7 Apr 2008 23:24:32 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-86-203.hlrn.qwest.net [71.215.86.203]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 07 Apr 2008 23:24:32 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.86.203; client-port=1090; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: From: Shane Amante To: Luca Martini In-Reply-To: <47FA34D1.6030502@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: L2VPN WG (Re-)charter Date: Mon, 7 Apr 2008 23:24:17 -0600 References: <47F13154.6070703@castlepoint.net> <47FA34D1.6030502@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Luca, OK. I will add "and MPLS" to the end of that paragraph. -shane On Apr 7, 2008, at 8:50 AM, Luca Martini wrote: > Shane, > > The charter looks good , but I would like to propose the following > small change: > > OLD: > The L2VPN WG will provide extensions of existing protocols that will > be > discussed in protocol-specific WG's. In particular, the L2VPN WG > will define extensions to pseudowire management (OAM) mechanisms, > specifically Pseudowire Virtual Circuit Connectivity Verification > (VCCV), > for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure > they > are inline with the overall design/architecture of VCCV. > > NEW: > The L2VPN WG will provide extensions of existing protocols that will > be > discussed in protocol-specific WG's. In particular, the L2VPN WG > will define extensions to pseudowire management (OAM) mechanisms, > specifically Pseudowire Virtual Circuit Connectivity Verification > (VCCV), > for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure > they > are inline with the overall design/architecture of VCCV and MPLS. > ^ > ^^^^^^^^ > The concern here is that in order to do some convoluted > OAM method, somebody will come along, and try to do something that > is not in the MPLS architecture. > > Thanks. > Luca > > > Shane Amante wrote: >> Hi Folks, >> >> It's been just over two weeks and we haven't heard any support for >> or comments on the suggested charter below. This is just a gentle >> reminder to speak up in order that current/in-flight and future >> projects aren't delayed or dropped. >> >> -shane >> >> >> Shane Amante wrote: >>> Hi, >>> >>> As mentioned during the WG meeting at IETF 71 in Philadelphia, >>> below is a proposed draft of a new charter for the L2VPN WG. >>> Included are the following new items: >>> - Multicast >>> - Scalability >>> - Multi-homing / Service Convergence >>> - Inter-AS >>> >>> Please take a look at the entire text, including suggested dates >>> for deliverables & milestones. >>> >>> Please send any questions, clarifications or suggested changes to >>> the WG mailing list. If you believe the new charter (below) is >>> fine "as-is", then please indicate your support to the WG mailing >>> list, as well. >>> >>> We would like to set a time-limit for discussion and agreement of >>> the new charter, in order that we can get back to the business at >>> hand. As such, let me propose that we wrap-up discussion and >>> gauge (rough) consensus by Friday, April 25, 1700 MDT (UTC -6), >>> which is a little over 1 month from now. >>> >>> Thanks, >>> >>> -shane & Vach >>> >>> ---cut here--- >>> >>> The L2VPN working group is responsible for defining and specifying a >>> limited number of solutions for supporting provider-provisioned >>> Layer-2 >>> Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the >>> following: >>> >>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that >>> emulates >>> an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet >>> Switched >>> Network (PSN). >>> >>> 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that >>> provides >>> point-to-point connectivity for a variety of link layers, >>> including >>> Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS- >>> enabled IP >>> PSN. >>> >>> 3. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP- >>> only" >>> service over an IP or MPLS-enabled PSN. This service is similar >>> to >>> VPWS because it supports a variety of link-layer protocols on the >>> Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, >>> etc. >>> IP-only L2VPN's are different from both VPLS and VPWS because >>> unicast >>> Layer-2 frames containing IP data packets, either IPv4 or IPv6, >>> are de- >>> encapsulated leaving only the IP data packet to be transmitted >>> over >>> the PSN. An IP-only L2VPN service also differs from L3VPN >>> service, >>> since no routing protocol operates between the PE and CE; >>> furthermore, >>> connectivity from CE to CE is provided via an emulated Layer-2 >>> service >>> over the PSN, which results in the CE's appearing to be directly >>> attached to each other at Layer-2. The WG will address two >>> specific >>> types of IP-only L2VPN: >>> >>> a) Those with Attachment Circuits (ACs) that use the same Layer 2 >>> framing at all attachment points in the same L2VPN; and, >>> >>> b) Those with ACs that use different Layer 2 framing at various >>> attachment points in the same L2VPN. For (b), inter-working >>> between >>> link-layers is strictly out of scope beyond that which is >>> minimally >>> necessary to ensure that IP packets are transported from an AC >>> of one >>> type, across the IP or MPLS-enabled IP PSN, and to an AC of >>> another >>> type in as transparent a manner as possible to the CEs on both >>> sides >>> of the service. >>> >>> VPLS and VPWS operate over Pseudowires (PWs) as defined by the >>> PWE3 WG. >>> As with a single PW, an L2VPN emulates a "native" service over a >>> PSN that >>> is reasonably faithful to, but may not be entirely indistinguishable >>> from, the native service itself. Further, following in the "edge- >>> to-edge" >>> nature of the PWs that it uses, the L2VPN WG will not define any new >>> mechanisms which exert control over the underlying PSN. When >>> necessary >>> it may, however, recommend or require the use of existing PSN QoS >>> and >>> path control mechanisms between PW endpoints which make up the >>> L2VPN. >>> >>> L2VPN's will make use of existing IETF specified mechanisms unless >>> there >>> are technical reasons why the existing mechanisms are insufficient >>> or >>> unnecessary. >>> >>> The L2VPN WG is responsible for specification of the discovery and >>> membership of PE's participating in a VPLS, VPWS or IP-only L2VPN >>> as well >>> as the membership of CE devices to a specific instance of a L2VPN. >>> >>> The L2VPN WG will provide extensions of existing protocols that >>> will be >>> discussed in protocol-specific WG's. In particular, the L2VPN WG >>> will define extensions to pseudowire management (OAM) mechanisms, >>> specifically Pseudowire Virtual Circuit Connectivity Verification >>> (VCCV), >>> for VPLS. Those VCCV extensions will be reviewed by PWE3 to >>> ensure they >>> are inline with the overall design/architecture of VCCV. >>> >>> The L2VPN WG will not define new encapsulations, control (set-up, >>> configuration, maintenance or tear-down), or resiliency mechanisms >>> specifically related to pseudowires, because those must be defined >>> by the >>> PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- >>> working between a VPLS or VPWS and native service-layer control, >>> OAM or >>> or resiliency mechanisms, as those will be defined by the PWE3 >>> WG. On >>> the other hand, the L2VPN WG will define how to operate native >>> service- >>> layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS >>> service. >>> >>> The L2VPN WG scope includes the following: >>> >>> 1. Discovery of PE's participating in a Layer-2 VPN and the >>> associated >>> topology required for connectivity of the VPLS or VPWS service. >>> >>> 2. Signaling of information related to the discovery and >>> membership of >>> PE's within a L2VPN. These procedures must use PWE3 control and >>> management procedures, or define requirements for extensions of >>> PWE3 >>> protocols to suit the needs of an L2VPN. Once those >>> requirements are >>> reviewed by the L2VPN WG, they should be provided to the PWE3 WG >>> to >>> derive solutions. >>> >>> 3. MIB's for Layer-2 VPN solutions. >>> >>> 4. Specification of requirements and framework that will define >>> Operations >>> Administration and Management (OAM) procedures for VPLS and VPWS >>> VPN's, >>> related to the operation of VPLS and VPWS VPN's over IP/MPLS >>> PSN's. >>> In addition, the L2VPN WG will define OAM solutions for VPLS and >>> VPWS >>> VPN's. >>> >>> 5. Mechanisms to permit optimization of multicast data traffic >>> within >>> a VPLS or VPWS VPN over an IP/MPLS PSN. >>> >>> 6. Improved service convergence for multi-homed CE's to VPLS PE's. >>> Specifically, upon failure of a primary path from a CE to VPLS PE, >>> initiate a rapid switch-over to an alternate path. If required, >>> interactions with native service-layer resiliency mechanisms >>> will be >>> provided via solutions from other IETF WG's such as PWE3. >>> >>> 7. Enhancements to increase the scalability of the Forwarding >>> Database of >>> VPLS PE nodes. >>> >>> 8. Definition of requirements and solutions for Inter-AS VPLS and >>> VPWS >>> services. >>> >>> The L2VPN WG currently works on the following tasks: >>> >>> - Define MIB's appropriate for each type of Layer-2 VPN. >>> >>> - Specification of Operations Administration and Management (OAM) >>> mechanisms for VPLS, VPWS and IP-only VPN's. >>> >>> - Specification of procedures to permit optimization of L2VPN >>> multicast >>> data traffic within the PSN. >>> >>> - Define enhancements to increase scalability of VPLS PE nodes, to >>> provide aggregation of learned customer MAC addresses at VPLS PE's. >>> >>> - Identify requirements for multi-homing of CE's to VPLS PE's. >>> elements. Based on these requirements, define solutions for >>> achieving >>> fast convergence after a switchover to an alternate path, for >>> example >>> through optimized MAC flushing within a VPLS domain. >>> >>> - Identify requirements for Inter-AS VPLS and VPWS services. Define >>> Inter-AS enhancements to VPLS and VPWS based on these requirements. >>> >>> Where necessary, the WG will coordinate its activities with IEEE >>> 802.1. >>> >>> Goals and Milestones: >>> >>> Done Submit L2 requirements to IESG for publication as >>> Informational RFC >>> Done Identify VPLS and VPWS solutions for the WG >>> Done Submit L2 framework to IESG for publication as >>> Informational RFC >>> Done Submit VPLS solution documents to IESG >>> Done Submit VPWS solution documents to IESG >>> Done Submit an I-D on OAM requirements for VPLS >>> Done Submit an I-D on OAM requirements for VPWS >>> Done Submit an I-D describing MIB for VPLS >>> Done Submit an I-D describing MIB for VPWS >>> >>> Mar 2008 Submit IP-only L2VPN solution documents to IESG >>> >>> Nov 2008 Submit MAC learning optimization solutions for VPLS to >>> IESG >>> >>> Nov 2008 Submit multicast optimization solutions for VPLS to IESG >>> >>> Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) >>> requirements to IESG >>> >>> Mar 2009 Submit OAM solutions for VPWS to IESG >>> Mar 2009 Submit OAM solutions for VPLS to IESG >>> Mar 2009 Submit OAM solutions for IP-only L2VPN to IESG >>> >>> Jul 2009 Submit MIB for VPLS to IESG >>> Jul 2009 Submit MIB for VPWS to IESG >>> Jul 2009 Submit MIB for IP-only L2VPN to IESG >>> >>> Nov 2009 Submit Auto-Discovery solution for VPMS to IESG >>> >>> Nov 2009 Submit scalability solutions for VPLS Control-Plane to >>> IESG >>> Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG >>> >>> Jul 2010 Submit VPLS service convergence improvement solutions >>> to IESG >>> >>> Jul 2010 Submit VPLS multi-homing solutions to IESG >>> >>> Jul 2010 Submit Inter-AS VPLS and VPWS solutions to IESG >> > > From l2vpn-bounces@ietf.org Mon Apr 7 23:01:34 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06B73A6DAF; Mon, 7 Apr 2008 23:01:33 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705AA3A6DF9 for ; Mon, 7 Apr 2008 23:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J09WtQBAfucR for ; Mon, 7 Apr 2008 23:01:32 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7B1393A6DAF for ; Mon, 7 Apr 2008 23:01:31 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id A25EC26803D; Tue, 8 Apr 2008 00:01:46 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-86-203.hlrn.qwest.net [71.215.86.203]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Tue, 08 Apr 2008 00:01:46 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.86.203; client-port=4677; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <77E760C1-F304-465C-A817-1D546E08A196@castlepoint.net> From: Shane Amante To: l2vpn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: L2VPN (Re-)charter: Multicast Optimization Date: Tue, 8 Apr 2008 00:01:31 -0600 X-Mailer: Apple Mail (2.919.2) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Folks, I received a private e-mail asking if the following WG draft: draft-ietf-l2vpn-vpls-pim-snooping ... is part of the new WG charter. I believe it is, therefore I've added the following item to the new WG charter: ---cut here--- Mar 2009 Submit PIM snooping solution for VPLS to IESG ---cut here--- I've also slightly changed the text and slightly pushed out the following deliverable, which was originally set at Nov 2008 to Mar 2009 to coincide with the above addition. FROM: ---cut here--- Nov 2008 Submit multicast optimization solutions for VPLS to IESG ---cut here--- TO: ---cut here--- Mar 2009 Submit signaling solution for multicast-optimized VPLS to IESG ---cut here--- If we get either done sooner than that, I'm sure there won't be complaints. Any questions or concerns, please let me know. -shane From l2vpn-bounces@ietf.org Mon Apr 7 23:13:20 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285A43A6C89; Mon, 7 Apr 2008 23:13:20 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF053A6C89 for ; Mon, 7 Apr 2008 23:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.283 X-Spam-Level: X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHIeVmdd4IKN for ; Mon, 7 Apr 2008 23:13:17 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 6B2803A6C42 for ; Mon, 7 Apr 2008 23:13:17 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id A392F26803D; Tue, 8 Apr 2008 00:13:32 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-86-203.hlrn.qwest.net [71.215.86.203]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Tue, 08 Apr 2008 00:13:32 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.86.203; client-port=1478; syn-fingerprint=65535:54:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> From: Shane Amante To: l2vpn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: L2VPN WG (Re-)Charter Draft with changes Date: Tue, 8 Apr 2008 00:13:17 -0600 X-Mailer: Apple Mail (2.919.2) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org For those of you following along at home, I've posted the complete text of the current, proposed L2VPN WG charter, including all changes that have been accepted thus far, to the following location: http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt (Also, I'll continue to update the version at the above URL if/when more changes come in). If there are any comments, questions or concerns with the charter, please follow-up to the list or let Vach or I know. Thanks, -shane (& Vach) From l2vpn-bounces@ietf.org Tue Apr 8 01:30:37 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14313A67DB; Tue, 8 Apr 2008 01:30:37 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED49428C19C for ; Tue, 8 Apr 2008 01:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6bxHz6QxxU0 for ; Tue, 8 Apr 2008 01:30:29 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 939223A6ADF for ; Tue, 8 Apr 2008 01:30:28 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 08 Apr 2008 12:10:48 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 11:30:26 +0300 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.263.0; Tue, 8 Apr 2008 11:30:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN WG (Re-)Charter Draft with changes Date: Tue, 8 Apr 2008 11:30:22 +0300 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02EC713F@ILPTEX02.ecitele.com> In-Reply-To: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN WG (Re-)Charter Draft with changes Thread-Index: AciZP7B6S/tPLGAET2GDb5b9F8BTZAAElntQ References: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> From: Alexander Vainshtein To: "Shane Amante" X-OriginalArrivalTime: 08 Apr 2008 08:30:26.0503 (UTC) FILETIME=[CBC3BD70:01C89952] Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane and all, I support the proposed L2VPN Charter. At the same time I'd like to note that, to the best of my understanding, the following milestone looks somewhat problematic today: Mar 2008 Submit IP-only L2VPN solution documents to IESG Did I miss something? Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Tuesday, April 08, 2008 9:13 AM > To: l2vpn@ietf.org > Subject: L2VPN WG (Re-)Charter Draft with changes >=20 > For those of you following along at home, I've posted the complete =20 > text of the current, proposed L2VPN WG charter, including all=20 > changes =20 > that have been accepted thus far, to the following location: > http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >=20 > (Also, I'll continue to update the version at the above URL if/when =20 > more changes come in). >=20 > If there are any comments, questions or concerns with the charter, =20 > please follow-up to the list or let Vach or I know. >=20 > Thanks, >=20 > -shane (& Vach) >=20 From l2vpn-bounces@ietf.org Tue Apr 8 03:56:10 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013FF3A6866; Tue, 8 Apr 2008 03:56:10 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53B228C1AB for ; Tue, 8 Apr 2008 03:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KchbRn+i5PfO for ; Tue, 8 Apr 2008 03:56:05 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id DC5E63A6866 for ; Tue, 8 Apr 2008 03:56:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,623,1199682000"; d="scan'208";a="116680440" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 08 Apr 2008 06:56:20 -0400 X-IronPort-AV: E=Sophos;i="4.25,623,1199682000"; d="scan'208";a="186146107" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Apr 2008 06:56:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN WG (Re-)Charter Draft with changes Date: Tue, 8 Apr 2008 12:56:29 +0200 Message-ID: In-Reply-To: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN WG (Re-)Charter Draft with changes Thread-Index: AciZP7cwohcIQYDRQaGJnfbchZ8efAAJvUIw References: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> From: "Romascanu, Dan (Dan)" To: "Shane Amante" , X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org I am concerned by the expression 'pseudowire management (OAM) mechanisms'. Management of pseudo-wires is not equivalent to OAM, there is more in the management of pseudo-wires than OAM, and elements of the OAM protocols are used also for operational purposes that are not necessarily OAM related. I would suggest to use 'pseudowire management mechanisms (including OAM)' instead.=20 Dan > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Tuesday, April 08, 2008 9:13 AM > To: l2vpn@ietf.org > Subject: L2VPN WG (Re-)Charter Draft with changes >=20 > For those of you following along at home, I've posted the=20 > complete text of the current, proposed L2VPN WG charter,=20 > including all changes that have been accepted thus far, to=20 > the following location: > http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >=20 > (Also, I'll continue to update the version at the above URL=20 > if/when more changes come in). >=20 > If there are any comments, questions or concerns with the=20 > charter, please follow-up to the list or let Vach or I know. >=20 > Thanks, >=20 > -shane (& Vach) >=20 From l2vpn-bounces@ietf.org Tue Apr 8 07:02:20 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6A128C102; Tue, 8 Apr 2008 07:02:20 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE513A6C86 for ; Tue, 8 Apr 2008 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5oyjHBzcdkY for ; Tue, 8 Apr 2008 07:02:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 18F483A6BEB for ; Tue, 8 Apr 2008 07:02:15 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 1049D26803D; Tue, 8 Apr 2008 08:02:31 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Tue, 08 Apr 2008 08:02:31 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=51541; data-bytes=0 Message-ID: <47FB7AF6.8040806@castlepoint.net> Date: Tue, 08 Apr 2008 08:02:30 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexander Vainshtein Subject: Re: L2VPN WG (Re-)Charter Draft with changes References: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> <64122293A6365B4A9794DC5636F9ACFD02EC713F@ILPTEX02.ecitele.com> In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD02EC713F@ILPTEX02.ecitele.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Sasha, Alexander Vainshtein wrote: > Shane and all, > I support the proposed L2VPN Charter. > > At the same time I'd like to note that, to the best of my understanding, > the following milestone looks somewhat problematic today: > > > Mar 2008 Submit IP-only L2VPN solution documents to IESG > > > Did I miss something? Thanks for pointing that out. Given the questions/changes suggested by Margaret with respect to IPv6 support it looks like we'll have to push this out to give Himanshu and the other co-authors a chance to address them. I suggest we change the above to be as follows: Nov 2008 Submit IP-only L2VPN solution documents to IESG Thanks, -shane > Regards, > Sasha >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Shane Amante >> Sent: Tuesday, April 08, 2008 9:13 AM >> To: l2vpn@ietf.org >> Subject: L2VPN WG (Re-)Charter Draft with changes >> >> For those of you following along at home, I've posted the complete >> text of the current, proposed L2VPN WG charter, including all >> changes >> that have been accepted thus far, to the following location: >> http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >> >> (Also, I'll continue to update the version at the above URL if/when >> more changes come in). >> >> If there are any comments, questions or concerns with the charter, >> please follow-up to the list or let Vach or I know. >> >> Thanks, >> >> -shane (& Vach) >> From l2vpn-bounces@ietf.org Tue Apr 8 07:06:20 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFA23A6C86; Tue, 8 Apr 2008 07:06:20 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65F83A6C86 for ; Tue, 8 Apr 2008 07:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDvd++6xCbpZ for ; Tue, 8 Apr 2008 07:06:19 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id F0F923A6BEB for ; Tue, 8 Apr 2008 07:06:18 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id F09D826803D; Tue, 8 Apr 2008 08:06:34 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Tue, 08 Apr 2008 08:06:34 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=54458; data-bytes=0 Message-ID: <47FB7BEA.7050808@castlepoint.net> Date: Tue, 08 Apr 2008 08:06:34 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: L2VPN WG (Re-)Charter Draft with changes References: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Dan, I'm OK with your suggested change and have updated the proposed charter accordingly. Refer here for the full list of accepted changes thus far: http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt Thanks, -shane Romascanu, Dan (Dan) wrote: > I am concerned by the expression 'pseudowire management (OAM) > mechanisms'. Management of pseudo-wires is not equivalent to OAM, there > is more in the management of pseudo-wires than OAM, and elements of the > OAM protocols are used also for operational purposes that are not > necessarily OAM related. I would suggest to use 'pseudowire management > mechanisms (including OAM)' instead. > > Dan > > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Shane Amante >> Sent: Tuesday, April 08, 2008 9:13 AM >> To: l2vpn@ietf.org >> Subject: L2VPN WG (Re-)Charter Draft with changes >> >> For those of you following along at home, I've posted the >> complete text of the current, proposed L2VPN WG charter, >> including all changes that have been accepted thus far, to >> the following location: >> http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >> >> (Also, I'll continue to update the version at the above URL >> if/when more changes come in). >> >> If there are any comments, questions or concerns with the >> charter, please follow-up to the list or let Vach or I know. >> >> Thanks, >> >> -shane (& Vach) >> From l2vpn-bounces@ietf.org Tue Apr 8 07:43:48 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AE328C171; Tue, 8 Apr 2008 07:43:48 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF35D28C171 for ; Tue, 8 Apr 2008 07:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUH55mJ8--mC for ; Tue, 8 Apr 2008 07:43:45 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 71C9828C253 for ; Tue, 8 Apr 2008 07:43:45 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m38Ehv410924; Tue, 8 Apr 2008 14:43:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: L2VPN WG (Re-)Charter Draft with changes Date: Tue, 8 Apr 2008 10:43:20 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1468BA9B@zcarhxm0.corp.nortel.com> In-Reply-To: <47FB7BEA.7050808@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN WG (Re-)Charter Draft with changes Thread-Index: AciZgch+fXIVacOeR5qR0yYxo0SH7QAAT5Ew References: <07C842DF-3253-4866-A0F1-A676EFC9060A@castlepoint.net> <47FB7BEA.7050808@castlepoint.net> From: "Hamid Ould-Brahim" To: "Shane Amante" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org One comment on VPMS:=20 There are in fact multiple references (with multiple acronyms)=20 to this service (that may or may not refer to a common definition). Here are the ones I saw in both l2vpn and pwe3:=20 - "Virtual Private P2MP Service" (pwe3, l2vpn) - "Virtual Private P2MP unidirectional service" (pwe3) - VPMS: Virtual Private Multicast service (l2vpn charter) - L2MVPN (Layer-2 Multicast VPN, using l2vpn p2mp) Another issue is depending on the definition we pick,=20 P2MP PW may end up being just *one* possible solution=20 to provide VPMS service. I think in the absence of an agreed upon definition of=20 what this service is and what solutions/building blocks can be used to provide this service I suggest we remove this item until we get a better view from PWE3 WG on a direction on this topic and then later on add this service (possibly with explicit drafts) in l2vpn charter (or wait for PWE3 decision and then update and submit this charter). Hamid.=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Tuesday, April 08, 2008 10:07 AM > To: Romascanu, Dan (Dan) > Cc: l2vpn@ietf.org > Subject: Re: L2VPN WG (Re-)Charter Draft with changes >=20 > Hi Dan, >=20 > I'm OK with your suggested change and have updated the=20 > proposed charter accordingly. >=20 > Refer here for the full list of accepted changes thus far: > http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >=20 > Thanks, >=20 > -shane >=20 >=20 > Romascanu, Dan (Dan) wrote: > > I am concerned by the expression 'pseudowire management (OAM)=20 > > mechanisms'. Management of pseudo-wires is not equivalent to OAM,=20 > > there is more in the management of pseudo-wires than OAM,=20 > and elements=20 > > of the OAM protocols are used also for operational purposes=20 > that are=20 > > not necessarily OAM related. I would suggest to use 'pseudowire=20 > > management mechanisms (including OAM)' instead. > >=20 > > Dan > >=20 > >=20 > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 > >> Behalf Of Shane Amante > >> Sent: Tuesday, April 08, 2008 9:13 AM > >> To: l2vpn@ietf.org > >> Subject: L2VPN WG (Re-)Charter Draft with changes > >> > >> For those of you following along at home, I've posted the complete=20 > >> text of the current, proposed L2VPN WG charter, including=20 > all changes=20 > >> that have been accepted thus far, to the following location: > >> http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt > >> > >> (Also, I'll continue to update the version at the above=20 > URL if/when=20 > >> more changes come in). > >> > >> If there are any comments, questions or concerns with the charter,=20 > >> please follow-up to the list or let Vach or I know. > >> > >> Thanks, > >> > >> -shane (& Vach) > >> >=20 >=20 From l2vpn-bounces@ietf.org Tue Apr 8 08:59:50 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E1928C38C; Tue, 8 Apr 2008 08:59:49 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645EF28C3A6 for ; Tue, 8 Apr 2008 08:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ+pD5h1bduA for ; Tue, 8 Apr 2008 08:59:47 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id E8EDB28C38C for ; Tue, 8 Apr 2008 08:59:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt Date: Tue, 8 Apr 2008 12:00:01 -0400 Message-ID: <3C13767EA2F93441AFB13A630204F1B201D885B9@mamxm02.ciena.com> In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04192006@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt Thread-Index: AciWZtmi0HmMvDNDR2yw3B0lM3AsYgCmQsuA From: "Shah, Himanshu" To: "AISSAOUI Mustapha" , X-OriginalArrivalTime: 08 Apr 2008 16:00:03.0441 (UTC) FILETIME=[9B45CE10:01C89991] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Mustapha, Thanks for bringing this issue to the list as this has implication on interoperability with other implementations. Here are my thoughts - 1) ARP mediation requires that both PEs exchange IP address of the local CEs. This enables local PE to do proxy for remote CE. This is one of the important aspect of the mediation. 2) When PE is configured for ARP mediation, it advertises this capability by including the address list=20 TLV in PW FEC advertisement. In turn, it depends on peer to reciprocate the same.=20 3) when there is a capability mismatch, especially the one on which the receiving PE depends on peer to have, it has the right to = disengage. I do not believe this is contrary to RFC 4447. IP PW is the conduit=20 and for the data plane. IP PW is not ARP mediation. 4) As for using static configuration, ARP mediation draft describes how it can be done when using ARP mediation. One could very well do = static configuration such that both the local & remote CE's IP address is configured at both the PEs, in which case there is no need to = exchange IP addresses between the PEs. For this case, ARP mediation capability is not configured. May be draft needs to add text to clarify this = case. However, what is not cool is asymmetry whereby PE1 has the capability configured and PE2 does not but still accepts the PW label mapping FEC and keeps the PE1 in limbo.=20 /himanshu =20 > -----Original Message----- > From: l2vpn-bounces@ietf.org=20 > [mailto:l2vpn-bounces@ietf.org]On Behalf Of > AISSAOUI Mustapha > Sent: Friday, April 04, 2008 11:16 AM > To: l2vpn@ietf.org > Subject: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt >=20 >=20 > Himanshu and all, > I am sorry I am bringing this late in the game but I believe=20 > there is an > issue with the signaling procedures of the IP PW in this draft. >=20 > Specifically, Section 6.2 states the following: > " > As defined in [RFC4447], when processing a received PW FEC, the=20 > PE matches the PW ID and PW type with the locally configured PW=20 > ID and PW Type. If there is a match, and if the PW Type is IP=20 > Layer2 Transport the PE further checks for the presence of an=20 > Address List TLV (as specified in [RFC 3036]) in the optional=20 > parameter TLVs. If absent, a Label Release message is issued=20 > with a Status Code meaning "IP Address of the CE is absent"=20 > [note: Status Code 0x0000002D is pending IANA allocation] to=20 > reject the PW establishment. > " >=20 > I do not think we can mandate that if the Address List TLV was not > present, the label must be released. I am saying this as the=20 > IP PW type > has been defined in RFC 4447 and there is no such a constraint on the > setup of this type of PW in this RFC.=20 >=20 > There are deployed implementations which use the IP PW with static CE > address configurations and which will just not check for the address > list TLV. Yet, these implementations are compliant to RFC 4447. >=20 > I can think of one way of addressing the backward=20 > compatibility with RFC > 4447 and that is to follow what we have done for the PW=20 > Status TLV. This > TLV is included in the Label Mapping Message with the I-bit=20 > (ignore bit) > set. Only if both PEs have included the Address List TLV in the Label > Mapping message that it can be used subsequently inside a Notification > message. >=20 > This issue also exists in the IPLS draft. >=20 > Regards, > Mustapha.=20 >=20 >=20 From l2vpn-bounces@ietf.org Tue Apr 15 09:42:19 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F016D28C444; Tue, 15 Apr 2008 09:42:18 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C9228C349 for ; Tue, 15 Apr 2008 09:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STmQQD8YpVbl for ; Tue, 15 Apr 2008 09:42:15 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 025D628C448 for ; Tue, 15 Apr 2008 09:40:51 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m3FGfKIs006638; Tue, 15 Apr 2008 11:41:20 -0500 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Apr 2008 11:41:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt Date: Tue, 15 Apr 2008 11:41:18 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04293021@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <3C13767EA2F93441AFB13A630204F1B201D885B9@mamxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt Thread-Index: AciWZtmi0HmMvDNDR2yw3B0lM3AsYgCmQsuAAYMIuHA= References: <4A5028372622294A99B8FFF6BD06EB7B04192006@USDALSMBS03.ad3.ad.alcatel.com> <3C13767EA2F93441AFB13A630204F1B201D885B9@mamxm02.ciena.com> From: "AISSAOUI Mustapha" To: "Shah, Himanshu" , X-OriginalArrivalTime: 15 Apr 2008 16:41:19.0084 (UTC) FILETIME=[87C332C0:01C89F17] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Himanshu, I understand the importance of exchanging the CE IP address for the purpose of ARP proxy.=20 However, the static configuration of CE IP addresses is still an ARP mediation function. This is because the ARP proxy is still using the configured Ethernet CE address to ARP for the CE MAC address. So, you cannot say that "ARP mediation capability" should be disabled in this case. What needs to be disabled is the advertising of the Address List TLV. This can be done by configuration such that even if one PE advertised it in the label mapping message but not the other, none of them will use it in a subsequent notification message. However, this is a misconfiguration and what will happen is the PW will be up but unicast IP packets will not flow. This is the behaviour anyways if a PE has not yet learnt the Ethernet CE IP address. As for the backward compatibility with RFC 4447, it is related to the fact that many applications can use a specific PW type. For example, both Ethernet VPWS and VPLS will make use of it. Yet, none changes the signaling procedures in RFC 4447. ARP mediation with static configuration and with automatic CE discovery are just two applications. IPLS is another one. There may be others in the future. Given that we have deployments of the static ARP mediation capability, I really think we should address the backward compatibility with RFC 4447. What I proposed with the I-bit is just a proposal but I am open for other ways to resolve it. Mustapha. > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com]=20 > Sent: Tuesday, April 08, 2008 12:00 PM > To: AISSAOUI Mustapha; l2vpn@ietf.org > Subject: RE: IP PW establishment in=20 > draft-ietf-l2vpn-arp-mediation-09.txt >=20 > Hi Mustapha, >=20 > Thanks for bringing this issue to the list as this has=20 > implication on interoperability with other implementations. >=20 > Here are my thoughts - > 1) ARP mediation requires that both PEs exchange > IP address of the local CEs. This enables local PE > to do proxy for remote CE. This is one of the important > aspect of the mediation. >=20 > 2) When PE is configured for ARP mediation, > it advertises this capability by including the address list=20 > TLV in PW FEC advertisement. In turn, it depends on peer to > reciprocate the same.=20 >=20 > 3) when there is a capability mismatch, especially the one on which > the receiving PE depends on peer to have, it has the right=20 > to disengage. > I do not believe this is contrary to RFC 4447. IP PW is=20 > the conduit=20 > and for the data plane. IP PW is not ARP mediation. >=20 > 4) As for using static configuration, ARP mediation draft=20 > describes how > it can be done when using ARP mediation. One could very=20 > well do static > configuration such that both the local & remote CE's IP address is > configured at both the PEs, in which case there is no need=20 > to exchange > IP addresses between the PEs. For this case, ARP mediation=20 > capability > is not configured. May be draft needs to add text to=20 > clarify this case. > However, what is not cool is asymmetry whereby PE1 has the=20 > capability > configured and PE2 does not but still accepts the PW label mapping > FEC and keeps the PE1 in limbo.=20 >=20 >=20 > /himanshu > =20 >=20 >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org > > [mailto:l2vpn-bounces@ietf.org]On Behalf Of AISSAOUI Mustapha > > Sent: Friday, April 04, 2008 11:16 AM > > To: l2vpn@ietf.org > > Subject: IP PW establishment in=20 > draft-ietf-l2vpn-arp-mediation-09.txt > >=20 > >=20 > > Himanshu and all, > > I am sorry I am bringing this late in the game but I believe=20 > > there is an > > issue with the signaling procedures of the IP PW in this draft. > >=20 > > Specifically, Section 6.2 states the following: > > " > > As defined in [RFC4447], when processing a received PW FEC, the=20 > > PE matches the PW ID and PW type with the locally=20 > configured PW=20 > > ID and PW Type. If there is a match, and if the PW Type is IP=20 > > Layer2 Transport the PE further checks for the presence of an=20 > > Address List TLV (as specified in [RFC 3036]) in the optional=20 > > parameter TLVs. If absent, a Label Release message is issued=20 > > with a Status Code meaning "IP Address of the CE is absent"=20 > > [note: Status Code 0x0000002D is pending IANA allocation] to=20 > > reject the PW establishment. > > " > >=20 > > I do not think we can mandate that if the Address List TLV was not > > present, the label must be released. I am saying this as the=20 > > IP PW type > > has been defined in RFC 4447 and there is no such a=20 > constraint on the > > setup of this type of PW in this RFC.=20 > >=20 > > There are deployed implementations which use the IP PW with=20 > static CE > > address configurations and which will just not check for the address > > list TLV. Yet, these implementations are compliant to RFC 4447. > >=20 > > I can think of one way of addressing the backward=20 > > compatibility with RFC > > 4447 and that is to follow what we have done for the PW=20 > > Status TLV. This > > TLV is included in the Label Mapping Message with the I-bit=20 > > (ignore bit) > > set. Only if both PEs have included the Address List TLV in=20 > the Label > > Mapping message that it can be used subsequently inside a=20 > Notification > > message. > >=20 > > This issue also exists in the IPLS draft. > >=20 > > Regards, > > Mustapha.=20 > >=20 > >=20 >=20 From l2vpn-bounces@ietf.org Thu Apr 24 08:05:39 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED96D3A6BC5; Thu, 24 Apr 2008 08:05:38 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1B728C1B1 for ; Thu, 24 Apr 2008 08:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN-G4kFHGqYD for ; Thu, 24 Apr 2008 08:05:33 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id BBB333A68B8 for ; Thu, 24 Apr 2008 08:05:33 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 24996268494; Thu, 24 Apr 2008 09:05:39 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Thu, 24 Apr 2008 09:05:39 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=60794; data-bytes=0 Message-ID: <4810A1C2.6000805@castlepoint.net> Date: Thu, 24 Apr 2008 09:05:38 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: l2vpn@ietf.org Subject: Updates to L2VPN (Re-)charter: VPMS, OAM & Other Misc. Tidbits Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Just a reminder that we'd like to wrap-up the re-charter discussion by this Friday afternoon, April 25, 1700 MDT (UTC -6). As such, I did another pass of the most current draft text of the L2VPN charter to tidy it up. As part of that review, I've made the following changes: 1) Native Service-Layer OAM. I've changed the "will" to "may" in the following sentence: | On | the other hand, the L2VPN WG may define how to operate native service- ^^^ | layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS | service. This should align better with the "may" in the paragraph above it that L2VPN "/may/ define extensions to pseudowire management mechanisms ...". Note, this is not to de-emphasize the importance of doing work in this area, but rather to strike a better balance in the language. In addition, although there is active interest in the WG with respect to native service-layer OAM (e.g.: 802.1ag) and clearly expect that work to continue, the WG hasn't yet decided if it wants/needs to work on native-service layer control or resiliency mechanisms on top of VPLS. Therefore, a "may" seems more appropriate in that regard as well. 2) Submit MAC learning Optimizations milestone. I believe Florin raised a question about what is the following milestone: | Nov 2008 Submit MAC learning optimization solutions for VPLS to IESG I believe the above was a typo, therefore I'm going to remove the above from the charter, since that should be covered by the following milestones: | Nov 2009 Submit scalability solutions for VPLS Control-Plane to IESG | Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG 3) VPMS. Finally, at this point, I see no choice, but to remove VPMS (Virtual Private Multicast Service) from the L2VPN charter. While there appears to be some interest in L2VPN to do this work, it seems fairly clear at this point that we are blocked on a decision as to whether the PWE3 WG will add P2MP PW's to its charter. If/when PWE3 recharters and that WG reaches a decision on P2MP PW's, we will then entertain another re-charter to add VPMS to the L2VPN charter as well. Please let me know if there are any comments or concerns with the above changes. In addition, the latest charter text reflecting the above changes is at the following location: http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt Regards, -shane From l2vpn-bounces@ietf.org Fri Apr 25 13:46:36 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA1828C139; Fri, 25 Apr 2008 13:46:36 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234B83A6768 for ; Fri, 25 Apr 2008 13:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEnehzy56k3b for ; Fri, 25 Apr 2008 13:46:29 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 9D89E28C35B for ; Fri, 25 Apr 2008 13:46:14 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id m3PKk8Q2021633; Fri, 25 Apr 2008 15:46:08 -0500 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 25 Apr 2008 15:46:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Updates to L2VPN (Re-)charter: VPMS, OAM & Other Misc. Tidbits Date: Fri, 25 Apr 2008 15:45:59 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04311986@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <4810A1C2.6000805@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to L2VPN (Re-)charter: VPMS, OAM & Other Misc. Tidbits Thread-Index: AcimHK8aGhWXTlgvTumKMphUiz8+4AA+GotQ From: "BALUS Florin" To: "Shane Amante" , X-OriginalArrivalTime: 25 Apr 2008 20:46:08.0184 (UTC) FILETIME=[63477B80:01C8A715] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Shane, The charter looks good. Great job in addressing all the submitted comments. Thanks, Florin=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Shane Amante > Sent: Thursday, April 24, 2008 8:06 AM > To: l2vpn@ietf.org > Subject: Updates to L2VPN (Re-)charter: VPMS, OAM & Other=20 > Misc. Tidbits >=20 > Just a reminder that we'd like to wrap-up the re-charter=20 > discussion by this Friday afternoon, April 25, 1700 MDT (UTC=20 > -6). As such, I did another pass of the most current draft=20 > text of the L2VPN charter to tidy it up. As part of that=20 > review, I've made the following changes: >=20 > 1) Native Service-Layer OAM. I've changed the "will" to=20 > "may" in the following sentence: > | On > | the other hand, the L2VPN WG may define how to operate=20 > native service- > ^^^ > | layer control, OAM or resiliency mechanisms on top of a=20 > VPLS or VPWS=20 > | service. >=20 > This should align better with the "may" in the paragraph=20 > above it that L2VPN "/may/ define extensions to pseudowire=20 > management mechanisms ...".=20 > Note, this is not to de-emphasize the importance of=20 > doing work in this area, but rather to strike a better=20 > balance in the language. In addition, although there is=20 > active interest in the WG with respect to native=20 > service-layer OAM (e.g.: 802.1ag) and clearly expect that=20 > work to continue, the WG hasn't yet decided if it wants/needs=20 > to work on native-service layer control or resiliency=20 > mechanisms on top of VPLS.=20 > Therefore, a "may" seems more appropriate in that regard as well. >=20 >=20 > 2) Submit MAC learning Optimizations milestone. I believe=20 > Florin raised a question about what is the following milestone: > | Nov 2008 Submit MAC learning optimization solutions for=20 > VPLS to IESG >=20 > I believe the above was a typo, therefore I'm going to remove=20 > the above=20 > from the charter, since that should be covered by the=20 > following milestones: > | Nov 2009 Submit scalability solutions for VPLS=20 > Control-Plane to IESG > | Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG >=20 >=20 > 3) VPMS. Finally, at this point, I see no choice, but to=20 > remove VPMS=20 > (Virtual Private Multicast Service) from the L2VPN charter. =20 > While there=20 > appears to be some interest in L2VPN to do this work, it seems fairly=20 > clear at this point that we are blocked on a decision as to=20 > whether the=20 > PWE3 WG will add P2MP PW's to its charter. If/when PWE3=20 > recharters and=20 > that WG reaches a decision on P2MP PW's, we will then=20 > entertain another=20 > re-charter to add VPMS to the L2VPN charter as well. >=20 >=20 > Please let me know if there are any comments or concerns with=20 > the above=20 > changes. In addition, the latest charter text reflecting the above=20 > changes is at the following location: > http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >=20 > Regards, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Mon Apr 28 20:54:29 2008 Return-Path: X-Original-To: l2vpn-archive@megatron.ietf.org Delivered-To: ietfarch-l2vpn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B773A699B; Mon, 28 Apr 2008 20:54:29 -0700 (PDT) X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C6F3A699B for ; Mon, 28 Apr 2008 20:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HY6mlbjQZZU for ; Mon, 28 Apr 2008 20:54:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 97A633A68FA for ; Mon, 28 Apr 2008 20:54:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 082E4268495; Mon, 28 Apr 2008 21:54:31 -0600 (MDT) Received: from pmac.castlepoint.net (71-215-85-33.hlrn.qwest.net [71.215.85.33]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Mon, 28 Apr 2008 21:54:30 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.85.33; client-port=4431; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <4023C658-0591-4347-B1ED-1E0EB6653D42@castlepoint.net> From: Shane Amante To: l2vpn@ietf.org In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04311986@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Updates to L2VPN (Re-)charter: VPMS, OAM & Other Misc. Tidbits Date: Mon, 28 Apr 2008 21:54:15 -0600 References: <4A5028372622294A99B8FFF6BD06EB7B04311986@USDALSMBS03.ad3.ad.alcatel.com> X-Mailer: Apple Mail (2.919.2) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Thank you everyone for their help in re-drafting the L2VPN WG charter. This e-mail now closes the re-chartering process. We'll forward the new charter on to the IESG for their review and, hopefully, approval. -shane On Apr 25, 2008, at 2:45 PM, BALUS Florin wrote: > Shane, > The charter looks good. Great job in addressing all the submitted > comments. > Thanks, > Florin > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Shane Amante >> Sent: Thursday, April 24, 2008 8:06 AM >> To: l2vpn@ietf.org >> Subject: Updates to L2VPN (Re-)charter: VPMS, OAM & Other >> Misc. Tidbits >> >> Just a reminder that we'd like to wrap-up the re-charter >> discussion by this Friday afternoon, April 25, 1700 MDT (UTC >> -6). As such, I did another pass of the most current draft >> text of the L2VPN charter to tidy it up. As part of that >> review, I've made the following changes: >> >> 1) Native Service-Layer OAM. I've changed the "will" to >> "may" in the following sentence: >> | On >> | the other hand, the L2VPN WG may define how to operate >> native service- >> ^^^ >> | layer control, OAM or resiliency mechanisms on top of a >> VPLS or VPWS >> | service. >> >> This should align better with the "may" in the paragraph >> above it that L2VPN "/may/ define extensions to pseudowire >> management mechanisms ...". >> Note, this is not to de-emphasize the importance of >> doing work in this area, but rather to strike a better >> balance in the language. In addition, although there is >> active interest in the WG with respect to native >> service-layer OAM (e.g.: 802.1ag) and clearly expect that >> work to continue, the WG hasn't yet decided if it wants/needs >> to work on native-service layer control or resiliency >> mechanisms on top of VPLS. >> Therefore, a "may" seems more appropriate in that regard as well. >> >> >> 2) Submit MAC learning Optimizations milestone. I believe >> Florin raised a question about what is the following milestone: >> | Nov 2008 Submit MAC learning optimization solutions for >> VPLS to IESG >> >> I believe the above was a typo, therefore I'm going to remove >> the above >> from the charter, since that should be covered by the >> following milestones: >> | Nov 2009 Submit scalability solutions for VPLS >> Control-Plane to IESG >> | Nov 2009 Submit scalability solutions for VPLS Data-Plane to IESG >> >> >> 3) VPMS. Finally, at this point, I see no choice, but to >> remove VPMS >> (Virtual Private Multicast Service) from the L2VPN charter. >> While there >> appears to be some interest in L2VPN to do this work, it seems fairly >> clear at this point that we are blocked on a decision as to >> whether the >> PWE3 WG will add P2MP PW's to its charter. If/when PWE3 >> recharters and >> that WG reaches a decision on P2MP PW's, we will then >> entertain another >> re-charter to add VPMS to the L2VPN charter as well. >> >> >> Please let me know if there are any comments or concerns with >> the above >> changes. In addition, the latest charter text reflecting the above >> changes is at the following location: >> http://l2vpn.tcb.net/recharter/l2vpn-recharter.txt >> >> Regards, >> >> -shane >>