From l2vpn-bounces@ietf.org Fri May 05 15:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Ji-0006ZL-B6; Fri, 05 May 2006 15:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6JQ-0006U7-J5; Fri, 05 May 2006 15:50:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc6JN-0002em-S9; Fri, 05 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k45Jo1vP000914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fc6JN-0008OB-DV; Fri, 05 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-signaling-08.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Provisioning, Autodiscovery, and Signaling in L2VPNs Author(s) : E. Rosen, et al. Filename : draft-ietf-l2vpn-signaling-08.txt Pages : 39 Date : 2006-5-5 Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-signaling-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-signaling-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-5125226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-signaling-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-signaling-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-5125226.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue May 09 10:48:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdTUi-0000d4-RJ; Tue, 09 May 2006 10:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdTUh-0000ae-6O for l2vpn@ietf.org; Tue, 09 May 2006 10:47:23 -0400 Received: from howler.tri.sbc.com ([205.173.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdTUe-0004OM-8a for l2vpn@ietf.org; Tue, 09 May 2006 10:47:23 -0400 Received: from sbctri.tri.sbc.com (internet-austin-webdmz.labs.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.13.6/8.12.10) with ESMTP id k49ElHuH012246 for ; Tue, 9 May 2006 09:47:17 -0500 (CDT) Received: from TSMAIL.ad.tri.sbc.com (tsmail.ad.tri.sbc.com [144.60.55.228]) by sbctri.tri.sbc.com (8.13.6/8.12.10) with ESMTP id k49ElHnr014188 for ; Tue, 9 May 2006 09:47:17 -0500 (CDT) Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 09:47:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67377.777598C4" Date: Tue, 9 May 2006 09:47:16 -0500 Message-ID: <0CED449E95A92A42991EB71B778C17BF02D0F99E@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-l2vpn-requirements Thread-Index: AcZzd3cTRHM8qvN+QJucjkGMbzSaVw== From: "Serbest, Yetik" To: X-OriginalArrivalTime: 09 May 2006 14:47:17.0169 (UTC) FILETIME=[779C9210:01C67377] X-Spam-Score: 0.0 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Subject: DISCUSS: draft-ietf-l2vpn-requirements X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C67377.777598C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everybody, =20 Sam Hartman sent the following DISCUSS after reviewing draft-ietf-l2vpn-requirements. Below please find the DISCUSS and our proposed resolution. Please let us know if you have any comments or suggestions. =20 Thanks, Yetik =20 DISCUSS-1: The L2VPN requirements do not address section 4.5.1 of RFC 3809. According to section 4.5, PPVPN solutions should address user security. Section 4.5.1 says that PPVPN solutions that include user security should support confidentiality and integrity using standard mechanism s. =20 I would strongly prefer that L2VPN handle this issue the same as L3VPN. In particular text similar to section 6.9.1 of RFC 4031 needs to be included. =20 PROPOSED RESOLUTION: Include the following text in Section 6.6 Security. When a L2VPN solution operates over a part of the Internet, it should support a configurable option to support one or more of the following standard IPsec methods for securing a customer's VPN traffic: o Confidentiality, so that only authorized devices can decrypt it o Integrity, to ensure that the data has not been altered o Authentication, to ensure that the sender is indeed who he or she claims to be=20 o Replay attack prevention. =20 The above functions SHOULD be applicable to "data traffic" of the customer, which includes the traffic exchanged between sites. It SHOULD also be possible to apply these functions to "control traffic", such as routing or signaling protocol exchanges, that are not necessarily perceived by the customer but are nevertheless essential to maintain his or her VPN. =20 Furthermore, such security methods MUST be configurable between different end-points, such as PE-PE and PE-MTU, only in the case where L2VPN data traffic is carried over IP [RFC4023]. Methods to secure data flows at the native service layer (Layer-2), from CE-CE, CE- MTU and CE-PE, are outside the scope of this document. It is also desirable to configure security on a per-VPN basis [VPNSEC]. =20 A VPN solution MAY support one or more encryption schemes, including AES, and 3DES. Encryption, decryption, and key management SHOULD be included in profiles as part of the security management system. =20 [RFC4023] Worster, T., and et. al., "Encapsulating MPLS in IP or Generic Routing Encapsulation", RFC 4023, March 2005. =20 [VPNSEC] De Clercq, J., et al., "Considerations about possible security extensions to BGP/MPLS VPN", Work in Progress. =20 =20 DISCUSS-2: Also, please confirm that nothing from RFC 4031 6.10.4 applies to L2VPN. I believe that nothing does because I believe you are not currently handling the multi-provider case. =20 PROPOSED RESOLUTION: Include the following text in Section 9 Security Considerations. In the case where a L2VPN service is carried over IP [RFC4023], traverses multiple SP networks and passes through an unsecured SP, POP, NAP, or IX, then security mechanisms MUST be employed. These security mechanisms include encryption, authentication, and resource protection, as described in section 4.5. For example, a provider should consider using both authentication and encryption for a tunnel used as part of an L2VPN that traverses another service provider's network. =20 =20 ------_=_NextPart_001_01C67377.777598C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Everybody,

 

Sam Hartman sent the following DISCUSS after = reviewing draft-ietf-l2vpn-requirements. Below please find the DISCUSS and our proposed resolution. Please let us = know if you have any comments or suggestions.

 

Thanks,

Yetik

 

DISCUSS-1:

    = The L2VPN requirements do not address section 4.5.1 of RFC = 3809.

    = According to section 4.5, PPVPN solutions should address = user

    security.  Section 4.5.1 says that PPVPN solutions that include = user

    = security should support confidentiality and integrity using = standard

    = mechanism s.

 

    = I would strongly prefer that L2VPN handle this issue the same = as

    L3VPN.  In particular text similar to section 6.9.1 of RFC 4031 = needs

    = to be included.

 

PROPOSED RESOLUTION: Include the following text in = Section 6.6 Security.

When a L2VPN solution operates over a part of the Internet, it should support = a configurable option to support one or more of the following standard = IPsec methods for securing a customer's VPN = traffic:

    o  Confidentiality, so that only authorized devices can decrypt = it

    o  Integrity, to ensure that the data has not been = altered

    o  Authentication, to ensure that the sender is indeed who he or = she claims to be

    o  Replay attack prevention.

 

 The above functions SHOULD be applicable to "data traffic" of the = customer, which includes the traffic exchanged between sites.  It  = SHOULD also be possible to apply these functions to "control traffic", = such as routing or signaling protocol exchanges, that  are not necessarily perceived by the customer but are  nevertheless essential to = maintain his or her VPN.

 

 Furthermore, such security methods MUST be configurable between different end-points, = such as PE-PE and PE-MTU, only in the case where L2VPN data traffic is = carried over IP [RFC4023].  Methods to secure data flows at the native service = layer (Layer-2), from CE-CE,

CE-

 MTU and CE-PE, are outside the scope of this document.  It is also = desirable to configure security on a per-VPN basis = [VPNSEC].

 

 A VPN solution MAY support one or more encryption schemes, including AES, = and 3DES.  Encryption, decryption, and key management SHOULD be = included in profiles as part of the security management = system.

 

   =
[RFC4023]     Worster, T., and et. al., =
"Encapsulating MPLS in IP =
or
       &nbs=
p;         Generic Routing =
Encapsulation", RFC 4023, March =
2005.

 

   =
[VPNSEC]      De Clercq, J., et al., =
"Considerations about =
possible
       &nbs=
p;         security extensions =
to BGP/MPLS VPN", Work in =
Progress.
 

 

DISCUSS-2:

    = Also, please confirm that nothing from RFC 4031 6.10.4 applies = to

    L2VPN.  I believe that nothing does because I believe you are = not

    = currently handling the multi-provider case.

 

PROPOSED RESOLUTION: Include the following text in = Section 9 Security Considerations.

    = In the case where a L2VPN service is carried over IP = [RFC4023],

    = traverses multiple SP networks and passes through an

    = unsecured SP, POP, NAP, or IX, then security mechanisms MUST = be

    employed.  These security mechanisms include = encryption,

    authentication, and resource protection, as described in section = 4.5.

    = For example, a provider should consider using both = authentication

    = and encryption for a tunnel used as part of an L2VPN that = traverses

    = another service provider's network.

 

 

------_=_NextPart_001_01C67377.777598C4-- From l2vpn-bounces@ietf.org Wed May 10 15:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduWs-0004iR-P1; Wed, 10 May 2006 15:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduWr-0004iM-DP for l2vpn@ietf.org; Wed, 10 May 2006 15:39:25 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FduWq-0005Sk-Lb for l2vpn@ietf.org; Wed, 10 May 2006 15:39:25 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4AJYM026893; Wed, 10 May 2006 15:34:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 May 2006 15:39:16 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB065C19A8@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Requirements Review] Thread-Index: AcZcWMVuEFMH2XUnScaLAou40svZLAC0GzwgBU1RtCA= From: "Dinesh Mohan" To: "Shane Amante" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Requirements Review] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Shane, Thank you for your careful review. While we have addressed the comments in details (see below), we still feel that you could have provided some of these comments along with other comments you have been providing during the review process for last couple of years now.=20 As you would notice, we propose to incorporate some of them in the next update. These have also been reviewed by some of the other contributors. The responses are marked as [DM-AS]/[DM-AS] Regards, Dinesh & Ali -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 Sent: Monday, April 10, 2006 12:38 AM To: l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Requirements Review] Ali, Dinesh, et. al, I have reviewed the OAM reqmt's and framework doc and have a substantial number of comments. In order make them more digestible, I am going to=20 split up the comments into two pieces: first, the comments relating to=20 the OAM requirements and, second, the comments relating to the OAM=20 framework. (Yes, that's reverse order, but I view the reqmt's as more=20 significant). Inside each half I have split the comments up to those=20 that are substantial/significant in nature and those that are editorial. Below is the review of the requirements section(s). Based on: a) "TBD"=20 section(s) (Section 9.2); b) incomplete security requirements (Section=20 11); and, c) solutions inside of a reqmt's doc (Section 9), I don't=20 believe it's ready for Last Call, yet. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SUBSTANTIATIVE: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sections 6 (VPLS OAM Reqmt's) and Section 7 (VPWS OAM Reqmt's) appear to be identical, except for a search & replace on VPLS with VPWS. Are=20 there, in fact, differences? If not, why are there two separate sections? [DM-AS]=20 The requirements for VPLS and VPWS are not entirely identical, especially not a search and replace on VPLS with VPWS. There are some distinct requirements called out and distinct description applicable to VPLS and/or VPWS. However, the question, IMO, should not be whether these requirements are identical or not, but whether they are complete or not for VPLS and VPWS. Please note, that we decided to keep the requirements separate since the two services are distinct and the OAM requirements can diverge, as an example see in Section 6.2.1 and 7.2.1. /[DM-AS] In Section 6, are these requirements relative to VPLS as a Bridged LAN=20 service (4.1.1), VPLS as a Network (4.1.2) or VPLS as VLAN Emulation=20 (4.1.3)? Although the title says "VPLS Service OAM requirements", it=20 might help to add a sentence/pointer back up to the top of the I-D to=20 clarify that you probably mean 4.1.1. [DM-AS] You are correct. We will add a statement in Section 6: "These requirements are applicable to VPLS as a Bridged LAN service, as described in Section 4.1.1." /[DM-AS] Why is there a Section 8, "L2VPN Network OAM Requirements", and then a=20 Section 8.1, "VPLS (V)LAN Emulation OAM Requirements"? Why not just=20 have a Section 8 that is "VPLS (V)LAN Emulation OAM Requirements" and=20 getting rid of the "L2VPN Network OAM Requirements" ... if there's not=20 going to be any VPWS Network OAM Requirements? [DM-AS] Yeah, we could rearrange Section 8 as you suggest and we will do it. In future, if we do end up identifying network requirements for VPWS, we can always create a new section. /[DM-AS] Section 9 prescribe solutions, with specific pointers to IEEE 802.1ag=20 and Y.1731, as it relates to VPLS OAM. That might be OK for a=20 "solutions document", but solutions don't belong in requirements=20 documents. Recommend striking this whole section. [DM-AS] First of all, Section 9 is marked as "OAM Operational Scenarios" and not requirements. If there would have been references to solutions (.1ag, Y.1731, VCCV, BFD) in Sections 6 or 7, which are marked specifically as "Requirements", it would not have been appropriate. As a framework document, there had been a desire expressed in our discussions to provide some guidance around abstract architectural elements. As a result, Section 9 was created which does not mandate any specific solution and indicates how different solutions including BFD, VCCV, .1ag etc can be applied as an example operational scenario. /[DM-AS] Section 9.2: Why are VPWS OAM Operational Scenarios TBD? This doc is in WG Last=20 Call, why TBD? [DM-AS] Fair point. We will remove this section and a new section can be added in future. /[DM-AS] Section 11, says: "Security issues resulting from this draft will be=20 discussed in greater depth at a later point." Is WG Last Call of the=20 document a 'later point'? ;-) I'd recommend this section dumps what's=20 currently in there and covers _at least_ the following: a) OAM messages=20 not leaking outside OAM domains; and, b) any authentication or=20 encryption reqmt's for OAM messages that may exist inside a single OAM=20 domain or that cross multiple OAM domains, etc. [DM-AS] Good comment. We will update the security section in the next version. /[DM-AS] Appendix A1: If anything, this whole section should be moved up to=20 replace of Section 9, since it discusses what appears to be OAM=20 scenarios without dragging any OAM solutions into the document. If you=20 do not believe that is acceptable, either craft a new section 9 similar=20 in language to Section 9 (e.g.: requirements, not solutions) or drop=20 Appendix A altogether. [DM-AS] Also see disposition to your comment regarding Section 9. Please note that Appendix A was specifically added based on our discussions and agreements to reflect some interim framework guidance, as you had requested. If you are interested, we could drop Appendix A? /[DM-AS] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIGNIFICANT: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 6.2.4: ---snip--- Therefore, VPLS OAM must allow alarm notification to allow suppression of service connectivity fault notifications. ---snip--- Change the above sentence to say like the following: ---snip--- Therefore, VPLS OAM must allow rate-limiting or suppression of service=20 connectivity fault notifications. ---snip--- [DM-AS] We will change the statement to: "Therefore, VPLS OAM must allow alarm notification to allow suppression of service connectivity faults notifications." /[DM-AS] Section 6.2.4: I would recommend you state that rate-limiting/suppression is a "MUST"=20 and make it (R2e). It seems to be a fundamental requirement. [DM-AS] The previous comment should address this since rate limiting is not specific to fault notifications. /[DM-AS] Section 6.5: Frame Delay variation opens up a can of worms with respect to one's=20 interpretation of between what two points are you measuring variation?=20 Specifically, is it between each packet received packet? If so, what do you do for lost packets? Or, is it for a series of packets which is=20 then averaged, etc.? ---snip--- (R5) VPLS OAM MUST support measurement of per-service frame/packet delay variation between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. ---snip--- [DM-AS] As also pointed out by Dan Romascanu's comment, we plan to add a note to the document pointing to some existing definitions (e.g. MEF, IPPM, etc.) for the performance metrics which seems to be what you are also seeking. /[DM-AS] Section 6.6: s/Data Path Execution/Data Path Forwarding/ [DM-AS] Accept. /[DM-AS] Section 6.6: Isn't the below requirement practically impossible? I'm referring=20 specifically to proprietary MPLS load-balancing hashes used on a per-hop basis in today's networks. I recommend changing this to SHOULD, and=20 making OAM implementations specifically MUST call-out where they will=20 not be forwarded on the same path as VPLS service/data frames. ---snip--- (R6) VPLS OAM frames MUST be forwarded along the same path as the VPLS service/data frames. ---snip--- [DM-AS] In the presence of ECMP the load balancing is done on a PW basis, and each PW belongs to a given VPLS instance, the OAM frames will travel the same path (i.e. links and nodes) as the data frames.=20 Given this requirement is specifically for VPLS which is bridged LAN service, the requriment still remains. We can clarify the requirement as: "(R6) VPLS OAM frames MUST be forwarded along the same path (i.e. links and nodes) as the VPLS service/data frames."=20 /[DM-AS] Section 6.7: Can you elaborate on what is the intent of this sentence? I don't follow. ---snip--- Note: The specific numbers or range of services should align with the [L2VPN-FRWK] ---snip--- [DM-AS] We intended to associate the number of service OAM instances supported to the number of service instances supported as per the L2VPN Requirements. We will update the reference from L2VPN-FRMK to L2VPN-REQ, and also update the text a little bit more to convey the intent. /[DM-AS] Section 6.12, "Backward Compatibility", & Section 6.8, "Extensibility".=20 Aren't these really one and the same? If so, shouldn't these be=20 merged into one requirement? [DM-AS] These are not the same however going thorugh the text in Section 6.8 and 6.12, we can see the potential for confusion. We will merge the two sections and clarify the text. /[DM-AS] Section 6.13: Two things here. First, I recommend moving Section 6.13 up to around=20 the same point as Frame Loss, Frame Delay, etc., since Availability is=20 one of the fundamental metrics for observing whether service is up or not. Second, it seems very odd that the I-D has no requirement with respect=20 to "availability", yet it has very precise requirements with respect to=20 Frame Loss, Frame Delay, Connectivity Fault Detection, Connectivity=20 Fault Verification, etc. Why if you have all those other requirements=20 to detect whether or not the service is up, or down, is there no=20 requirement for availability? ---snip--- Since availability measurement may be associated with connectivity, frame/packet loss, frame/packet delay and frame/packet delay variation measurements, no additional requirements are specified currently. ---snip--- [DM-AS] We will move the Availability requirement up. Wrt your comment on the need for putting a specific requirement against Availability, if the definition is built out from connectivity, FL, FD and FDV, then the OAM protocol does not need any specific mechanism for Availability. We could clarify this and also provide reference to some existing definitions of Availability. /[DM-AS] Section 8.1.1: I think a "MUST" is dangerous here, for a couple of reasons, but most=20 importantly, the signaling state associated with the [rapid] shutdown=20 and re-initialization of a large, full-mesh VPLS will almost certainly=20 lead to a catastrophic meltdown of the network. Recommend changing MUST to MAY and putting in a statement along the lines of what I just said,=20 i.e.: the network operator should be aware that this could have=20 detrimental effects on network performance. ---snip--- (R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the entire mesh of PWs to be shutdown upon detection of a partial-mesh failure condition. ---snip--- [DM-AS] Shutting down does not mean that the labels etc are withdrawn. Maybe we could make a specific statement around this point. Further, we are indicating that it must ALLOW for shutdown because there is other requirement R13c that indicates a partial mesh can be allowed if the remaining subset can be considered as full mesh. /[DM-AS] Section 8.1.1: I recommend upgrading this MAY to MUST, since this is likely to be a=20 preferred mode of operation for network operators. ---snip--- (R13c) PW OAM for PWs related to a (V)LAN emulation MAY allow the subset of PWs to be shutdown upon detection of a partial-mesh failure condition in a manner such that full mesh is present across the remaining subset. ---snip--- [DM-AS] OK, will change this. /[DM-AS] Section 8.1.3: Two comments. First, you likely want to add "rate-limiting or alarm=20 suppression". Second, I believe what you're attempting to say here is=20 that interworking must be supported between PWs and the native,=20 service-layer OAM. Is that correct? If so, then perhaps cleaning up=20 this sentence a bit would make that more clear. ---snip--- (R15) PW OAM for PWs related to a (V)LAN emulation MUST support interworking with VPLS service OAM to allow alarm suppression in the VPLS service upon fault detection in (V)LAN emulation. ---snip--- [DM-AS] We think that the requirement says what you are indicating above as your understanding. If not, please suggest the modified text that you would like to see. /[DM-AS] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D EDITORIAL: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 6.2.3: (R2c) VPLS OAM MUST allow connectivity fault localization between two VPLS service aware devices that support the VPLS same service instance within a given OAM domain. s/the VPLS same service/the same VPLS service/ [DM-AS] OK, will change this. /[DM-AS] Section 6.2.4: EMS/NMS (Element Management System/Network Management System). Change the above to just say "NMS (Network Management System)". [DM-AS] OK, will change this. /[DM-AS] Section 6.2.4: However, a single transport/network fault may cause multiple services to fail causing s/to fail causing/to fail simultaneously causing/ [DM-AS] OK, will change this. /[DM-AS] Section 6.3: ---snip--- A VPLS service may be considered degraded if it is sensitive to service frames/packets loss during transit between the VPLS service aware devices. ---snip--- I'd recommend changing the above to be: ---snip--- A VPLS service may be considered degrade if service-layer frames/packets are lost during transit between VPLS service-aware devices. ---snip--- [DM-AS] OK, will change this with "degrade" changed to "degraded" in your proposed text /[DM-AS] Section 6.7: ---snip--- though the OAM may only be used for limited VPLS services e.g. premium services and may not be used for best effort services. ---snip--- I'd recommend changing the above to be: ---snip--- though the OAM may only be used for limited VPLS service instances, for=20 example premium VPLS service instances, and may not be used for=20 best-effort VPLS services. ---snip--- [DM-AS] OK, will change this. /[DM-AS] Section 6.8: ---snip--- Extensibility is intended to allow introduction of additional functionality in future such that backward compatibility can be maintained i.e. when working with older version devices, VPLS OAM with reduced functionality is still possible. ---snip--- I'd recommend changing the above to be: ---snip--- Extensibility is intended to allow introduction of additional OAM=20 functionality in the future such that backward compatibility can be=20 maintained when interoperating with older devices. In such a case, VPLS OAM with reduced functionality should still be possible. ---snip--- [DM-AS] OK, will change this. /[DM-AS] Section 6.10: ---snip--- (R10b) VPLS OAM MAY allow adaptation/interworking with specific transport/network OAM functions. For example, this would be useful to allow Fault Notifications from transport/network layer(s) to be sent to VPLS service layer. ---snip--- s/sent to VPLS service layer/sent to the VPLS service layer/ [DM-AS] OK, will change this. /[DM-AS] Section 8.1.1: ---snip--- Therefore, when partial-mesh failure occurs in (V)LAN emulation, either the entire PW mesh should be shutdown when only an entire VPLS service is acceptable or a subset of PW with full PW mesh should be realized when partial VPLS service is acceptable. ---snip--- s/or a subset of PW with full PW mesh should be realized/or a subset=20 of PWs should be shutdown when a partial-mesh VPLS service is acceptable/ [DM-AS] s/or a subset of PW with full PW mesh should be realized/or a subset of PWs should be shutdown such that the remaining PWs have full connectivity among them/ /[DM-AS] Section 8.1.3: ---snip--- When connectivity fault is detected in (V)LAN emulation, PE devices may notify the EMS/NMS (Element Management System/Network Management System). ---snip--- s/EMS\/NMS (Element Management System\/Network Management=20 System)/NMS (Network Management System)/ Make sure to do the same in the next sentence. [DM-AS] OK, will change this. /[DM-AS] -shane Shane Amante wrote: > The authors of draft-ietf-l2vpn-oam-req-frmk-05, have requested a=20 > L2VPN WG Last Call for this I-D, "L2VPN OAM Requirements and=20 > Framework". It can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.txt >=20 > Please thoroughly review the document and send any comments to the=20 > list. Also, please indicate whether you believe this document is=20 > ready to go to the IESG "as is", or whether there should be a cleaner=20 > separation between the requirements and framework. In the latter=20 > case, the I-D would not pass LC, would need to get re-drafted for WG=20 > comments and the separate components sent out for WG Last Call again. >=20 > The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7). >=20 > -shane >=20 From l2vpn-bounces@ietf.org Fri May 12 10:00:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeYAh-00042Y-Rq; Fri, 12 May 2006 09:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeYAg-0003vC-4A for l2vpn@ietf.org; Fri, 12 May 2006 09:59:10 -0400 Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeYAe-0006L8-Qy for l2vpn@ietf.org; Fri, 12 May 2006 09:59:10 -0400 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id k4CDx5EN011766 for ; Fri, 12 May 2006 08:59:05 -0500 Received: from vkompellaxp (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k4CDxURA007851 for ; Fri, 12 May 2006 06:59:31 -0700 (PDT) From: "Vach Kompella" To: Date: Fri, 12 May 2006 06:59:05 -0700 Message-ID: <004c01c675cc$3b8e0860$cab816ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: l2vpn requirements X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org All, The l2vpn requirements draft is just inches away from being approved. There was a lot of behind the scenes discussion with Sam Hartman who helped word the security parts of the draft. =20 If we can summon up enough energy to read it one last time and send comments to the list, in light of the last set of comments that Yetik sent out, then we can hopefully clear the IESG review, and get all the other drafts in the l2vpn WG ublocked.. Please get all your comments in by May 19. Thanks. Shane & Vach From l2vpn-bounces@ietf.org Tue May 23 04:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSFF-0004LY-2s; Tue, 23 May 2006 04:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSFD-0004Gq-9s for l2vpn@ietf.org; Tue, 23 May 2006 04:27:59 -0400 Received: from [212.25.127.226] (helo=spm-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiSFA-0002J3-69 for l2vpn@ietf.org; Tue, 23 May 2006 04:27:59 -0400 Received: from dove.seabridge.co.il ([172.30.10.115]) by spm-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 11:25:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67E4A.CF8781C9" Date: Tue, 23 May 2006 11:25:06 +0200 Message-ID: <347D74C07C4F924091F863CBC284F4120265597A@dove.seabridge.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcZ+SerJovg1Jg/aSeuL91bPuM6oyQAABGzw From: "Andrei Sergeev" To: X-OriginalArrivalTime: 23 May 2006 09:25:20.0303 (UTC) FILETIME=[CFA53BF0:01C67E4A] X-Spam-Score: 0.1 (/) X-Scan-Signature: c72c29da2ca4b2bd12d89dfc936ad645 Cc: Andrei Sergeev Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C67E4A.CF8781C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, Sorry for late wake up - your proposal for MAC withdrawal with empty list enhancement looks vital for VPLS-STP coexistence. I am wandering is it accepted or not for next release of the draft. =20 Regards, Andrei Sergeev, Siemens =20 ________________________________ From: Andrei Sergeev=20 Sent: Tuesday, May 23, 2006 11:19 To: Andrei Sergeev Subject: VPLS question on MAC address withdrawal =20 Hi Marc, =20 It seems that you and pranjal are taking narrower view of the use of MAC address withdraw mechanism. This being its use during failovers to backup PE-rs in H-VPLS topology. =20 My concern is for general cases. If a TCN was triggered 5 hops deep in C-STP land and is being propagated from root to leaves. If PE-rs or MTU-s is monitoring such TCN and triggers MAC address withdraw then empty and non-empty MAC address withdraw is going to achieve different results at receiving PE-rs (as was described in my previous emails). =20 If MAC address withdraw is strictly used for H-VPLS topology for failover from primary to secondary PE-rs, then you should=20 state this restriction in the draft. If not, then may be you need another qualifier (i.e. flag) for empty MAC address withdraw list which states for a given VPLS instance, 1) age out all MAC except ones learned on PW receiving this signal ( current ) 2) age out all MAC that are learned on PW receiving this signal (new) 3) age out all MAC (new) =20 regards, himanshu -----Original Message----- From: Marc Lasserre [mailto:marc at riverstonenet.com] Sent: Wednesday, January 04, 2006 6:22 AM To: Shah, Himanshu; l2vpn at ietf.org Subject: Re: VPLS question on MAC address withdrawal Himanshu, =20 Sorry to jump a bit late in this discussion. See my answers below. =20 Cheers, Marc ----- Original Message -----=20 From: Shah, Himanshu =20 To: l2vpn at ietf.org =20 Sent: Thursday, December 29, 2005 10:19 PM Subject: VPLS question on MAC address withdrawal =20 =20 Hope somebody can shed light on the following questions....=20 (1)=20 There are two mechanisms described -=20 MAC address withdraw List TLV and empty MAC Address withdraw List TLV=20 cut-and-paste from draft.=20 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.=20 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC=20 addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending=20 a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending=20 explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were=20 associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove=20 none. However, the draft says,=20 Sending an empty MAC withdraw message will trigger all MACs to be unlearned (the 5 MACs in your examples). Only MACs behing the newly active PE-rs would be preserved. In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.=20 (2)=20 Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)?=20 If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to=20 be described.=20 The main intent is for an MTU-s to trigger MAC withdrawal to its directly attached PE-rs. The PE-rs will propagate MAC withdrawal messages to its peer PEs. There is no withdrawal event to be performed by egress MTUs. The triggering events for sending MAC withdrawals can be based on different failure detection mechanisms (eg STP based TCNs, BFD, etc). regards,=20 himanshu=20 Himanshu Shah=20 Ciena Corp=20 =20 ------_=_NextPart_001_01C67E4A.CF8781C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Himanshu,

Sorry for late = wake up – your proposal for MAC withdrawal with empty list enhancement = looks vital for VPLS-STP coexistence.

I am wandering = is it accepted or not for next release of the = draft.

 =

Regards,

Andrei = Sergeev,

Siemens

 =

From: Andrei Sergeev
Sent: Tuesday, May 23, = 2006 11:19
To: Andrei Sergeev
Subject: VPLS question on = MAC address withdrawal

 

Hi = Marc,

 

It seems = that you and pranjal are taking narrower view of the use = of

MAC address = withdraw mechanism. This being its use during

failovers = to backup PE-rs in H-VPLS topology.

 

My concern = is for general cases. If a TCN was triggered 5 = hops

deep in = C-STP land and is being propagated from root to leaves.

If PE-rs or = MTU-s is monitoring such TCN and triggers MAC

address = withdraw then empty and non-empty MAC address

withdraw is = going to achieve different results at receiving = PE-rs

(as was = described in my previous emails).

 

If MAC = address withdraw is strictly used for H-VPLS = topology

for = failover from primary to secondary PE-rs, then you should =

state this restriction in the draft. If not, then may be you = need

another = qualifier (i.e. flag) for empty MAC address withdraw list = which

states for = a given VPLS instance,

1) age out = all MAC except ones learned on PW receiving this signal ( current = )

2) age out = all MAC that are learned on PW receiving this signal = (new)

3) age out = all MAC (new)

 

regards,

himanshu

-----Original Message-----
From: Marc Lasserre = [mailto:marc at riverstonenet.com]
Sent: Wednesday, = January 04, 2006 6:22 AM
To: Shah, Himanshu; = l2vpn at ietf.org
Subject: Re: VPLS = question on MAC address withdrawal

Himanshu,

 

Sorry to jump a bit late in this = discussion.

See my answers = below.

 

Cheers,

Marc

----- Original Message ----- =

From: Shah, Himanshu

To: l2vpn at ietf.org

Sent: Thursday, December 29, 2005 10:19 PM

Subject: VPLS question on MAC address withdrawal

 

 

Hope somebody can shed light on the = following questions....

(1)
There are two mechanisms described - =
MAC address withdraw List TLV and empty MAC Address = withdraw List TLV

cut-and-paste from draft. =

6.2.2. Address Withdraw Message Containing = MAC List TLV
  
  The processing for MAC List TLV received in an Address = Withdraw
  Message is:
  
  For each MAC address in the TLV:
     - Remove the association between the MAC = address and the AC or
        PW over which this message = is received
  
  For a MAC Address Withdraw message with empty list:
     - Remove all the MAC addresses associated = with the VPLS
        instance  (specified = by the FEC TLV) except the MAC addresses
        learned over the PW = associated with this signaling session
        over which the message was received
  
  The scope of a MAC List TLV is the VPLS specified in the FEC = TLV in
  the MAC Address Withdraw Message.  The number of MAC = addresses can
  be deduced from the length field in the TLV. =

To simplify the problem, lets assume that = for a given VPLS instance A there are only 5 MAC
addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending
a list of 5 MAC address vs sending an empty list = achieves opposite result. That is, sending
explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were
associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove
none.  However, the draft says, =

Sending an empty MAC withdraw message will trigger all MACs to be unlearned (the 5 = MACs

in your examples). Only MACs behing the = newly active PE-rs would be preserved.

In order to minimize the impact on LDP = convergence time, when the
  MAC list TLV contains a large number of MAC addresses, it may = be
  preferable to send a MAC address withdrawal message with an = empty
  list.

(2)
Is MAC-Address-withdraw mechanism ever intended to be = used for U-PW (user facing PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw msg from = N-PW (PE<->PE) to U-PW, etc needs to
be described.

The main intent is for an MTU-s to trigger = MAC withdrawal to its directly attached PE-rs. The PE-rs = will

propagate MAC withdrawal messages to its = peer PEs. There is no withdrawal event to be performed by = egress

MTUs. The triggering events for sending = MAC withdrawals can be based on different failure = detection

mechanisms (eg STP based TCNs, BFD, = etc).

regards,
himanshu

Himanshu Shah
Ciena Corp

 

------_=_NextPart_001_01C67E4A.CF8781C9-- From l2vpn-bounces@ietf.org Fri May 26 10:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdGK-0005Fb-Pm; Fri, 26 May 2006 10:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdFl-0004c6-TC for l2vpn@ietf.org; Fri, 26 May 2006 10:25:25 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjd8M-0004uG-Rc for l2vpn@ietf.org; Fri, 26 May 2006 10:17:49 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 30FE4644D2 for ; Fri, 26 May 2006 08:17:39 -0600 (MDT) Message-ID: <44770E07.2020403@castlepoint.net> Date: Fri, 26 May 2006 08:17:43 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: multipart/mixed; boundary="------------020501070004090809070201" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. --------------020501070004090809070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020501070004090809070201 Content-Type: message/rfc822; name*0="Internet-Drafts Submission Cutoff Dates for the 66th IETF Meetin"; name*1="g in Montreal, Quebec, Canada" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Internet-Drafts Submission Cutoff Dates for the 66th IETF Me"; filename*1="eting in Montreal, Quebec, Canada" Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 1E9206451C for ; Thu, 25 May 2006 22:09:40 -0600 (MDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTUa-0003Cp-89; Fri, 26 May 2006 00:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTUZ-0003CZ-1y for ietf-announce@ietf.org; Fri, 26 May 2006 00:00:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjTUX-0003qf-QU for ietf-announce@ietf.org; Fri, 26 May 2006 00:00:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4Q401XO022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 May 2006 04:00:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FjTUX-0005gG-Cl for ietf-announce@ietf.org; Fri, 26 May 2006 00:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org Cc: From: ietf-secretariat@ietf.org Message-Id: Date: Fri, 26 May 2006 00:00:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------020501070004090809070201-- From l2vpn-bounces@ietf.org Mon May 29 00:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkZWS-0001hd-7m; Mon, 29 May 2006 00:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkZWQ-0001hV-Tu for l2vpn@ietf.org; Mon, 29 May 2006 00:38:30 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkZWQ-0002w6-3D for l2vpn@ietf.org; Mon, 29 May 2006 00:38:30 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 4CACF64542; Sun, 28 May 2006 22:38:23 -0600 (MDT) In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB065C19A8@zcarhxm1.corp.nortel.com> References: <183DD1B052A11A40B76125E42F1CBAAB065C19A8@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Shane Amante Date: Sun, 28 May 2006 22:38:26 -0600 To: Dinesh Mohan X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Requirements Review] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Dinesh, Ali, Comments in-line below. On May 10, 2006, at 1:39 PM, Dinesh Mohan wrote: > Shane, > > Thank you for your careful review. While we have addressed the > comments > in details (see below), we still feel that you could have provided > some > of these comments along with other comments you have been providing > during the review process for last couple of years now. > As you would notice, we propose to incorporate some of them in the > next > update. These have also been reviewed by some of the other > contributors. > > The responses are marked as [DM-AS]/[DM-AS] > > Regards, > Dinesh & Ali > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Monday, April 10, 2006 12:38 AM > To: l2vpn@ietf.org > Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 > [Requirements Review] > > > Ali, Dinesh, et. al, > > I have reviewed the OAM reqmt's and framework doc and have a > substantial > > number of comments. In order make them more digestible, I am going to > split up the comments into two pieces: first, the comments relating to > the OAM requirements and, second, the comments relating to the OAM > framework. (Yes, that's reverse order, but I view the reqmt's as more > significant). Inside each half I have split the comments up to those > that are substantial/significant in nature and those that are > editorial. > > Below is the review of the requirements section(s). Based on: a) > "TBD" > section(s) (Section 9.2); b) incomplete security requirements (Section > 11); and, c) solutions inside of a reqmt's doc (Section 9), I don't > believe it's ready for Last Call, yet. > > =================================================================== > SUBSTANTIATIVE: > =================================================================== > > Sections 6 (VPLS OAM Reqmt's) and Section 7 (VPWS OAM Reqmt's) > appear to > > be identical, except for a search & replace on VPLS with VPWS. Are > there, in fact, differences? If not, why are there two separate > sections? > > [DM-AS] > The requirements for VPLS and VPWS are not entirely identical, > especially not a search and replace on VPLS with VPWS. There are some > distinct requirements called out and distinct description > applicable to > VPLS and/or VPWS. However, the question, IMO, should not be whether > these requirements are identical or not, but whether they are complete > or not for VPLS and VPWS. > > Please note, that we decided to keep the requirements separate > since the > two services are distinct and the OAM requirements can diverge, as an > example see in Section 6.2.1 and 7.2.1. /[DM-AS] OK, so the two sections are nearly 98% identical in terms of content? When using diff, the significant majority of differences are due to formatting (extra spaces, carriage returns, etc.). The only content differences I had noticed were as follows: - As you previously noted, Section 7.2.1 (Connectivity Fault Detection), adds one reqm't (R14b). - Addition of one reqm't (R14f) to Section 7.2.4 (Connectivity Fault Alarm) - Addition of one reqm't (R18b) to Section 7.6 (Data Path Execution) - Addition of Section 7.13 (Prioritization) to the VPWS section. The goal of pointing this out is it would be much easier for readers of the I-D if there was one common section covering both VPLS & VPWS reqmt's and only the above differences were called out in a separate section as needed. However, since no one else seems to have significant concerns over this, I'm fine leaving it "as is". > In Section 6, are these requirements relative to VPLS as a Bridged LAN > service (4.1.1), VPLS as a Network (4.1.2) or VPLS as VLAN Emulation > (4.1.3)? Although the title says "VPLS Service OAM requirements", it > might help to add a sentence/pointer back up to the top of the I-D to > clarify that you probably mean 4.1.1. > > [DM-AS] > You are correct. We will add a statement in Section 6: "These > requirements are applicable to VPLS as a Bridged LAN service, as > described in Section 4.1.1." /[DM-AS] OK. > Why is there a Section 8, "L2VPN Network OAM Requirements", and then a > Section 8.1, "VPLS (V)LAN Emulation OAM Requirements"? Why not just > have a Section 8 that is "VPLS (V)LAN Emulation OAM Requirements" and > getting rid of the "L2VPN Network OAM Requirements" ... if there's not > going to be any VPWS Network OAM Requirements? > > [DM-AS] > Yeah, we could rearrange Section 8 as you suggest and we will do > it. In > future, if we do end up identifying network requirements for VPWS, we > can always create a new section. /[DM-AS] OK, sounds good. > Section 9 prescribe solutions, with specific pointers to IEEE 802.1ag > and Y.1731, as it relates to VPLS OAM. That might be OK for a > "solutions document", but solutions don't belong in requirements > documents. Recommend striking this whole section. > > [DM-AS] > First of all, Section 9 is marked as "OAM Operational Scenarios" > and not > requirements. If there would have been references to solutions (.1ag, > Y.1731, VCCV, BFD) in Sections 6 or 7, which are marked > specifically as > "Requirements", it would not have been appropriate. > > As a framework document, there had been a desire expressed in our > discussions to provide some guidance around abstract architectural > elements. As a result, Section 9 was created which does not mandate > any > specific solution and indicates how different solutions including BFD, > VCCV, .1ag etc can be applied as an example operational scenario. > /[DM-AS] The substantial part of the first half of this document (up to Section 6) is all about "OAM Framework". What's disconcerting is to read through this I-D and read the following: framework (Sections 1 - 5), reqmt's (Sections 6 - 8) and then, finally, switch briefly back into framework again (Section 9). At a minimum, it would be ideal to consolidate the framework bits all into the first part of the document, (at a minimum move Section 9 up before Section 6). At least this way Section 9 is adjacent with the rest of the framework. However, I see you mixed in a small handful of references to Section 6 (VPLS Service OAM reqmt's) into the current Section 9. Thus, I'm assuming you might be concerned over forward references if Section 9 moved up ahead of Section 6? Personally, I think the forward references would be a small concern relative to consolidating the framework together in one portion of the document to provide a more comprehensive & consolidated picture of the OAM framework. Ultimately, while I still have significant concerns relative to the content of Section 9, in the absence of any public opinion that it does not belong in this I-D that must mean everyone thinks the content is OK "as is". That said, I still want you to consider consolidating it with the rest of the framework. > Section 9.2: > Why are VPWS OAM Operational Scenarios TBD? This doc is in WG Last > Call, why TBD? > > [DM-AS] > Fair point. We will remove this section and a new section can be added > in future. /[DM-AS] OK. > Section 11, says: "Security issues resulting from this draft will be > discussed in greater depth at a later point." Is WG Last Call of the > document a 'later point'? ;-) I'd recommend this section dumps > what's > currently in there and covers _at least_ the following: a) OAM > messages > not leaking outside OAM domains; and, b) any authentication or > encryption reqmt's for OAM messages that may exist inside a single OAM > domain or that cross multiple OAM domains, etc. > > [DM-AS] > Good comment. We will update the security section in the next version. > /[DM-AS] OK. > Appendix A1: If anything, this whole section should be moved up to > replace of Section 9, since it discusses what appears to be OAM > scenarios without dragging any OAM solutions into the document. If > you > do not believe that is acceptable, either craft a new section 9 > similar > in language to Section 9 (e.g.: requirements, not solutions) or drop > Appendix A altogether. > > [DM-AS] > Also see disposition to your comment regarding Section 9. Please note > that Appendix A was specifically added based on our discussions and > agreements to reflect some interim framework guidance, as you had > requested. If you are interested, we could drop Appendix A? /[DM-AS] IMO, there is much, much more value in Appendix A1 which defines "OAM Operational Scenarios" (framework) in a much more general sense than Section 9 and without any reference to other standards. Appendix A1 even succeeds at outlining the (strengths and) weaknesses related to each of the Alternate Models, (as compared to a full-blown hierarchical OAM layering model). IMO, this general style ought to have been the same principle used in Section 9. However, since I've not been able to convince you of this and no one else has expressed similar concerns, it's OK to leave Appendix A1 in "as-is" since there is value in these Alternate Models, because they are likely the first to be deployed. > =================================================================== > SIGNIFICANT: > =================================================================== > > Section 6.2.4: > ---snip--- > Therefore, VPLS OAM must allow alarm notification to allow suppression > of service connectivity fault notifications. > ---snip--- > Change the above sentence to say like the following: > ---snip--- > Therefore, VPLS OAM must allow rate-limiting or suppression of service > connectivity fault notifications. > ---snip--- > > [DM-AS] > We will change the statement to: "Therefore, VPLS OAM must allow alarm > notification to allow suppression of service connectivity faults > notifications." /[DM-AS] Your suggested change appears confusing. Why are you opposed to the original suggested change? I thought that by using the term "rate- limiting" it could be interpreted as anything from 0 to X over some time period. Thus, if someone wanted complete "suppression" they could set a rate-limiter to 0, which is equivalent to full suppression. > Section 6.2.4: > I would recommend you state that rate-limiting/suppression is a "MUST" > and make it (R2e). It seems to be a fundamental requirement. > > [DM-AS] > The previous comment should address this since rate limiting is not > specific to fault notifications. /[DM-AS] Please see my previous comment. I still think this is necessary, since operators may not want to completely suppress all alarms, but in some cases have them rate-limited. Again, a rate-limiter can be set to 0 for those who desire complete suppression. > Section 6.5: > Frame Delay variation opens up a can of worms with respect to one's > interpretation of between what two points are you measuring variation? > Specifically, is it between each packet received packet? If so, > what do > > you do for lost packets? Or, is it for a series of packets which is > then averaged, etc.? > ---snip--- > (R5) VPLS OAM MUST support measurement of per-service frame/packet > delay > variation between two VPLS service aware devices that support the same > VPLS service instance within a given OAM domain. > ---snip--- > > [DM-AS] > As also pointed out by Dan Romascanu's comment, we plan to add a > note to > the document pointing to some existing definitions (e.g. MEF, IPPM, > etc.) for the performance metrics which seems to be what you are also > seeking. /[DM-AS] OK. > Section 6.6: > s/Data Path Execution/Data Path Forwarding/ > > [DM-AS] > Accept. > /[DM-AS] > > Section 6.6: > Isn't the below requirement practically impossible? I'm referring > specifically to proprietary MPLS load-balancing hashes used on a > per-hop > > basis in today's networks. I recommend changing this to SHOULD, and > making OAM implementations specifically MUST call-out where they will > not be forwarded on the same path as VPLS service/data frames. > ---snip--- > (R6) VPLS OAM frames MUST be forwarded along the same path as the VPLS > service/data frames. > ---snip--- > > [DM-AS] > In the presence of ECMP the load balancing is done on a PW basis, and > each PW belongs to a given VPLS instance, the OAM frames will > travel the > same path (i.e. links and nodes) as the data frames. > > Given this requirement is specifically for VPLS which is bridged LAN > service, the requriment still remains. We can clarify the requirement > as: > "(R6) VPLS OAM frames MUST be forwarded along the same path (i.e. > links > and nodes) as the VPLS service/data frames." > /[DM-AS] I wasn't referring to ECMP, but rather load-balancing of a given PW "flow" across multiple links in a single link-bundle between two adjacent devices. Typically, implementations take some number of MPLS labels for a given MPLS datagram, then calculate a hash which determines the individual link a PW "flow" will be forwarded on. Since these hash algorithms are proprietary to every vendor, there is no standard. The bottom-line is you can't guarantee the behavior of the network wrt forwarding of datagrams in the presence of this type of load-balancing, (because it depends on what is consumed as input to the load-balancing hash). While I agree that this type of load- balancing could cause problems relative to associating a given OAM fault with a particular PW used by a VPLS service, it is a fact of life in today's networks and will likely be around for the foreseeable future. One way to address this concern is to make R6 a "SHOULD" (and not a "MUST"). Then, add a second paragraph to Section 6.6, before the requirement, that says something like the following: ---snip--- Load-balancing of PW's between two adjacent devices in a link-bundle may result in VPLS OAM frames not fate-sharing with the VPLS data- plane traffic. Operators concerned with this incongruity between OAM and data-plane traffic may design their network to avoid these scenarios. ---snip--- > Section 6.7: > Can you elaborate on what is the intent of this sentence? I don't > follow. > ---snip--- > Note: The specific numbers or range of services should align with the > [L2VPN-FRWK] > ---snip--- > > [DM-AS] > We intended to associate the number of service OAM instances supported > to the number of service instances supported as per the L2VPN > Requirements. We will update the reference from L2VPN-FRMK to L2VPN- > REQ, > and also update the text a little bit more to convey the intent. > /[DM-AS] OK. > Section 6.12, "Backward Compatibility", & Section 6.8, > "Extensibility". > Aren't these really one and the same? If so, shouldn't these be > merged into one requirement? > > [DM-AS] > These are not the same however going thorugh the text in Section > 6.8 and > 6.12, we can see the potential for confusion. We will merge the two > sections and clarify the text. /[DM-AS] OK. > Section 6.13: > Two things here. First, I recommend moving Section 6.13 up to around > the same point as Frame Loss, Frame Delay, etc., since Availability is > one of the fundamental metrics for observing whether service is up or > not. Second, it seems very odd that the I-D has no requirement with > respect > to "availability", yet it has very precise requirements with > respect to > Frame Loss, Frame Delay, Connectivity Fault Detection, Connectivity > Fault Verification, etc. Why if you have all those other requirements > to detect whether or not the service is up, or down, is there no > requirement for availability? > ---snip--- > Since availability measurement may be associated with connectivity, > frame/packet loss, frame/packet delay and frame/packet delay variation > measurements, no additional requirements are specified currently. > ---snip--- > > [DM-AS] > We will move the Availability requirement up. Wrt your comment on the > need for putting a specific requirement against Availability, if the > definition is built out from connectivity, FL, FD and FDV, then the > OAM > protocol does not need any specific mechanism for Availability. We > could > clarify this and also provide reference to some existing > definitions of > Availability. /[DM-AS] OK, please move Availability up. Related to the second point, what reference to an existing definition of Availability are you considering pointing at? > Section 8.1.1: > I think a "MUST" is dangerous here, for a couple of reasons, but most > importantly, the signaling state associated with the [rapid] shutdown > and re-initialization of a large, full-mesh VPLS will almost certainly > lead to a catastrophic meltdown of the network. Recommend changing > MUST > > to MAY and putting in a statement along the lines of what I just said, > i.e.: the network operator should be aware that this could have > detrimental effects on network performance. > ---snip--- > (R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the > entire mesh of PWs to be shutdown upon detection of a partial-mesh > failure condition. > ---snip--- > > [DM-AS] > Shutting down does not mean that the labels etc are withdrawn. Why would the labels not be withdrawn? > Maybe we > could make a specific statement around this point. This might help, but I still need to see what your thinking wrt the previous question. > Further, we are > indicating that it must ALLOW for shutdown because there is other > requirement R13c that indicates a partial mesh can be allowed if the > remaining subset can be considered as full mesh. /[DM-AS] Perhaps the way I should consider this is to reverse the order of these two reqmt's? IOW, an implementation is likely to consider R13c first and, if that reqm't can't be met, only then do R13b. Is that your thinking? Aside from that, I'm still concerned with the potential for a catastrophic meltdown due to the tear-down of several PW's triggered by an OAM fault condition. One way to address this concern wrt R13b is to suggest a pacing of PW teardown, label withdraw messages, PW re- initialization, etc. to avoid killing the network. I won't push this point to wait to see how you're going to address the first question as to why labels won't be withdrawn and how that is supposed to help alleviate the potential for pathological churn on the network. > Section 8.1.1: > I recommend upgrading this MAY to MUST, since this is likely to be a > preferred mode of operation for network operators. > ---snip--- > (R13c) PW OAM for PWs related to a (V)LAN emulation MAY allow the > subset > of PWs to be shutdown upon detection of a partial-mesh failure > condition > in a manner such that full mesh is present across the remaining > subset. > ---snip--- > > [DM-AS] > OK, will change this. /[DM-AS] Before changing this, let's agree to the course of action on R13b above. > Section 8.1.3: > Two comments. First, you likely want to add "rate-limiting or alarm > suppression". Second, I believe what you're attempting to say here is > that interworking must be supported between PWs and the native, > service-layer OAM. Is that correct? If so, then perhaps cleaning up > this sentence a bit would make that more clear. > ---snip--- > (R15) PW OAM for PWs related to a (V)LAN emulation MUST support > interworking with VPLS service OAM to allow alarm suppression in the > VPLS service upon fault detection in (V)LAN emulation. > ---snip--- > > [DM-AS] > We think that the requirement says what you are indicating above as > your > understanding. If not, please suggest the modified text that you would > like to see. /[DM-AS] OK, try this text: ---snip--- (R15) PW OAM for PWs related to a (V)LAN emulation MUST support interworking with native service-layer OAM to allow alarm suppression in the VPLS service-layer upon fault detection in the native service layer, or vice-versa. ---snip--- [--snipped to end--] All of the rest of the editorial changes look good. -shane From l2vpn-bounces@ietf.org Tue May 30 07:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl2E0-0004b9-Ks; Tue, 30 May 2006 07:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl2Dz-0004b4-CU for l2vpn@ietf.org; Tue, 30 May 2006 07:17:23 -0400 Received: from smtp103.plus.mail.re2.yahoo.com ([206.190.53.28]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fl2Dy-00079x-1o for l2vpn@ietf.org; Tue, 30 May 2006 07:17:23 -0400 Received: (qmail 20753 invoked from network); 30 May 2006 11:17:21 -0000 Received: from unknown (HELO LIFEBOOK) (vsharma87@59.184.36.60 with login) by smtp103.plus.mail.re2.yahoo.com with SMTP; 30 May 2006 11:17:21 -0000 From: "Vishal Sharma" To: Date: Tue, 30 May 2006 04:17:53 -0700 Organization: Metanoia, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcaD2rHGbCXJ3wbhSHWr4x6nYvE8ew== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: 'Nasir Ghani' , "'Fang, Luyuan, ALABS'" Subject: CFP: "Advances in VPNs": Special Issue IEEE Comm. Mag. X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: v.sharma@ieee.org List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Message-Id: Dear Colleagues, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "Advances in Virtual Private Networks (VPNs)." The CFP is attached below, We invite those working in this area to consider sending in their contributions. And, we appreciate your forwarding this CFP on to your colleagues and associates. If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the special issue. We look forward to your participation! Best regards, -Luyuan, Nasir, and Vishal ***************************************************************** *************************** IEEE Communications Magazine Feature Topic on "Advances in Virtual Private Networks? VPN's have become one of the biggest success stories of the recent years and related service offerings represent a key area of expansion and revenue generation for new and incumbent service providers worldwide. This is particularly important given the ongoing decline in legacy service revenues, such as long distance voice, private line, etc. Whether it be AT&T in the US, France Telecom in Europe, BSNL in India, or NTT in Japan, each one of these network providers is now offering managed VPN services to both large and small and medium enterprise (SME) customers. As this market continues to expand, VPN paradigms are evolving to deliver new levels of capability and attracting wider interest from the academic research community. Along these lines, the purpose of this special issue is to present the IEEE Communications Magazine readership with the latest advances in the overall VPN area, i.e., Layers 1-3. Broadly, this will include issues pertaining to standards and architectures, resource allocation/traffic engineering algorithms, real-world deployment experiences, and emerging challenges. Indeed, these contemporary issues are of interest to many in the networking community, including carriers providing VPN services, standards organizations (IETF, ITU-T), and academic researchers. In particular, some of the main topics include (but are not necessarily limited to) the following: * VPN standards for architectures and service models as developed in the IETF and ITU-T. Commensurate evolutions in networking protocol and equipment requirements. * Resource provisioning and QoS support schemes for Layers 1-3 VPN. Current state-of-the-art in QoS provisioning in IP/MPLS-based carrier VPN services. * VPN topology overlay design and traffic engineering considerations. Multi-area/domain VPN design and issues. * Routing and signalling protocols considerations for VPN. Related implementations in distributed, centralized, and hybrid control environments along with scalability issues. * VPN service survivability and reliability schemes for Layers 1, 2, and 3. Feasibility of dedicated and/or shared resource models. * Security and operations management for Layer 1/2/3 VPN services. Including topics such as authentication, encryption, key management, control plane security. * Infrastructure virtualization via Layer 1 VPN (circuit-switched), comparisons with capabilities and scope of Layer 2 and 3 VPN (packet switched) services. * Business models for deploying VPN services and the experience of enterprise customers and carriers in deploying the different types of VPN services. Comparisons versus traditional private line services. * Migration strategies between legacy Layer 2 VPN and IP/MPLS Layer 3 VPN, including impacts and requirements for carriers and end-user clients. * Current research developments in various aspects of VPN development, analysis, and deployment. Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided there is consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than 15 September 2006. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: 15 September 2006 Acceptance Notification: 15 December 2006 Final Manuscript Due: 31 January 2007 Publication Date: April 2007 Guest Editors Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Nasir Ghani, Tennesse Tech. University (nghani@tntech.edu) Luyuan Fang, AT&T Labs. (luyuanfang@att.com) On-line version of this CFP: http://www.metanoia-inc.com/AdvancesinVPNs_IEEECommMag_FT_CFP.htm