From l2vpn-bounces@ietf.org Thu Feb 01 15:51:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCisy-0003Ef-I4; Thu, 01 Feb 2007 15:50:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCisj-0002aq-21; Thu, 01 Feb 2007 15:50:09 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCisc-0006qg-NQ; Thu, 01 Feb 2007 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A7E83329FF; Thu, 1 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-00085i-IG; Thu, 01 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-07.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 : L2VPN OAM Requirements and Framework Author(s) : D. Mohan, A. Sajassi Filename : draft-ietf-l2vpn-oam-req-frmk-07.txt Pages : 35 Date : 2007-2-1 This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-07.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-oam-req-frmk-07.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-oam-req-frmk-07.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: <2007-2-1115229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-oam-req-frmk-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-oam-req-frmk-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-1115229.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Feb 06 03:25:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELcs-0004NX-Bx; Tue, 06 Feb 2007 03:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELcr-0004NK-Jz for l2vpn@ietf.org; Tue, 06 Feb 2007 03:24:29 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HELcq-0008O2-Bf for l2vpn@ietf.org; Tue, 06 Feb 2007 03:24:29 -0500 Received: by nf-out-0910.google.com with SMTP id l36so109223nfa for ; Tue, 06 Feb 2007 00:24:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tX1GqlPVaNsNbxnc1FFo7414qz7hxtKS3wNlDn5a0pLbfyXYOm4fRIWrqD3Gae8AnNNJE5W2GbrOwpxY0pbPYBnrkPM8O0PELKfa7QiTm89O+xAEHbqtmyBrBcJZIqguamlypvxd5tO44yINytllFvoCDRAuVUeTSbFXf5GgRoc= Received: by 10.48.217.20 with SMTP id p20mr191474nfg.1170750267127; Tue, 06 Feb 2007 00:24:27 -0800 (PST) Received: by 10.49.42.14 with HTTP; Tue, 6 Feb 2007 00:24:27 -0800 (PST) Message-ID: Date: Tue, 6 Feb 2007 13:54:27 +0530 From: "sujay gupta" To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2401_27514575.1170750267099" X-Spam-Score: 0.7 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: test 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 ------=_Part_2401_27514575.1170750267099 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ------=_Part_2401_27514575.1170750267099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
------=_Part_2401_27514575.1170750267099-- From l2vpn-bounces@ietf.org Thu Feb 15 13:20:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHlCh-0003Ha-6O; Thu, 15 Feb 2007 13:19:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHlCf-0003HU-MI for l2vpn@ietf.org; Thu, 15 Feb 2007 13:19:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHlCd-0003Jk-Ca for l2vpn@ietf.org; Thu, 15 Feb 2007 13:19:33 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 Feb 2007 10:19:31 -0800 X-IronPort-AV: i="4.14,176,1170662400"; d="scan'208"; a="389466954:sNHT1423497692" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1FIJT8N016688; Thu, 15 Feb 2007 10:19:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1FIJPUw000173; Thu, 15 Feb 2007 10:19:25 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 10:19:24 -0800 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 Date: Thu, 15 Feb 2007 10:19:23 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02C320E4@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call for L2VPN drafts Thread-Index: AcdRLdFZgXupt6C9QjyaZWhrEB2eyQ== From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" , "Vach Kompella" X-OriginalArrivalTime: 15 Feb 2007 18:19:25.0149 (UTC) FILETIME=[D291B0D0:01C7512D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=295; t=1171563569; x=1172427569; c=relaxed/simple; s=sjdkim6002; 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:=20WG=20last=20call=20for=20L2VPN=20drafts |Sender:=20; bh=m3PIIjUpJ1vb/nLvetNMVk4zOtEQMMgU1cFYUklQDVs=; b=QlEOJFa4lMW47Pe2l3/TdKGzxujG2Ta8ybL2uDKSIivwLwTzWvmh9BYof9l7n8oajGRg3SLW h3z88YfaEHGCQu29YqjfzrxzZ8CFTPJmvFCINLOczIOsXRAIYzoZCT/t; Authentication-Results: sj-dkim-6; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: l2vpn@ietf.org Subject: WG last call for L2VPN drafts 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, The following two IETF drafts have been updated for quite sometime and they are ready for the WG last call. Would you please initiate the last call for these two drafts. draft-ietf-l2vpn-oam-req-frmk-07.txt draft-ietf-l2vpn-vpls-bridge-interop-01.txt Thanks, Ali & Dinesh From l2vpn-bounces@ietf.org Thu Feb 15 22:44:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHu02-00081o-LB; Thu, 15 Feb 2007 22:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHu01-00080h-D6 for l2vpn@ietf.org; Thu, 15 Feb 2007 22:43:05 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHu00-0004a8-6G for l2vpn@ietf.org; Thu, 15 Feb 2007 22:43:05 -0500 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 C838164500; Thu, 15 Feb 2007 20:42:58 -0700 (MST) In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02C320E4@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02C320E4@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Shane Amante Date: Thu, 15 Feb 2007 20:43:00 -0700 To: Ali Sajassi (sajassi) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: l2vpn@ietf.org, Vach Kompella Subject: Re: WG last call for L2VPN drafts 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 Hi Ali, I have not had an opportunity to (re-)review the changes to draft- ietf-l2vpn-oam-req-frmk-07, yet. I'd like the opportunity to do so before issuing another WG Last Call. However, I will issue a WG Last Call for draft-ietf-l2vpn-vpls-bridge- interop-01 right now. Thanks for the reminder. -shane On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote: > > Shane, > > The following two IETF drafts have been updated for quite sometime and > they are ready for the WG last call. Would you please initiate the > last > call for these two drafts. > > draft-ietf-l2vpn-oam-req-frmk-07.txt > draft-ietf-l2vpn-vpls-bridge-interop-01.txt > > Thanks, > Ali & Dinesh From l2vpn-bounces@ietf.org Thu Feb 15 22:48:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHu4s-0003Yg-KQ; Thu, 15 Feb 2007 22:48:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHu4r-0003Xq-Ql for l2vpn@ietf.org; Thu, 15 Feb 2007 22:48:05 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHu4q-0005sU-JL for l2vpn@ietf.org; Thu, 15 Feb 2007 22:48:05 -0500 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 A721F64500 for ; Thu, 15 Feb 2007 20:48:01 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <551A17FF-64D4-48D6-8207-B2A4A4DC1509@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Thu, 15 Feb 2007 20:48:02 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: WG Last Call: draft-ietf-l2vpn-vpls-bridge-interop-01 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 the start of the WG Last Call for: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-bridge-interop-01 Please e-mail the list with any comments, concerns or corrections. Last Call on this draft will end in two weeks, on Friday, March 2, 2007, at 17:00 MST (UTC -7). Thanks, -shane & Vach From l2vpn-bounces@ietf.org Tue Feb 20 10:01:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWTj-0006Oj-Gf; Tue, 20 Feb 2007 10:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWTh-0006OO-ED for l2vpn@ietf.org; Tue, 20 Feb 2007 10:00:25 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWTf-0006jr-7e for l2vpn@ietf.org; Tue, 20 Feb 2007 10:00:25 -0500 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 B4BC66472A for ; Tue, 20 Feb 2007 08:00:09 -0700 (MST) Message-ID: <45DB0CF5.90606@castlepoint.net> Date: Tue, 20 Feb 2007 08:00:05 -0700 From: Shane Amante User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: IETF 68 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 We have a 1-hour slot scheduled for L2VPN at IETF 68 in Prague on Wednesday, March 21, 1510-1610. If you have an item you'd like to discuss, please e-mail Vach and I ASAP. Thanks! -shane & Vach From l2vpn-bounces@ietf.org Tue Feb 20 17:30:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdUi-0003gs-LY; Tue, 20 Feb 2007 17:29:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdUg-0003eu-Vw for l2vpn@ietf.org; Tue, 20 Feb 2007 17:29:54 -0500 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJdUf-0000xl-NQ for l2vpn@ietf.org; Tue, 20 Feb 2007 17:29:54 -0500 Received: by wx-out-0506.google.com with SMTP id h31so2274882wxd for ; Tue, 20 Feb 2007 14:29:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rXSdjJZ7qfTmXexNvLRlUyhSHppnzC8aBYpLFZqnCM6tmCi3v4aX17MrHdrM20Z3g1QFZsucVkCebxTibZNj1yCQn5QZt3Hlf3aeXMcZXQCS+43zyjR46ri2l9AuHhzoMNJG6dPM85jxMeKnQvBVug2CDqCPffxQeie1XudVBfo= Received: by 10.70.29.7 with SMTP id c7mr14455770wxc.1172010593167; Tue, 20 Feb 2007 14:29:53 -0800 (PST) Received: by 10.70.10.14 with HTTP; Tue, 20 Feb 2007 14:29:53 -0800 (PST) Message-ID: Date: Wed, 21 Feb 2007 09:29:53 +1100 From: "Simon Delord" To: "Shane Amante" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_63809_24240257.1172010593095" References: <75B2A84D9323BC4CA3977CF378CE75EB02C320E4@xmb-sjc-21e.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: l2vpn@ietf.org, sajassi Ali Sajassi , Vach Kompella Subject: Re: WG last call for L2VPN drafts 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 ------=_Part_63809_24240257.1172010593095 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Shane, Can you please provide an update on the following document: draft-ietf-l2vpn-oam-req-frmk-07 ? As par of the co-authors, I'd like to know what is the plan regarding the updated document which has been in the works for such a long time and has undergone extensive reviews. I am really interested in seeing the draft through as we have invested lot of time in bringing the draft to the current maturity. Regards, Simon 2007/2/16, Shane Amante : > > Hi Ali, > > I have not had an opportunity to (re-)review the changes to draft- > ietf-l2vpn-oam-req-frmk-07, yet. I'd like the opportunity to do so > before issuing another WG Last Call. > > However, I will issue a WG Last Call for draft-ietf-l2vpn-vpls-bridge- > interop-01 right now. Thanks for the reminder. > > -shane > > > > On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote: > > > > > Shane, > > > > The following two IETF drafts have been updated for quite sometime and > > they are ready for the WG last call. Would you please initiate the > > last > > call for these two drafts. > > > > draft-ietf-l2vpn-oam-req-frmk-07.txt > > draft-ietf-l2vpn-vpls-bridge-interop-01.txt > > > > Thanks, > > Ali & Dinesh > > > ------=_Part_63809_24240257.1172010593095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Shane,

Can you please provide an update on the following document:
draft-ietf-l2vpn-oam-req-frmk-07 ?
 
As par of the co-authors, I'd like to know what is the
plan regarding the updated document which has been
in the works for such a long time and has undergone extensive reviews.
 
I am really interested in seeing the draft through as we have invested lot of time
in bringing the draft to the current maturity.
 
Regards,
 
         Simon
 
2007/2/16, Shane Amante <shane@castlepoint.net>:
Hi Ali,

I have not had an opportunity to (re-)review the changes to draft-
ietf-l2vpn-oam-req-frmk-07, yet.  I'd like the opportunity to do so
before issuing another WG Last Call.

However, I will issue a WG Last Call for draft-ietf-l2vpn-vpls-bridge-
interop-01 right now.  Thanks for the reminder.

-shane



On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote:

>
> Shane,
>
> The following two IETF drafts have been updated for quite sometime and
> they are ready for the WG last call. Would you please initiate the
> last
> call for these two drafts.
>
> draft-ietf-l2vpn-oam-req-frmk-07.txt
> draft-ietf-l2vpn-vpls-bridge-interop-01.txt
>
> Thanks,
> Ali & Dinesh



------=_Part_63809_24240257.1172010593095-- From l2vpn-bounces@ietf.org Tue Feb 20 22:37:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJiH6-0007qc-4q; Tue, 20 Feb 2007 22:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJiH4-0007pR-Tk for l2vpn@ietf.org; Tue, 20 Feb 2007 22:36:10 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJiGy-0006Q0-7Z for l2vpn@ietf.org; Tue, 20 Feb 2007 22:36:06 -0500 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 266FD6462D; Tue, 20 Feb 2007 20:35:54 -0700 (MST) In-Reply-To: References: <75B2A84D9323BC4CA3977CF378CE75EB02C320E4@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BA3AC0F-7AE2-4134-BA0A-1F1D3E7C2050@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Tue, 20 Feb 2007 20:35:56 -0700 To: Simon Delord X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: l2vpn@ietf.org, sajassi Ali Sajassi , Vach Kompella Subject: Re: WG last call for L2VPN drafts 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 Ali, et. al, I looked through the archives, but I don't see a reply to my message from 23 July 2006: http://www1.ietf.org/mail-archive/web/l2vpn/current/msg01268.html If it was missed, can you please point me to it? If not, can you let me know your response? Thanks, -shane On Feb 20, 2007, at 3:29 PM, Simon Delord wrote: > Hi Shane, > > Can you please provide an update on the following document: > draft-ietf-l2vpn-oam-req-frmk-07 ? > > As par of the co-authors, I'd like to know what is the > plan regarding the updated document which has been > in the works for such a long time and has undergone extensive reviews. > > I am really interested in seeing the draft through as we have > invested lot of time > in bringing the draft to the current maturity. > > Regards, > > Simon > > 2007/2/16, Shane Amante : Hi Ali, > > I have not had an opportunity to (re-)review the changes to draft- > ietf-l2vpn-oam-req-frmk-07, yet. I'd like the opportunity to do so > before issuing another WG Last Call. > > However, I will issue a WG Last Call for draft-ietf-l2vpn-vpls-bridge- > interop-01 right now. Thanks for the reminder. > > -shane > > > > On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote: > > > > > Shane, > > > > The following two IETF drafts have been updated for quite > sometime and > > they are ready for the WG last call. Would you please initiate the > > last > > call for these two drafts. > > > > draft-ietf-l2vpn-oam-req-frmk-07.txt > > draft-ietf-l2vpn-vpls-bridge-interop-01.txt > > > > Thanks, > > Ali & Dinesh > > > From l2vpn-bounces@ietf.org Wed Feb 21 04:10:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnSj-0006IP-R1; Wed, 21 Feb 2007 04:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnSi-0006IF-QE for l2vpn@ietf.org; Wed, 21 Feb 2007 04:08:32 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJnSh-0006do-8Q for l2vpn@ietf.org; Wed, 21 Feb 2007 04:08:32 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 21 Feb 2007 01:08:30 -0800 X-IronPort-AV: i="4.14,200,1170662400"; d="scan'208"; a="41197989:sNHT173579346" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1L98UEQ023622; Wed, 21 Feb 2007 01:08:30 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1L98Oho018514; Wed, 21 Feb 2007 01:08:24 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 01:08:24 -0800 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 Date: Wed, 21 Feb 2007 01:08:22 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02C87681@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <1BA3AC0F-7AE2-4134-BA0A-1F1D3E7C2050@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call for L2VPN drafts Thread-Index: AcdVaW5CAORfSE8VShe9fFHvvo8sUwAFNofA From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" , "Simon Delord" X-OriginalArrivalTime: 21 Feb 2007 09:08:24.0013 (UTC) FILETIME=[D7132FD0:01C75597] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2868; t=1172048910; x=1172912910; c=relaxed/simple; s=sjdkim7002; 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=20WG=20last=20call=20for=20L2VPN=20drafts |Sender:=20; bh=KOj0sqY5RgMBp0ckJPp6TgCAckW6tuqfAW15Cx+o0SY=; b=lQMRFHUSp1+U1etKjJilri2qjV9giafQolQHq4soZMbfxGF5E6fQ0Q2d6FHr6QMrmVII5s+D cHXp3njv+pyMgqZVt0X0mYgABFwtlkQSW30va7k2j6mZMX5OGbzAq53n; Authentication-Results: sj-dkim-7; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: l2vpn@ietf.org, Vach Kompella Subject: RE: WG last call for L2VPN drafts 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 Hi Shane, Since your response was sent about a month after my response, I must have lost track of it and forgot to respond to it. Sorry for that. I went over your comments and I have tried to address all of them. I will send another email separately regarding my response to your July/06 comments. Frankly, after going over your comments, I didn't see any contentious issues. And given that we have address most of your comments in several rounds of edits and the remaining comments are of the nature of providing further clarifications in the text (refer to my response please), I was thinking if you can issue the WG last call and then I will incorporate these changes as part of the final edit for the last call.=20 Regards, Ali =20 =20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Tuesday, February 20, 2007 7:36 PM > To: Simon Delord > Cc: Ali Sajassi (sajassi); l2vpn@ietf.org; Vach Kompella > Subject: Re: WG last call for L2VPN drafts >=20 > Ali, et. al, >=20 > I looked through the archives, but I don't see a reply to my=20 > message from 23 July 2006: > http://www1.ietf.org/mail-archive/web/l2vpn/current/msg01268.html >=20 > If it was missed, can you please point me to it? If not, can=20 > you let me know your response? >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 > On Feb 20, 2007, at 3:29 PM, Simon Delord wrote: > > Hi Shane, > > > > Can you please provide an update on the following document: > > draft-ietf-l2vpn-oam-req-frmk-07 ? > > > > As par of the co-authors, I'd like to know what is the plan=20 > regarding=20 > > the updated document which has been in the works for such a=20 > long time=20 > > and has undergone extensive reviews. > > > > I am really interested in seeing the draft through as we=20 > have invested=20 > > lot of time in bringing the draft to the current maturity. > > > > Regards, > > > > Simon > > > > 2007/2/16, Shane Amante : Hi Ali, > > > > I have not had an opportunity to (re-)review the changes to draft-=20 > > ietf-l2vpn-oam-req-frmk-07, yet. I'd like the opportunity to do so=20 > > before issuing another WG Last Call. > > > > However, I will issue a WG Last Call for=20 > draft-ietf-l2vpn-vpls-bridge- > > interop-01 right now. Thanks for the reminder. > > > > -shane > > > > > > > > On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote: > > > > > > > > Shane, > > > > > > The following two IETF drafts have been updated for quite > > sometime and > > > they are ready for the WG last call. Would you please=20 > initiate the=20 > > > last call for these two drafts. > > > > > > draft-ietf-l2vpn-oam-req-frmk-07.txt > > > draft-ietf-l2vpn-vpls-bridge-interop-01.txt > > > > > > Thanks, > > > Ali & Dinesh > > > > > > >=20 From l2vpn-bounces@ietf.org Wed Feb 21 04:10:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnSw-0006RQ-8U; Wed, 21 Feb 2007 04:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnSu-0006RH-3T for l2vpn@ietf.org; Wed, 21 Feb 2007 04:08:44 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJnSs-0006eS-2E for l2vpn@ietf.org; Wed, 21 Feb 2007 04:08:44 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 21 Feb 2007 01:08:41 -0800 X-IronPort-AV: i="4.14,200,1170662400"; d="scan'208"; a="114731570:sNHT80700633" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1L98f7N000715; Wed, 21 Feb 2007 01:08:41 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1L98eho018603; Wed, 21 Feb 2007 01:08:41 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 01:08:40 -0800 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 Date: Wed, 21 Feb 2007 01:08:39 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02C87682@xmb-sjc-21e.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcautvAKj/CqYKM7QEy104hXHL4z4imyPPVg From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" X-OriginalArrivalTime: 21 Feb 2007 09:08:40.0748 (UTC) FILETIME=[E10CBEC0:01C75597] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21399; t=1172048921; x=1172912921; c=relaxed/simple; s=sjdkim8002; 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=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-0 5=20[FrameworkReview] |Sender:=20; bh=RDe4G+iBO6DCDenwtkdX8Y7G0JuemllZXM5WFxZjyIY=; b=b4zFqdRBNhzmGsbDXyzxlzLgRH3h2aWEg1vSmXonl5dKWAmYBe5WMnx9IQLWi1cwnSbrB8MZ twU4FmjGLl3qU8IrLgHfwzl7R/OXcj/vwO28I3abBWbYdIh6GVjOcqvn; Authentication-Results: sj-dkim-8; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 =20 Hi Shane, Please refer to my comments inline. As you can see I think we are very close in wrapping this up. Regards, Ali =20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Sunday, July 23, 2006 5:20 PM > To: Ali Sajassi (sajassi) > Cc: l2vpn@ietf.org > Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > [FrameworkReview] >=20 > Hi Ali, >=20 > Please see below. >=20 > On Jun 23, 2006, at 12:09 AM, Ali Sajassi (sajassi) wrote: > > Shane, > > > > Thank you for your detailed comments. Please refer to our=20 > replies in=20 > > line. We will incorporate the ones agreed upon in the next=20 > rev. of the=20 > > document. > > > > Regards, > > Ali & Dinesh > > > >> -----Original Message----- > >> From: Shane Amante [mailto:shane@castlepoint.net] > >> Sent: Sunday, April 09, 2006 9:41 PM > >> To: l2vpn@ietf.org > >> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > >> [FrameworkReview] > >> > >> Ali, Dinesh, et. al, > >> > >> As stated in an earlier e-mail, below are the comments relating to=20 > >> the Framework section(s). > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > >> > >> Section 1: > >> I understand the intent to have a comprehensive set of OAM=20 > reqmt's,=20 > >> but I'm not sure why the L2VPN WG specifically needs to=20 > take on the=20 > >> breadth of what this statement suggests, specifically "a reference=20 > >> model for OAM layering and furthermore emphasizes the=20 > importance of=20 > >> proper independent layering in design and development of OAM=20 > >> functionality across ..." > >> Wouldn't proper OAM layering be a topic more suitable for the Ops=20 > >> Area? > >> ---snip--- > >> This document provides a description and a reference model for OAM=20 > >> layering and furthermore emphasizes the importance of proper=20 > >> independent layering in design and development of OAM=20 > functionality=20 > >> across L2VPN services, Pseudo Wires (PWs) and Public=20 > Switched Network=20 > >> (PSN) tunnels. > >> ---snip--- > >> > > > > In VPLS because the native Ethernet service is transported over PWs=20 > > and PSN tunnels, it is important to identify the interaction among=20 > > these different layers and identify how the failure in PW or PSN=20 > > transport layers can impact VPLS service layer and that is=20 > why we have=20 > > established this OAM layering model. Also, in the previous=20 > > discussions, we were asked to identify the impact of PW and=20 > PSN layer=20 > > failure on VPLS service layer. If in addition to L2VPN WG,=20 > you would=20 > > like to present this layering to Ops area, then please make such=20 > > recommendation. >=20 > Perhaps some word-smithing might alleviate this concern. How about > this: > ---snip--- > This document provides a description and reference model for=20 > OAM as it relates to L2VPN services, which are comprised of=20 > Pseudo Wires > (PWs) and Public Switched Network (PSN) tunnels. > ---snip--- > I'm not sure you need to mention OAM layering or its=20 > importance in this paragraph, because that is captured by the=20 > phrase "description and reference model for OAM" in the=20 > sentence above. It is also captured in much detail=20 > throughout the framework portion of the document. >=20 >=20 That's fine. I will change it to: "This document provides a description and reference model for=20 OAM as it relates to L2VPN services and their associated=20 Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels." >=20 >=20 > >> Section 3.3 (MEPs and MIPs) > >> It would be *extremely* useful to address this comment, as=20 > it relates=20 > >> to "Scalability" of VPLS OAM, in Sections 6 (& 7). > >> Specifically, in a mp2p environment like VPLS, it would be=20 > useful to=20 > >> assert some guidelines as it relates to the number of ME's per=20 > >> service instance per PE, (particularly for the "sink PE" that is a=20 > >> receiver of n(n-1)/2 ME messages). > >> ---snip--- > >> A ME is a point-to-point association between a pair of MEPs and=20 > >> represents a monitored entity. For example, in a VPLS=20 > service which=20 > >> involves n CEs, all the MEs associated with the VPLS=20 > service in the=20 > >> customer OAM domain (i.e. from CE to CE) can be considered=20 > to be part=20 > >> of a VPLS MEG, where the n-point MEG consists of a maximum of=20 > >> n(n-1)/2 MEs. > >> ---snip--- > >> > > > > Accept. We will add a sentence or two to indicate that a=20 > MEP on a PE=20 > > will receive messages from (n-1) other MEPs (on the same or=20 > other PEs=20 > > for the same ME group). >=20 > OK. >=20 >=20 > >> Section 4.1.1 (VPLS as Bridged LAN Service) thru 4.1.3=20 > (VPLS as (V)=20 > >> LAN > >> Emulation): > >> I'm not sure I'm comfortable with these sections. > >> Specifically, I think what you're describing in Section=20 > 4.1.1 is VPLS=20 > >> operates as a peer-layer to the native (Ethernet)=20 > service-layer. In=20 > >> Section 4.1.2, I think you are attempting to describe VPLS as a=20 > >> peer-layer as well as a client-layer to an underlying MPLS or IP=20 > >> substrate. Finally, I think in Section 4.1.3, you're=20 > finally up to=20 > >> VPLS as a service-layer in its own right. Is that correct? > > > > No, that is not correct. The intention of this section is=20 > to describe=20 > > different interpretation of VPLS as reflected in some of the drafts=20 > > and L2VPN framework document because it is important to=20 > first clarify=20 > > what VPLS refers to, before identifying what OAM tools=20 > needed for it. > > Section > > 4.1.1 is the most common definition for VPLS (e.g., as an=20 > end-to-end=20 > > multipoint Ethernet service over different types of=20 > network). However,=20 > > section 4.1.2 and section 4.1.3 talks about different=20 > definitions of=20 > > VPLS - e.g., as a network where it support multiple of service=20 > > instances and as a LAN emulation part which only contains=20 > full mesh of=20 > > PWs along with its forwarders and talks about the fact that OAM for=20 > > those are handled differently. So, the intention of this=20 > section is to=20 > > clarify what we mean by VPLS (which is section 4.1.1) and=20 > > correspondingly what OAM tools are needed for it. >=20 > Thanks for providing some context around these sections. A=20 > few things might help to be clarified: > 1) In 4.1.2, you state that this is out-of-scope for this=20 > document; however, it would be useful to state that Sections=20 > 4.1.1 and 4.1.3 are what is being addressed by later sections=20 > of this OAM document. O.K. We'll do. > 2) In Section 4.1.1, it's stated that: > ---snip--- > To check the end-to-end service integrity, service=20 > level OAM mechanisms > are needed. > ---snip--- > I'm not comfortable with the words "service level" as they=20 > stand above. Is it referring to the VPLS service level,=20 > (e.g.: VPLS-LDP/ VPLS-BGP signaling, VPLS Forwarders as=20 > defined in L2VPN framework, > etc.) or to the IEEE 802.1 service level or both? >=20 It basically refers to multipoint Ethernet service which is provided via network elements - PE and bridging devices (for providing bridging/swtiching) functions and P devices (for providing tunneling function). And it is from AC to AC.=20 > Is there another L2VPN (or PWE3) document to which you can=20 > provide a pointer as to a definition of 'service layer'? =20 > (See the next comment for more context about a suggestion I=20 > have to hopefully address this comment). >=20 Basically service layer is the layer at which the multipoint Ethernet service is offered.=20 >=20 >=20 > >> If so, then I think we need to be careful in Sections 4.1.1 and > >> 4.1.2 when referring the native Ethernet service-layer=20 > (particularly=20 > >> in the context of the access-layer networks), that this is=20 > >> out-of-scope for this work product (and the IETF). > > > > That is not the case. Please refer to section 11 of vpls-ldp draft. >=20 > Section 11 of VPLS-LDP states the following: > ---snip--- > The details regarding bridge operation for MTU-s and PE-rs (e.g., > encapsulation format for Q-in-Q messages, customer's Ethernet > control protocol handling, etc.) are outside of the scope of this > document and they are covered in [802.1ad]. However, the relevant > part is the interaction between the bridge module and the MPLS/IP > PWs in the PE-rs, which behaves just as in a regular VPLS. > ---snip--- > The above section from VPLS-LDP states that bridging=20 > operation for the MTU-s and PE-rs are outside its scope, but=20 > that the interaction between the bridge module and MPLS/IP=20 > PWs in the PE-rs are important. I believe this sentence=20 > applies to Section 4.1.1 and, subsequently, the OAM=20 > requirements section, specifically as it relates to protocols=20 > we may create or augment to address OAM of VPLS/ VPWS=20 > services. Perhaps it's useful to 'borrow' this paragraph=20 > from VPLS-LDP in order to clarify that the 'service-layer' to=20 > which you refer in the "VPLS as a Bridged LAN service"=20 > section relates directly to this interaction. >=20 Yes, the brdiging operation are outside of the scope since they are already specified in IEEE 802.1ad spec; however, the fact that the aggregation of CE devices can be provided by MTU-s switches still remains the same. Basically, the mode of operation is H-VPLS with Ethernet access and Ethernet access is part of provider (not the customer) and as such when providers want end to end coverage, they want from AC to AC (e.g., among CE devices) and not just part of a network. The good thing is that in the draft we have covered both end to end service as well as the portion that just spans MPLS/IP network and we have covered the interaction between the two which is very important - e.g., if a fault happens in MPLS core, then how it is propagated to MTU-s bridges. > Because the introduction to Section 6 (VPLS Service OAM=20 > Requirements) has a reference back to Section 4.1.1: > ---snip--- > These requirements are applicable to VPLS as a Bridged=20 > LAN service, > as described in Section 4.1.1. Further, the performance=20 > metrics used > in requirements are based on [MEF10] and [RFC2544]. > ---snip--- > ... I think it's important that you clarify the service-layer. Sounds good. We will further clarify and describe service-layer. >=20 > In addition, in Section 6, it would useful to state that=20 > although the Framework may provide a comprehensive OAM=20 > solution set, the requirements for a L2VPN-defined OAM=20 > _protocol suite_ will be a subset of the Framework (along the=20 > lines of what VPLS-LDP says) related to those aspects of=20 > L2VPN protocols, signaling, etc. =20 > previously defined, owned & maintained by the L2VPN WG. > Considering that MTU-s and PE-rs have bridging modules in them, I don't think it would make any difference with respect to OAM framework and requirements specifications as whether they are directly connected with each other or they are connected via another set of bridges (e.g., via Ethernet network). In other words, we still need to perform fault management for MTU-s and PE-rs when the network is H-VPLS with Ethernet access and when you have the capability to do that, then you can do it for the intermediate nodes connecting the MTU-s to PE-rs.=20 =20 >=20 >=20 > >> In addition, in Section 4.1.2, there's a vague statement=20 > with respect=20 > >> to OAM mechanisms at the "network level". The way the current=20 > >> sentence is phrased, I believe you are saying that=20 > network-layer OAM=20 > >> mechanisms are required; however, it's not in our charter to solve=20 > >> MPLS-layer OAM. (Note, to be fair, you do say in Section=20 > 4.2.1 that=20 > >> OAM at the transport-layer is out-of-scope of this doc,=20 > but perhaps=20 > >> copying/moving that statement up to here would be useful)? > >> ---snip--- > >> To check the network > >> integrity regardless of the network topology, network level OAM=20 > >> mechanisms are needed for the VPLS networks. > >> ---snip--- > >> Related to the last comment, the words "network level" is IMO=20 > >> vague. > >> Perhaps it would be better to state that it refers to=20 > network-layer=20 > >> protocols such as MPLS, GRE/IP or L2TPv3? > >> > > > > O.K., we will add a sentence or two to clarify it further. > > > > > >> Section 4.2.2: > >> It doesn't look like the lines in the diagram in Figure 4,=20 > for A, B &=20 > >> C are properly aligned. You should fix them. > >> > > > > Great! We will do that. > > > >> Section 4.2.3: > >> Again, it doesn't look like the diagram in Figure 5 is properly=20 > >> aligned with the scenarios depicted in A, B & C. > >> > > > > It looks pretty align to us, but we will search for=20 > mis-alignment. If=20 > > you can point out expilictly what is misaligned, it would help. > > > >> Section 4.2.3: > >> In general, this section says that it is 'expected' that MEPs and=20 > >> MIPs will be implemented into various components of the VPLS=20 > >> architecture, (VPLS forwarder/briding modules). Are you=20 > discussing=20 > >> the OAM framework here, or do these 'expected' > >> details surrounding an eventual implementation which would=20 > mean these=20 > >> would translate into MUSTs or SHOULDs in the reqmt's=20 > sections? (I'm=20 > >> trying to seek clarity of what you're intent is with these=20 > >> statements, because I don't see anything related to MEPs=20 > and MIPs in=20 > >> the reqmt's section). > >> > > > > Our intention here is to satisfy your previous request as=20 > to show the=20 > > MEPs and MIPs relate to L2VPN framework. >=20 > OK. >=20 >=20 > >> Section 4.2.3: > >> (D) depicts both MEPs and MIPs, however this sentence only=20 > discusses=20 > >> expectations around MEPs ... what about the MIPs in Scenario (D)? > >> ---snip--- > >> (D) represents the MEPs and MIPs > >> visible within the service provider domain. These MEPs are=20 > expected=20 > >> to be implemented in the bridge module/VPLS forwarder of a=20 > PE device,=20 > >> as per the [L2VPN-FRWK]. > >> ---snip--- > >> > > > > Agreed. We will clarify it by adding MIPs to the above sentence: =20 > > "These > > MEPs and MIPs are expected ..." >=20 > OK. >=20 >=20 > >> Section 4.2.3: > >> In which components of the VPLS architecture do you expect=20 > the MEPs=20 > >> and MIPs in (E) to be implemented? > >> > > > > Agreed. We will clarify this by indicating that the MIPs=20 > for (E) would=20 > > exist when you have an Ethernet access network (e.g., section 11 of=20 > > vpld-ldp draft). >=20 > OK. >=20 >=20 > >> Section 4.2.4: > >> What about VPLS-BGP? What identifiers are used for it, since it=20 > >> doesn't use PW-id's? > >> > > > > PW-ids are used in VPLS-BGP but instead they are signaled=20 > via BGP and=20 > > we don't care about what signaling mechanism is used. >=20 > VPLS-LDP uses PWid's. VPLS-BGP uses a demultiplexor label=20 > defined as (Label Block + VE ID - VE Block Offset). > Perhaps it would useful to clarify that you are referring to=20 > the demultiplexor label, in order to be less specific as to=20 > one protocol or the other? Alternatively, clarify that with=20 > VPLS-BGP it would be what's stated above. >=20 It is really the same thing. The VPLS-BGP draft talks about PW and its associated signaling (setup and tear down). PW by definition is the demultiplexor label within the PSN tunnel. So both are the same and the use of PW id makes the reference consistent irregardless of signaling type (BGP v.s. LDP).=20 >=20 > >> Section 4.2.4: > >> ---snip--- > >> Both PW-ids and VLAN tags for a given VPLS instance are associated=20 > >> with a Service Identifier (e.g., VPN identifier). > >> ---snip--- > >> Which identifier do you have in mind, i.e.: VPLS-ID in=20 > >> l2vpn-signaling? > >> > > > > By PW-id, it is meant the associated MPLS label. >=20 > OK. >=20 >=20 > >> Section 5: > >> Diagrams aren't aligned Figure 6, VPWS Reference Model. > >> > > > > We must complement you for your keen eyes :-) We will fix it. > > > > > >> Section 5.2: > >> What are you trying to say here? > >> ---snip--- > >> In common scenarios, it could or simply a point-to-point=20 > interface of=20 > >> certain type. The core network connecting PEs can be IP,=20 > MPLS, etc. > >> ---snip--- > >> > > > > The statement ought to be: "In common scenarios, it could=20 > simply be a > > point-to-point ... Such as Ethernet PHY" and we will change it. > > > >> Section 5.2: > >> To which network types are you referring? Can you somehow > >> reference back to the heterogenous & homogeneous terminology > >> introduced in the aforementioned section? > >> ---snip--- > >> Therefore, it is important that the OAM mechanisms can be > >> applied to all these network types. > >> ---snip--- > >> > > > > We will change the sentence to "Therefore, it is important that OAM > > mechanisms can be applied to different network types some of which > > mentioned above" > > > > > >> Section 5.2.1: > >> Diagrams in Figure 7 are not aligned properly, and I believe > >> you're missing a > describing the right-most end-point in the =20 > >> diagram. > >> > > > > Right, We will fix it. > > > > > >> Section 5.2.2: > >> Diagrams in Figure 8a & 8b are not aligned properly, and I > >> believe you're missing a > describing the right-most > >> end-point in the diagram. > >> > > > > That's fine, we'll fix it. > > > >> Section 5.2.2: > >> ---snip--- > >> "The service provider is responsible to monitor the PW ME" > >> "... the monitoring requirements across the AC ME are minimal." > >> ---snip--- > >> What is the "PW ME" and "AC ME"? The term "ME" hasn't been > >> defined as it related specifically to PW's or AC's. > >> Furthermore, does ME refer to the NSP, or some other > >> function/layer of VPWS? > >> > > > > Section 1.1 has a clear definition of ME which one can apply to any > > types of entity such as service, PW, AC, etc. >=20 > OK. >=20 >=20 > >> Section 5.2.2: > >> ---snip--- > >> The > >> distinction between Figure 8b (C) and (D) is that (C) MEs > >> have MEPs at CE and PEs and have no MIPs while (D) MEs have > >> MEPs at CEs and PEs and likely MIPs in between, thereby > >> having a visibility to Operator network. > >> ---snip--- > >> Can you clarify this part of the sentence: "(C) MEs have > >> MEPs at CE and PEs and have no MIPs" ... specifically, it's > >> not clear at all > >> (e.g.: to which devices or components of VPWS) where MEPs and > >> MIPs are applicable. > >> Can you also clarify the second half of that sentence > >> "(D) MEs have MEPs at CEs and PEs and likely MIPs in between, > >> thereby having a visibility to Operator network." ... again, > >> it's not clear where (e.g.: > >> to which devices or components of VPWS) MEPs are MIPs are > >> applicable. I think it's just the way you're phrasing it, so > >> perhaps re-phrasing in a better way would be good. > >> > > > > We belive the phrasing is causing some confusion to you and we will > > further clarify it as: "The distinction between Figure 8(b)-C, and > > 8(b)-D is that in (C), MEs have MEPs at CEs and at Pes, and have no > > MIPs. While in (D) MEs have MEPs at CEs and at PEs and=20 > furthermore, =20 > > MIPs > > may be present in between the MEPs; thereby providing=20 > visibility of =20 > > the > > network to the operator." >=20 > OK. >=20 > [---snipped for brevity---] >=20 > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >=20 > [---snip---] >=20 > >> 5.2: > >> ---snip--- > >> As an example, the access network between CE and PE on one > >> side can be Ethernet bridged network, ATM network, etc. > >> ---snip--- > >> s/be Ethernet bridged network/be an Ethernet bridged/ > > > > Reject. It is intended to say "bridged network" as defined in IEEE > > standards >=20 > I was just asking to insert an 'an' into your sentence. I'm not =20 > clear on why you would reject that change? >=20 >=20 > [---snipped to end---] >=20 > Thanks, >=20 > -shane >=20 From l2vpn-bounces@ietf.org Wed Feb 21 21:56:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK46C-0007LD-6y; Wed, 21 Feb 2007 21:54:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK46A-0007L3-Ha for l2vpn@ietf.org; Wed, 21 Feb 2007 21:54:22 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK469-000738-5s for l2vpn@ietf.org; Wed, 21 Feb 2007 21:54:22 -0500 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 02EE964610; Wed, 21 Feb 2007 19:54:14 -0700 (MST) In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02C87681@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02C87681@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <542905A5-67A0-403A-8675-0123F67CF0F7@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Wed, 21 Feb 2007 19:54:16 -0700 To: Ali Sajassi (sajassi) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: l2vpn@ietf.org, Vach Kompella Subject: Re: WG last call for L2VPN drafts 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 Ali, On Feb 21, 2007, at 2:08 AM, Ali Sajassi (sajassi) wrote: > > Hi Shane, > > Since your response was sent about a month after my response, I must > have lost track of it and forgot to respond to it. Sorry for that. I > went over your comments and I have tried to address all of them. I > will > send another email separately regarding my response to your July/06 > comments. Frankly, after going over your comments, I didn't see any > contentious issues. And given that we have address most of your > comments > in several rounds of edits and the remaining comments are of the > nature > of providing further clarifications in the text (refer to my response > please), I was thinking if you can issue the WG last call and then I > will incorporate these changes as part of the final edit for the last > call. It does appear we are closer to reaching consensus. However, I don't want to issue a Last Call, until everyone can at least see the proposed changes you are going to make. Although you may consider them minor, I disagree and believe them to still be significant. How about if you send proposed text to the list to address those comments? Once we agree to that, you can incorporate those comments into a new version, quickly submit it and we'll issue a Last Call on it? -shane > > Regards, > Ali > > >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Tuesday, February 20, 2007 7:36 PM >> To: Simon Delord >> Cc: Ali Sajassi (sajassi); l2vpn@ietf.org; Vach Kompella >> Subject: Re: WG last call for L2VPN drafts >> >> Ali, et. al, >> >> I looked through the archives, but I don't see a reply to my >> message from 23 July 2006: >> http://www1.ietf.org/mail-archive/web/l2vpn/current/msg01268.html >> >> If it was missed, can you please point me to it? If not, can >> you let me know your response? >> >> Thanks, >> >> -shane >> >> >> >> On Feb 20, 2007, at 3:29 PM, Simon Delord wrote: >>> Hi Shane, >>> >>> Can you please provide an update on the following document: >>> draft-ietf-l2vpn-oam-req-frmk-07 ? >>> >>> As par of the co-authors, I'd like to know what is the plan >> regarding >>> the updated document which has been in the works for such a >> long time >>> and has undergone extensive reviews. >>> >>> I am really interested in seeing the draft through as we >> have invested >>> lot of time in bringing the draft to the current maturity. >>> >>> Regards, >>> >>> Simon >>> >>> 2007/2/16, Shane Amante : Hi Ali, >>> >>> I have not had an opportunity to (re-)review the changes to draft- >>> ietf-l2vpn-oam-req-frmk-07, yet. I'd like the opportunity to do so >>> before issuing another WG Last Call. >>> >>> However, I will issue a WG Last Call for >> draft-ietf-l2vpn-vpls-bridge- >>> interop-01 right now. Thanks for the reminder. >>> >>> -shane >>> >>> >>> >>> On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote: >>> >>>> >>>> Shane, >>>> >>>> The following two IETF drafts have been updated for quite >>> sometime and >>>> they are ready for the WG last call. Would you please >> initiate the >>>> last call for these two drafts. >>>> >>>> draft-ietf-l2vpn-oam-req-frmk-07.txt >>>> draft-ietf-l2vpn-vpls-bridge-interop-01.txt >>>> >>>> Thanks, >>>> Ali & Dinesh >>> >>> >>> >> From l2vpn-bounces@ietf.org Thu Feb 22 11:34:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKGsv-0003PC-7B; Thu, 22 Feb 2007 11:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKGsu-0003Oz-8P for l2vpn@ietf.org; Thu, 22 Feb 2007 11:33:32 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKGsr-0004uq-PX for l2vpn@ietf.org; Thu, 22 Feb 2007 11:33:32 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2007 08:33:29 -0800 X-IronPort-AV: i="4.14,207,1170662400"; d="scan'208"; a="41643681:sNHT50859441" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1MGXTXI021273; Thu, 22 Feb 2007 08:33:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1MGX4i2001954; Thu, 22 Feb 2007 08:33:19 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 08:33:15 -0800 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 Date: Thu, 22 Feb 2007 08:33:15 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02CF609C@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <542905A5-67A0-403A-8675-0123F67CF0F7@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call for L2VPN drafts Thread-Index: AcdWLMhp7Hbhjh6GSTah1ksSTbO7mwAchkIQ From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" X-OriginalArrivalTime: 22 Feb 2007 16:33:15.0954 (UTC) FILETIME=[271FE920:01C7569F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4157; t=1172162009; x=1173026009; c=relaxed/simple; s=sjdkim7002; 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=20WG=20last=20call=20for=20L2VPN=20drafts |Sender:=20; bh=w1u9Zq+hfb+zzVdzMzDy5urpf6NjQ8fjn2sbqfPOwZU=; b=Jth39t1SonJbKbYaVH2nGGnAWvTn0a+gKmN8fGXHIMZMckTh3QqUDGkjZVTyhTxU19uWAsde nBltXadaHUo9ciFf0YYRpud5/WQZudhy4Q6/BOar90mImcbx/qPbCdfU; Authentication-Results: sj-dkim-7; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: l2vpn@ietf.org, Vach Kompella Subject: RE: WG last call for L2VPN drafts 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, I will be in meetings all day, I will send the proposed changes for the remaining comments tonight or tomorrow. -Ali=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Wednesday, February 21, 2007 6:54 PM > To: Ali Sajassi (sajassi) > Cc: Simon Delord; l2vpn@ietf.org; Vach Kompella > Subject: Re: WG last call for L2VPN drafts >=20 > Ali, >=20 > On Feb 21, 2007, at 2:08 AM, Ali Sajassi (sajassi) wrote: > > > > Hi Shane, > > > > Since your response was sent about a month after my=20 > response, I must=20 > > have lost track of it and forgot to respond to it. Sorry=20 > for that. I=20 > > went over your comments and I have tried to address all of them. I=20 > > will send another email separately regarding my response to your=20 > > July/06 comments. Frankly, after going over your comments, I didn't=20 > > see any contentious issues. And given that we have address most of=20 > > your comments in several rounds of edits and the remaining comments=20 > > are of the nature of providing further clarifications in the text=20 > > (refer to my response please), I was thinking if you can=20 > issue the WG=20 > > last call and then I will incorporate these changes as part of the=20 > > final edit for the last call. >=20 > It does appear we are closer to reaching consensus. However,=20 > I don't want to issue a Last Call, until everyone can at=20 > least see the proposed changes you are going to make. =20 > Although you may consider them minor, I disagree and believe=20 > them to still be significant. How about if you send proposed=20 > text to the list to address those comments? Once we agree to=20 > that, you can incorporate those comments into a new version,=20 > quickly submit it and we'll issue a Last Call on it? >=20 > -shane >=20 >=20 >=20 >=20 > > > > Regards, > > Ali > > > > > >> -----Original Message----- > >> From: Shane Amante [mailto:shane@castlepoint.net] > >> Sent: Tuesday, February 20, 2007 7:36 PM > >> To: Simon Delord > >> Cc: Ali Sajassi (sajassi); l2vpn@ietf.org; Vach Kompella > >> Subject: Re: WG last call for L2VPN drafts > >> > >> Ali, et. al, > >> > >> I looked through the archives, but I don't see a reply to=20 > my message=20 > >> from 23 July 2006: > >> http://www1.ietf.org/mail-archive/web/l2vpn/current/msg01268.html > >> > >> If it was missed, can you please point me to it? If not,=20 > can you let=20 > >> me know your response? > >> > >> Thanks, > >> > >> -shane > >> > >> > >> > >> On Feb 20, 2007, at 3:29 PM, Simon Delord wrote: > >>> Hi Shane, > >>> > >>> Can you please provide an update on the following document: > >>> draft-ietf-l2vpn-oam-req-frmk-07 ? > >>> > >>> As par of the co-authors, I'd like to know what is the plan > >> regarding > >>> the updated document which has been in the works for such a > >> long time > >>> and has undergone extensive reviews. > >>> > >>> I am really interested in seeing the draft through as we > >> have invested > >>> lot of time in bringing the draft to the current maturity. > >>> > >>> Regards, > >>> > >>> Simon > >>> > >>> 2007/2/16, Shane Amante : Hi Ali, > >>> > >>> I have not had an opportunity to (re-)review the changes=20 > to draft-=20 > >>> ietf-l2vpn-oam-req-frmk-07, yet. I'd like the=20 > opportunity to do so=20 > >>> before issuing another WG Last Call. > >>> > >>> However, I will issue a WG Last Call for > >> draft-ietf-l2vpn-vpls-bridge- > >>> interop-01 right now. Thanks for the reminder. > >>> > >>> -shane > >>> > >>> > >>> > >>> On Feb 15, 2007, at 11:19 AM, Ali Sajassi (sajassi) wrote: > >>> > >>>> > >>>> Shane, > >>>> > >>>> The following two IETF drafts have been updated for quite > >>> sometime and > >>>> they are ready for the WG last call. Would you please > >> initiate the > >>>> last call for these two drafts. > >>>> > >>>> draft-ietf-l2vpn-oam-req-frmk-07.txt > >>>> draft-ietf-l2vpn-vpls-bridge-interop-01.txt > >>>> > >>>> Thanks, > >>>> Ali & Dinesh > >>> > >>> > >>> > >> >=20 From l2vpn-bounces@ietf.org Fri Feb 23 20:40:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKls0-00014D-Rr; Fri, 23 Feb 2007 20:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKls0-000144-7y for l2vpn@ietf.org; Fri, 23 Feb 2007 20:38:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKlry-0002uB-45 for l2vpn@ietf.org; Fri, 23 Feb 2007 20:38:40 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Feb 2007 17:38:37 -0800 X-IronPort-AV: i="4.14,213,1170662400"; d="scan'208"; a="115775702:sNHT87319728" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1O1cbaJ024436; Fri, 23 Feb 2007 17:38:37 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1O1cSGq029269; Fri, 23 Feb 2007 17:38:33 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 17:38:30 -0800 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 Date: Fri, 23 Feb 2007 17:38:29 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02CF677E@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02C87682@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcautvAKj/CqYKM7QEy104hXHL4z4imyPPVgAIslojA= From: "Ali Sajassi \(sajassi\)" To: "Ali Sajassi \(sajassi\)" , "Shane Amante" X-OriginalArrivalTime: 24 Feb 2007 01:38:30.0764 (UTC) FILETIME=[7D1582C0:01C757B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25076; t=1172281117; x=1173145117; 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=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-0 5=20[FrameworkReview] |Sender:=20; bh=kCNfzrArEolhcvazOIV01Z3XRoEUD5eKqD7U2KPrVc8=; b=N2GLDHoc3iwwMdxOgbAwG/OSmmHvowtsPg9md+MToHLS+mapPomucf/s6Ddb8oq7Ganf4SOk yWMkd5kescOMPx7EMf5Mm1PtwQ/hhgW/8XNLsPf2mVP6rUheKl3X99Ow; Authentication-Results: sj-dkim-4; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 =20 Shane, I have basically added the text as you have requested/suggested (please refer to the text inline). Let me know please if there are still some I's that I need to dot or T's that I need to cross before the WG last call :-) So, if you are O.K. with these changes, we can either add them after we go through the last call or do it before hand. My preference is after the call since I can do all the editing in one shot and avoid unnecessary overhead of going through multiple edit/release cycles. I would appreciate your prompt response as this draft has been gating issue for any work on OAM solution draft. Regards, Ali > -----Original Message----- > From: Ali Sajassi (sajassi)=20 > Sent: Wednesday, February 21, 2007 1:09 AM > To: Shane Amante > Cc: l2vpn@ietf.org > Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > [FrameworkReview] >=20 > =20 > Hi Shane, >=20 > Please refer to my comments inline. As you can see I think we=20 > are very close in wrapping this up. >=20 > Regards, > Ali =20 >=20 > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Sunday, July 23, 2006 5:20 PM > > To: Ali Sajassi (sajassi) > > Cc: l2vpn@ietf.org > > Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > > [FrameworkReview] > >=20 > > Hi Ali, > >=20 > > Please see below. > >=20 > > On Jun 23, 2006, at 12:09 AM, Ali Sajassi (sajassi) wrote: > > > Shane, > > > > > > Thank you for your detailed comments. Please refer to our > > replies in > > > line. We will incorporate the ones agreed upon in the next > > rev. of the > > > document. > > > > > > Regards, > > > Ali & Dinesh > > > > > >> -----Original Message----- > > >> From: Shane Amante [mailto:shane@castlepoint.net] > > >> Sent: Sunday, April 09, 2006 9:41 PM > > >> To: l2vpn@ietf.org > > >> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > > >> [FrameworkReview] > > >> > > >> Ali, Dinesh, et. al, > > >> > > >> As stated in an earlier e-mail, below are the comments=20 > relating to=20 > > >> the Framework section(s). > > >> > > >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: > > >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 1: > > >> I understand the intent to have a comprehensive set of OAM > > reqmt's, > > >> but I'm not sure why the L2VPN WG specifically needs to > > take on the > > >> breadth of what this statement suggests, specifically "a=20 > reference=20 > > >> model for OAM layering and furthermore emphasizes the > > importance of > > >> proper independent layering in design and development of OAM=20 > > >> functionality across ..." > > >> Wouldn't proper OAM layering be a topic more suitable=20 > for the Ops=20 > > >> Area? > > >> ---snip--- > > >> This document provides a description and a reference=20 > model for OAM=20 > > >> layering and furthermore emphasizes the importance of proper=20 > > >> independent layering in design and development of OAM > > functionality > > >> across L2VPN services, Pseudo Wires (PWs) and Public > > Switched Network > > >> (PSN) tunnels. > > >> ---snip--- > > >> > > > > > > In VPLS because the native Ethernet service is=20 > transported over PWs=20 > > > and PSN tunnels, it is important to identify the=20 > interaction among=20 > > > these different layers and identify how the failure in PW or PSN=20 > > > transport layers can impact VPLS service layer and that is > > why we have > > > established this OAM layering model. Also, in the previous=20 > > > discussions, we were asked to identify the impact of PW and > > PSN layer > > > failure on VPLS service layer. If in addition to L2VPN WG, > > you would > > > like to present this layering to Ops area, then please make such=20 > > > recommendation. > >=20 > > Perhaps some word-smithing might alleviate this concern. How about > > this: > > ---snip--- > > This document provides a description and reference model=20 > for OAM as it=20 > > relates to L2VPN services, which are comprised of Pseudo Wires > > (PWs) and Public Switched Network (PSN) tunnels. > > ---snip--- > > I'm not sure you need to mention OAM layering or its importance in=20 > > this paragraph, because that is captured by the phrase "description=20 > > and reference model for OAM" in the sentence above. It is also=20 > > captured in much detail throughout the framework portion of the=20 > > document. > >=20 > >=20 >=20 > That's fine. I will change it to: > "This document provides a description and reference model for=20 > OAM as it relates to L2VPN services and their associated=20 > Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels." >=20 Proposed text: Change the text to: "This document provides a description and reference model for=20 OAM as it relates to L2VPN services and their associated=20 Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels." > >=20 > >=20 > > >> Section 3.3 (MEPs and MIPs) > > >> It would be *extremely* useful to address this comment, as=20 > > it relates=20 > > >> to "Scalability" of VPLS OAM, in Sections 6 (& 7). > > >> Specifically, in a mp2p environment like VPLS, it would be=20 > > useful to=20 > > >> assert some guidelines as it relates to the number of ME's per=20 > > >> service instance per PE, (particularly for the "sink PE"=20 > that is a=20 > > >> receiver of n(n-1)/2 ME messages). > > >> ---snip--- > > >> A ME is a point-to-point association between a pair of MEPs and=20 > > >> represents a monitored entity. For example, in a VPLS=20 > > service which=20 > > >> involves n CEs, all the MEs associated with the VPLS=20 > > service in the=20 > > >> customer OAM domain (i.e. from CE to CE) can be considered=20 > > to be part=20 > > >> of a VPLS MEG, where the n-point MEG consists of a maximum of=20 > > >> n(n-1)/2 MEs. > > >> ---snip--- > > >> > > > > > > Accept. We will add a sentence or two to indicate that a=20 > > MEP on a PE=20 > > > will receive messages from (n-1) other MEPs (on the same or=20 > > other PEs=20 > > > for the same ME group). > >=20 > > OK. > >=20 > >=20 > > >> Section 4.1.1 (VPLS as Bridged LAN Service) thru 4.1.3=20 > > (VPLS as (V)=20 > > >> LAN > > >> Emulation): > > >> I'm not sure I'm comfortable with these sections. > > >> Specifically, I think what you're describing in Section=20 > > 4.1.1 is VPLS=20 > > >> operates as a peer-layer to the native (Ethernet)=20 > > service-layer. In=20 > > >> Section 4.1.2, I think you are attempting to describe VPLS as a=20 > > >> peer-layer as well as a client-layer to an underlying MPLS or IP=20 > > >> substrate. Finally, I think in Section 4.1.3, you're=20 > > finally up to=20 > > >> VPLS as a service-layer in its own right. Is that correct? > > > > > > No, that is not correct. The intention of this section is=20 > > to describe=20 > > > different interpretation of VPLS as reflected in some of=20 > the drafts=20 > > > and L2VPN framework document because it is important to=20 > > first clarify=20 > > > what VPLS refers to, before identifying what OAM tools=20 > > needed for it. > > > Section > > > 4.1.1 is the most common definition for VPLS (e.g., as an=20 > > end-to-end=20 > > > multipoint Ethernet service over different types of=20 > > network). However,=20 > > > section 4.1.2 and section 4.1.3 talks about different=20 > > definitions of=20 > > > VPLS - e.g., as a network where it support multiple of service=20 > > > instances and as a LAN emulation part which only contains=20 > > full mesh of=20 > > > PWs along with its forwarders and talks about the fact=20 > that OAM for=20 > > > those are handled differently. So, the intention of this=20 > > section is to=20 > > > clarify what we mean by VPLS (which is section 4.1.1) and=20 > > > correspondingly what OAM tools are needed for it. > >=20 > > Thanks for providing some context around these sections. A=20 > > few things might help to be clarified: > > 1) In 4.1.2, you state that this is out-of-scope for this=20 > > document; however, it would be useful to state that Sections=20 > > 4.1.1 and 4.1.3 are what is being addressed by later sections=20 > > of this OAM document. >=20 > O.K. We'll do. Propsosed Text: Add the following sentence at the end of section 4.1.1 and 4.1.3: "The framework & requirements for this OAM mechanism will be covered in this draft"=20 >=20 > > 2) In Section 4.1.1, it's stated that: > > ---snip--- > > To check the end-to-end service integrity, service=20 > > level OAM mechanisms > > are needed. > > ---snip--- > > I'm not comfortable with the words "service level" as they=20 > > stand above. Is it referring to the VPLS service level,=20 > > (e.g.: VPLS-LDP/ VPLS-BGP signaling, VPLS Forwarders as=20 > > defined in L2VPN framework, > > etc.) or to the IEEE 802.1 service level or both? > >=20 >=20 > It basically refers to multipoint Ethernet service which is=20 > provided via > network elements - PE and bridging devices (for providing > bridging/swtiching) functions and P devices (for providing tunneling > function). And it is from AC to AC.=20 >=20 > > Is there another L2VPN (or PWE3) document to which you can=20 > > provide a pointer as to a definition of 'service layer'? =20 > > (See the next comment for more context about a suggestion I=20 > > have to hopefully address this comment). > >=20 >=20 > Basically service layer is the layer at which the multipoint Ethernet > service is offered.=20 >=20 > >=20 > >=20 > > >> If so, then I think we need to be careful in Sections 4.1.1 and > > >> 4.1.2 when referring the native Ethernet service-layer=20 > > (particularly=20 > > >> in the context of the access-layer networks), that this is=20 > > >> out-of-scope for this work product (and the IETF). > > > > > > That is not the case. Please refer to section 11 of=20 > vpls-ldp draft. > >=20 > > Section 11 of VPLS-LDP states the following: > > ---snip--- > > The details regarding bridge operation for MTU-s and PE-rs (e.g., > > encapsulation format for Q-in-Q messages, customer's Ethernet > > control protocol handling, etc.) are outside of the scope of this > > document and they are covered in [802.1ad]. However,=20 > the relevant > > part is the interaction between the bridge module and the MPLS/IP > > PWs in the PE-rs, which behaves just as in a regular VPLS. > > ---snip--- > > The above section from VPLS-LDP states that bridging=20 > > operation for the MTU-s and PE-rs are outside its scope, but=20 > > that the interaction between the bridge module and MPLS/IP=20 > > PWs in the PE-rs are important. I believe this sentence=20 > > applies to Section 4.1.1 and, subsequently, the OAM=20 > > requirements section, specifically as it relates to protocols=20 > > we may create or augment to address OAM of VPLS/ VPWS=20 > > services. Perhaps it's useful to 'borrow' this paragraph=20 > > from VPLS-LDP in order to clarify that the 'service-layer' to=20 > > which you refer in the "VPLS as a Bridged LAN service"=20 > > section relates directly to this interaction. > >=20 >=20 > Yes, the brdiging operation are outside of the scope since they are > already specified in IEEE 802.1ad spec; however, the fact that the > aggregation of CE devices can be provided by MTU-s switches still > remains the same. Basically, the mode of operation is H-VPLS with > Ethernet access and Ethernet access is part of provider (not the > customer) and as such when providers want end to end=20 > coverage, they want > from AC to AC (e.g., among CE devices) and not just part of a network. > The good thing is that in the draft we have covered both end to end > service as well as the portion that just spans MPLS/IP network and we > have covered the interaction between the two which is very important - > e.g., if a fault happens in MPLS core, then how it is propagated to > MTU-s bridges. >=20 Proposed Text: Will add the following paragraph=20 "The details regarding bridge operation for MTU-s and PE-rs (e.g., Ethernet encapsulation format, customer's Ethernet control protocol handling, etc.) are outside of the scope of this document as they are covered in IEEE standards unless there is an=20 Interaction between these protocols and MPLS/IP protocols." > > Because the introduction to Section 6 (VPLS Service OAM=20 > > Requirements) has a reference back to Section 4.1.1: > > ---snip--- > > These requirements are applicable to VPLS as a Bridged=20 > > LAN service, > > as described in Section 4.1.1. Further, the performance=20 > > metrics used > > in requirements are based on [MEF10] and [RFC2544]. > > ---snip--- > > ... I think it's important that you clarify the service-layer. >=20 > Sounds good. We will further clarify and describe service-layer. >=20 Will add the following text to 4.1.1 for further clarification: "Service layer corresponds to the layer of the network, network elements,=20 that are service aware - e.g., if the service provided to an end-user is a multipoint Ethernet service, then the service layer constitues the network=20 elements that are aware of the end-user Ethernet frames. "=20 > >=20 > > In addition, in Section 6, it would useful to state that=20 > > although the Framework may provide a comprehensive OAM=20 > > solution set, the requirements for a L2VPN-defined OAM=20 > > _protocol suite_ will be a subset of the Framework (along the=20 > > lines of what VPLS-LDP says) related to those aspects of=20 > > L2VPN protocols, signaling, etc. =20 > > previously defined, owned & maintained by the L2VPN WG. > > >=20 > Considering that MTU-s and PE-rs have bridging modules in=20 > them, I don't > think it would make any difference with respect to OAM framework and > requirements specifications as whether they are directly=20 > connected with > each other or they are connected via another set of bridges (e.g., via > Ethernet network). In other words, we still need to perform fault > management for MTU-s and PE-rs when the network is H-VPLS=20 > with Ethernet > access and when you have the capability to do that, then you can do it > for the intermediate nodes connecting the MTU-s to PE-rs.=20 >=20 Will add a paragraph the following paragraph to this section: "The details regarding bridge OAM operation for MTU-s and PE-rs (e.g., OAM protocols for Ethernet) are outside of the scope of this document as they are covered in IEEE standards unless there is an=20 Interaction between these protocols and MPLS/IP protocols." > >=20 > >=20 > > >> In addition, in Section 4.1.2, there's a vague statement=20 > > with respect=20 > > >> to OAM mechanisms at the "network level". The way the current=20 > > >> sentence is phrased, I believe you are saying that=20 > > network-layer OAM=20 > > >> mechanisms are required; however, it's not in our=20 > charter to solve=20 > > >> MPLS-layer OAM. (Note, to be fair, you do say in Section=20 > > 4.2.1 that=20 > > >> OAM at the transport-layer is out-of-scope of this doc,=20 > > but perhaps=20 > > >> copying/moving that statement up to here would be useful)? > > >> ---snip--- > > >> To check the network > > >> integrity regardless of the network topology, network level OAM=20 > > >> mechanisms are needed for the VPLS networks. > > >> ---snip--- > > >> Related to the last comment, the words "network=20 > level" is IMO=20 > > >> vague. > > >> Perhaps it would be better to state that it refers to=20 > > network-layer=20 > > >> protocols such as MPLS, GRE/IP or L2TPv3? > > >> > > > > > > O.K., we will add a sentence or two to clarify it further. > > > > > > > > >> Section 4.2.2: > > >> It doesn't look like the lines in the diagram in Figure 4,=20 > > for A, B &=20 > > >> C are properly aligned. You should fix them. > > >> > > > > > > Great! We will do that. > > > > > >> Section 4.2.3: > > >> Again, it doesn't look like the diagram in Figure 5 is properly=20 > > >> aligned with the scenarios depicted in A, B & C. > > >> > > > > > > It looks pretty align to us, but we will search for=20 > > mis-alignment. If=20 > > > you can point out expilictly what is misaligned, it would help. > > > > > >> Section 4.2.3: > > >> In general, this section says that it is 'expected' that=20 > MEPs and=20 > > >> MIPs will be implemented into various components of the VPLS=20 > > >> architecture, (VPLS forwarder/briding modules). Are you=20 > > discussing=20 > > >> the OAM framework here, or do these 'expected' > > >> details surrounding an eventual implementation which would=20 > > mean these=20 > > >> would translate into MUSTs or SHOULDs in the reqmt's=20 > > sections? (I'm=20 > > >> trying to seek clarity of what you're intent is with these=20 > > >> statements, because I don't see anything related to MEPs=20 > > and MIPs in=20 > > >> the reqmt's section). > > >> > > > > > > Our intention here is to satisfy your previous request as=20 > > to show the=20 > > > MEPs and MIPs relate to L2VPN framework. > >=20 > > OK. > >=20 > >=20 > > >> Section 4.2.3: > > >> (D) depicts both MEPs and MIPs, however this sentence only=20 > > discusses=20 > > >> expectations around MEPs ... what about the MIPs in Scenario (D)? > > >> ---snip--- > > >> (D) represents the MEPs and MIPs > > >> visible within the service provider domain. These MEPs are=20 > > expected=20 > > >> to be implemented in the bridge module/VPLS forwarder of a=20 > > PE device,=20 > > >> as per the [L2VPN-FRWK]. > > >> ---snip--- > > >> > > > > > > Agreed. We will clarify it by adding MIPs to the above sentence: =20 > > > "These > > > MEPs and MIPs are expected ..." > >=20 > > OK. > >=20 > >=20 > > >> Section 4.2.3: > > >> In which components of the VPLS architecture do you expect=20 > > the MEPs=20 > > >> and MIPs in (E) to be implemented? > > >> > > > > > > Agreed. We will clarify this by indicating that the MIPs=20 > > for (E) would=20 > > > exist when you have an Ethernet access network (e.g.,=20 > section 11 of=20 > > > vpld-ldp draft). > >=20 > > OK. > >=20 > >=20 > > >> Section 4.2.4: > > >> What about VPLS-BGP? What identifiers are used for it, since it=20 > > >> doesn't use PW-id's? > > >> > > > > > > PW-ids are used in VPLS-BGP but instead they are signaled=20 > > via BGP and=20 > > > we don't care about what signaling mechanism is used. > >=20 > > VPLS-LDP uses PWid's. VPLS-BGP uses a demultiplexor label=20 > > defined as (Label Block + VE ID - VE Block Offset). > > Perhaps it would useful to clarify that you are referring to=20 > > the demultiplexor label, in order to be less specific as to=20 > > one protocol or the other? Alternatively, clarify that with=20 > > VPLS-BGP it would be what's stated above. > >=20 >=20 > It is really the same thing. The VPLS-BGP draft talks about PW and its > associated signaling (setup and tear down). PW by definition is the > demultiplexor label within the PSN tunnel. So both are the=20 > same and the > use of PW id makes the reference consistent irregardless of signaling > type (BGP v.s. LDP).=20 >=20 > >=20 > > >> Section 4.2.4: > > >> ---snip--- > > >> Both PW-ids and VLAN tags for a given VPLS instance are=20 > associated=20 > > >> with a Service Identifier (e.g., VPN identifier). > > >> ---snip--- > > >> Which identifier do you have in mind, i.e.: VPLS-ID in=20 > > >> l2vpn-signaling? > > >> > > > > > > By PW-id, it is meant the associated MPLS label. > >=20 > > OK. > >=20 > >=20 > > >> Section 5: > > >> Diagrams aren't aligned Figure 6, VPWS Reference Model. > > >> > > > > > > We must complement you for your keen eyes :-) We will fix it. > > > > > > > > >> Section 5.2: > > >> What are you trying to say here? > > >> ---snip--- > > >> In common scenarios, it could or simply a point-to-point=20 > > interface of=20 > > >> certain type. The core network connecting PEs can be IP,=20 > > MPLS, etc. > > >> ---snip--- > > >> > > > > > > The statement ought to be: "In common scenarios, it could=20 > > simply be a > > > point-to-point ... Such as Ethernet PHY" and we will change it. > > > > > >> Section 5.2: > > >> To which network types are you referring? Can you somehow > > >> reference back to the heterogenous & homogeneous terminology > > >> introduced in the aforementioned section? > > >> ---snip--- > > >> Therefore, it is important that the OAM mechanisms can be > > >> applied to all these network types. > > >> ---snip--- > > >> > > > > > > We will change the sentence to "Therefore, it is=20 > important that OAM > > > mechanisms can be applied to different network types some of which > > > mentioned above" > > > > > > > > >> Section 5.2.1: > > >> Diagrams in Figure 7 are not aligned properly, and I believe > > >> you're missing a > describing the right-most end-point in the =20 > > >> diagram. > > >> > > > > > > Right, We will fix it. > > > > > > > > >> Section 5.2.2: > > >> Diagrams in Figure 8a & 8b are not aligned properly, and I > > >> believe you're missing a > describing the right-most > > >> end-point in the diagram. > > >> > > > > > > That's fine, we'll fix it. > > > > > >> Section 5.2.2: > > >> ---snip--- > > >> "The service provider is responsible to monitor the PW ME" > > >> "... the monitoring requirements across the AC ME are minimal." > > >> ---snip--- > > >> What is the "PW ME" and "AC ME"? The term "ME" hasn't been > > >> defined as it related specifically to PW's or AC's. > > >> Furthermore, does ME refer to the NSP, or some other > > >> function/layer of VPWS? > > >> > > > > > > Section 1.1 has a clear definition of ME which one can=20 > apply to any > > > types of entity such as service, PW, AC, etc. > >=20 > > OK. > >=20 > >=20 > > >> Section 5.2.2: > > >> ---snip--- > > >> The > > >> distinction between Figure 8b (C) and (D) is that (C) MEs > > >> have MEPs at CE and PEs and have no MIPs while (D) MEs have > > >> MEPs at CEs and PEs and likely MIPs in between, thereby > > >> having a visibility to Operator network. > > >> ---snip--- > > >> Can you clarify this part of the sentence: "(C) MEs have > > >> MEPs at CE and PEs and have no MIPs" ... specifically, it's > > >> not clear at all > > >> (e.g.: to which devices or components of VPWS) where MEPs and > > >> MIPs are applicable. > > >> Can you also clarify the second half of that sentence > > >> "(D) MEs have MEPs at CEs and PEs and likely MIPs in between, > > >> thereby having a visibility to Operator network." ... again, > > >> it's not clear where (e.g.: > > >> to which devices or components of VPWS) MEPs are MIPs are > > >> applicable. I think it's just the way you're phrasing it, so > > >> perhaps re-phrasing in a better way would be good. > > >> > > > > > > We belive the phrasing is causing some confusion to you=20 > and we will > > > further clarify it as: "The distinction between Figure 8(b)-C, and > > > 8(b)-D is that in (C), MEs have MEPs at CEs and at Pes,=20 > and have no > > > MIPs. While in (D) MEs have MEPs at CEs and at PEs and=20 > > furthermore, =20 > > > MIPs > > > may be present in between the MEPs; thereby providing=20 > > visibility of =20 > > > the > > > network to the operator." > >=20 > > OK. > >=20 > > [---snipped for brevity---] > >=20 > > >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: > > >>=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > [---snip---] > >=20 > > >> 5.2: > > >> ---snip--- > > >> As an example, the access network between CE and PE on one > > >> side can be Ethernet bridged network, ATM network, etc. > > >> ---snip--- > > >> s/be Ethernet bridged network/be an Ethernet bridged/ > > > > > > Reject. It is intended to say "bridged network" as defined in IEEE > > > standards > >=20 > > I was just asking to insert an 'an' into your sentence. I'm not =20 > > clear on why you would reject that change? > >=20 > >=20 > > [---snipped to end---] > >=20 > > Thanks, > >=20 > > -shane > >=20 >=20 From l2vpn-bounces@ietf.org Sat Feb 24 18:50:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL6bn-0006Pv-I8; Sat, 24 Feb 2007 18:47:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL6bm-0006MP-QA for l2vpn@ietf.org; Sat, 24 Feb 2007 18:47:18 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL6bl-0001Zs-1V for l2vpn@ietf.org; Sat, 24 Feb 2007 18:47:18 -0500 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 87E5164505; Sat, 24 Feb 2007 16:47:09 -0700 (MST) In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02CF677E@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02CF677E@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Shane Amante Date: Sat, 24 Feb 2007 16:47:11 -0700 To: Ali Sajassi (sajassi) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Cc: l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 Ali, On Feb 23, 2007, at 6:38 PM, Ali Sajassi (sajassi) wrote: > Shane, > > I have basically added the text as you have requested/suggested > (please > refer to the text inline). Let me know please if there are still some > I's that I need to dot or T's that I need to cross before the WG last > call :-) So, if you are O.K. with these changes, we can either add > them > after we go through the last call or do it before hand. My > preference is > after the call since I can do all the editing in one shot and avoid > unnecessary overhead of going through multiple edit/release cycles. Once we agree to the below changes, let's please make them before WG Last Call. This will be courteous to all WG members by allowing them to read the document in its entirety, instead of having to scan the list & archives to see the doc in its final state -- particularly because they are comments related to the substance of the document, not spelling or grammatical typos. In addition, there are a significant number of 'nits' found (4 errors, 15 warnings) in the doc that need to get cleaned up before it goes to the IESG: http://tools.ietf.org/wg/l2vpn/draft-ietf-l2vpn-oam-req-frmk/draft- ietf-l2vpn-oam-req-frmk-07.nits.txt Can you, or one of the other co-authors/contributors, please address these as well in the final version? > I would appreciate your prompt response as this draft has been gating > issue for any work on OAM solution draft. I think we're getting close to finishing this. Please see below. I'm OK with most of your suggested changes, however there's still three outstanding items. > Regards, > Ali > >> -----Original Message----- >> From: Ali Sajassi (sajassi) >> Sent: Wednesday, February 21, 2007 1:09 AM >> To: Shane Amante >> Cc: l2vpn@ietf.org >> Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 >> [FrameworkReview] >> >> >> Hi Shane, >> >> Please refer to my comments inline. As you can see I think we >> are very close in wrapping this up. >> >> Regards, >> Ali >> >>> -----Original Message----- >>> From: Shane Amante [mailto:shane@castlepoint.net] >>> Sent: Sunday, July 23, 2006 5:20 PM >>> To: Ali Sajassi (sajassi) >>> Cc: l2vpn@ietf.org >>> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 >>> [FrameworkReview] >>> >>> Hi Ali, >>> >>> Please see below. >>> >>> On Jun 23, 2006, at 12:09 AM, Ali Sajassi (sajassi) wrote: >>>> Shane, >>>> >>>> Thank you for your detailed comments. Please refer to our >>> replies in >>>> line. We will incorporate the ones agreed upon in the next >>> rev. of the >>>> document. >>>> >>>> Regards, >>>> Ali & Dinesh >>>> >>>>> -----Original Message----- >>>>> From: Shane Amante [mailto:shane@castlepoint.net] >>>>> Sent: Sunday, April 09, 2006 9:41 PM >>>>> To: l2vpn@ietf.org >>>>> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 >>>>> [FrameworkReview] >>>>> >>>>> Ali, Dinesh, et. al, >>>>> >>>>> As stated in an earlier e-mail, below are the comments >> relating to >>>>> the Framework section(s). >>>>> >>>>> >> =================================================================== >>>>> SUBSTANTIATIVE: >>>>> >> =================================================================== >>>>> >>>>> Section 1: >>>>> I understand the intent to have a comprehensive set of OAM >>> reqmt's, >>>>> but I'm not sure why the L2VPN WG specifically needs to >>> take on the >>>>> breadth of what this statement suggests, specifically "a >> reference >>>>> model for OAM layering and furthermore emphasizes the >>> importance of >>>>> proper independent layering in design and development of OAM >>>>> functionality across ..." >>>>> Wouldn't proper OAM layering be a topic more suitable >> for the Ops >>>>> Area? >>>>> ---snip--- >>>>> This document provides a description and a reference >> model for OAM >>>>> layering and furthermore emphasizes the importance of proper >>>>> independent layering in design and development of OAM >>> functionality >>>>> across L2VPN services, Pseudo Wires (PWs) and Public >>> Switched Network >>>>> (PSN) tunnels. >>>>> ---snip--- >>>>> >>>> >>>> In VPLS because the native Ethernet service is >> transported over PWs >>>> and PSN tunnels, it is important to identify the >> interaction among >>>> these different layers and identify how the failure in PW or PSN >>>> transport layers can impact VPLS service layer and that is >>> why we have >>>> established this OAM layering model. Also, in the previous >>>> discussions, we were asked to identify the impact of PW and >>> PSN layer >>>> failure on VPLS service layer. If in addition to L2VPN WG, >>> you would >>>> like to present this layering to Ops area, then please make such >>>> recommendation. >>> >>> Perhaps some word-smithing might alleviate this concern. How about >>> this: >>> ---snip--- >>> This document provides a description and reference model >> for OAM as it >>> relates to L2VPN services, which are comprised of Pseudo Wires >>> (PWs) and Public Switched Network (PSN) tunnels. >>> ---snip--- >>> I'm not sure you need to mention OAM layering or its importance in >>> this paragraph, because that is captured by the phrase "description >>> and reference model for OAM" in the sentence above. It is also >>> captured in much detail throughout the framework portion of the >>> document. >>> >>> >> >> That's fine. I will change it to: >> "This document provides a description and reference model for >> OAM as it relates to L2VPN services and their associated >> Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels." >> > > Proposed text: Change the text to: > > "This document provides a description and reference model for > OAM as it relates to L2VPN services and their associated > Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels." OK. >>>>> Section 3.3 (MEPs and MIPs) >>>>> It would be *extremely* useful to address this comment, as >>> it relates >>>>> to "Scalability" of VPLS OAM, in Sections 6 (& 7). >>>>> Specifically, in a mp2p environment like VPLS, it would be >>> useful to >>>>> assert some guidelines as it relates to the number of ME's per >>>>> service instance per PE, (particularly for the "sink PE" >> that is a >>>>> receiver of n(n-1)/2 ME messages). >>>>> ---snip--- >>>>> A ME is a point-to-point association between a pair of MEPs and >>>>> represents a monitored entity. For example, in a VPLS >>> service which >>>>> involves n CEs, all the MEs associated with the VPLS >>> service in the >>>>> customer OAM domain (i.e. from CE to CE) can be considered >>> to be part >>>>> of a VPLS MEG, where the n-point MEG consists of a maximum of >>>>> n(n-1)/2 MEs. >>>>> ---snip--- >>>>> >>>> >>>> Accept. We will add a sentence or two to indicate that a >>> MEP on a PE >>>> will receive messages from (n-1) other MEPs (on the same or >>> other PEs >>>> for the same ME group). >>> >>> OK. >>> >>> >>>>> Section 4.1.1 (VPLS as Bridged LAN Service) thru 4.1.3 >>> (VPLS as (V) >>>>> LAN >>>>> Emulation): >>>>> I'm not sure I'm comfortable with these sections. >>>>> Specifically, I think what you're describing in Section >>> 4.1.1 is VPLS >>>>> operates as a peer-layer to the native (Ethernet) >>> service-layer. In >>>>> Section 4.1.2, I think you are attempting to describe VPLS as a >>>>> peer-layer as well as a client-layer to an underlying MPLS or IP >>>>> substrate. Finally, I think in Section 4.1.3, you're >>> finally up to >>>>> VPLS as a service-layer in its own right. Is that correct? >>>> >>>> No, that is not correct. The intention of this section is >>> to describe >>>> different interpretation of VPLS as reflected in some of >> the drafts >>>> and L2VPN framework document because it is important to >>> first clarify >>>> what VPLS refers to, before identifying what OAM tools >>> needed for it. >>>> Section >>>> 4.1.1 is the most common definition for VPLS (e.g., as an >>> end-to-end >>>> multipoint Ethernet service over different types of >>> network). However, >>>> section 4.1.2 and section 4.1.3 talks about different >>> definitions of >>>> VPLS - e.g., as a network where it support multiple of service >>>> instances and as a LAN emulation part which only contains >>> full mesh of >>>> PWs along with its forwarders and talks about the fact >> that OAM for >>>> those are handled differently. So, the intention of this >>> section is to >>>> clarify what we mean by VPLS (which is section 4.1.1) and >>>> correspondingly what OAM tools are needed for it. >>> >>> Thanks for providing some context around these sections. A >>> few things might help to be clarified: >>> 1) In 4.1.2, you state that this is out-of-scope for this >>> document; however, it would be useful to state that Sections >>> 4.1.1 and 4.1.3 are what is being addressed by later sections >>> of this OAM document. >> >> O.K. We'll do. > > Propsosed Text: Add the following sentence at the end of section 4.1.1 > and 4.1.3: > > "The framework & requirements for this OAM mechanism will be > covered in > this draft" OK. >>> 2) In Section 4.1.1, it's stated that: >>> ---snip--- >>> To check the end-to-end service integrity, service >>> level OAM mechanisms >>> are needed. >>> ---snip--- >>> I'm not comfortable with the words "service level" as they >>> stand above. Is it referring to the VPLS service level, >>> (e.g.: VPLS-LDP/ VPLS-BGP signaling, VPLS Forwarders as >>> defined in L2VPN framework, >>> etc.) or to the IEEE 802.1 service level or both? >>> >> >> It basically refers to multipoint Ethernet service which is >> provided via >> network elements - PE and bridging devices (for providing >> bridging/swtiching) functions and P devices (for providing tunneling >> function). And it is from AC to AC. >> >>> Is there another L2VPN (or PWE3) document to which you can >>> provide a pointer as to a definition of 'service layer'? >>> (See the next comment for more context about a suggestion I >>> have to hopefully address this comment). >>> >> >> Basically service layer is the layer at which the multipoint Ethernet >> service is offered. >> >>> >>> >>>>> If so, then I think we need to be careful in Sections 4.1.1 and >>>>> 4.1.2 when referring the native Ethernet service-layer >>> (particularly >>>>> in the context of the access-layer networks), that this is >>>>> out-of-scope for this work product (and the IETF). >>>> >>>> That is not the case. Please refer to section 11 of >> vpls-ldp draft. >>> >>> Section 11 of VPLS-LDP states the following: >>> ---snip--- >>> The details regarding bridge operation for MTU-s and PE-rs (e.g., >>> encapsulation format for Q-in-Q messages, customer's Ethernet >>> control protocol handling, etc.) are outside of the scope of this >>> document and they are covered in [802.1ad]. However, >> the relevant >>> part is the interaction between the bridge module and the MPLS/IP >>> PWs in the PE-rs, which behaves just as in a regular VPLS. >>> ---snip--- >>> The above section from VPLS-LDP states that bridging >>> operation for the MTU-s and PE-rs are outside its scope, but >>> that the interaction between the bridge module and MPLS/IP >>> PWs in the PE-rs are important. I believe this sentence >>> applies to Section 4.1.1 and, subsequently, the OAM >>> requirements section, specifically as it relates to protocols >>> we may create or augment to address OAM of VPLS/ VPWS >>> services. Perhaps it's useful to 'borrow' this paragraph >>> from VPLS-LDP in order to clarify that the 'service-layer' to >>> which you refer in the "VPLS as a Bridged LAN service" >>> section relates directly to this interaction. >>> >> >> Yes, the brdiging operation are outside of the scope since they are >> already specified in IEEE 802.1ad spec; however, the fact that the >> aggregation of CE devices can be provided by MTU-s switches still >> remains the same. Basically, the mode of operation is H-VPLS with >> Ethernet access and Ethernet access is part of provider (not the >> customer) and as such when providers want end to end >> coverage, they want >> from AC to AC (e.g., among CE devices) and not just part of a >> network. >> The good thing is that in the draft we have covered both end to end >> service as well as the portion that just spans MPLS/IP network and we >> have covered the interaction between the two which is very >> important - >> e.g., if a fault happens in MPLS core, then how it is propagated to >> MTU-s bridges. >> > > Proposed Text: Will add the following paragraph > > "The details regarding bridge operation for MTU-s and PE-rs (e.g., > Ethernet encapsulation format, customer's Ethernet > control protocol handling, etc.) are outside of the scope of this > document as they are covered in IEEE standards unless there is an > Interaction between these protocols and MPLS/IP protocols." May I suggest that you re-phrase "MPLS/IP" to be "VPLS or VPWS"? >>> Because the introduction to Section 6 (VPLS Service OAM >>> Requirements) has a reference back to Section 4.1.1: >>> ---snip--- >>> These requirements are applicable to VPLS as a Bridged >>> LAN service, >>> as described in Section 4.1.1. Further, the performance >>> metrics used >>> in requirements are based on [MEF10] and [RFC2544]. >>> ---snip--- >>> ... I think it's important that you clarify the service-layer. >> >> Sounds good. We will further clarify and describe service-layer. >> > > Will add the following text to 4.1.1 for further clarification: > > "Service layer corresponds to the layer of the network, network > elements, > that are service aware - e.g., if the service provided to an end- > user is > > a multipoint Ethernet service, then the service layer constitues the > network > elements that are aware of the end-user Ethernet frames. " These seems like a very broad definition of "service-layer". Can you instead re-phrase your definition for 'service-layer' in terms of RFC 4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)? This would provide cohesiveness with the framework, requirements, solutions (VPLS-LDP/VPLS-BGP) and, ultimately, through OAM reqmt's of VPLS & VPWS. >>> In addition, in Section 6, it would useful to state that >>> although the Framework may provide a comprehensive OAM >>> solution set, the requirements for a L2VPN-defined OAM >>> _protocol suite_ will be a subset of the Framework (along the >>> lines of what VPLS-LDP says) related to those aspects of >>> L2VPN protocols, signaling, etc. >>> previously defined, owned & maintained by the L2VPN WG. >>> >> >> Considering that MTU-s and PE-rs have bridging modules in >> them, I don't >> think it would make any difference with respect to OAM framework and >> requirements specifications as whether they are directly >> connected with >> each other or they are connected via another set of bridges (e.g., >> via >> Ethernet network). In other words, we still need to perform fault >> management for MTU-s and PE-rs when the network is H-VPLS >> with Ethernet >> access and when you have the capability to do that, then you can >> do it >> for the intermediate nodes connecting the MTU-s to PE-rs. >> > > Will add a paragraph the following paragraph to this section: > > "The details regarding bridge OAM operation for MTU-s and PE-rs (e.g., > OAM protocols for Ethernet) are outside of the scope of this > document as they are covered in IEEE standards unless there is an > Interaction between these protocols and MPLS/IP protocols." May I suggest the above be rephrased as follows, and be put as a new paragraph: ---snip--- The details regarding the "bridge module", as defined in the framework of L2PVN [RFC 4664], of the PE-rs as well as the native Ethernet MTU-s are outside of the scope of this document and the solutions defined as a result of this document, as they are covered in IEEE standards. The requirements in this draft apply to the "VPLS Forwarder" and the "Emulated LAN interface", which connects the VPLS Forwarder to the bridge module. ---snip--- [--snip--] It looks like you also need to address the following minor nit, as well: >> =================================================================== >>>>> EDITORIAL: >>>>> >> =================================================================== >>> >>> [---snip---] >>> >>>>> 5.2: >>>>> ---snip--- >>>>> As an example, the access network between CE and PE on one >>>>> side can be Ethernet bridged network, ATM network, etc. >>>>> ---snip--- >>>>> s/be Ethernet bridged network/be an Ethernet bridged/ >>>> >>>> Reject. It is intended to say "bridged network" as defined in IEEE >>>> standards >>> >>> I was just asking to insert an 'an' into your sentence. I'm not >>> clear on why you would reject that change? >>> >>> >>> [---snipped to end---] >>> >>> Thanks, >>> >>> -shane Thanks, -shane From l2vpn-bounces@ietf.org Mon Feb 26 12:51:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjz2-0004If-RE; Mon, 26 Feb 2007 12:49:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjz1-0004I2-KP for l2vpn@ietf.org; Mon, 26 Feb 2007 12:49:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjz0-0001LH-9A for l2vpn@ietf.org; Mon, 26 Feb 2007 12:49:55 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 09:49:53 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="42667352:sNHT48371454" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1QHnrhi015845; Mon, 26 Feb 2007 09:49:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QHnCEI013709; Mon, 26 Feb 2007 09:49:43 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 09:49:37 -0800 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 Date: Mon, 26 Feb 2007 09:49:35 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02CF69DC@xmb-sjc-21e.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcdYbiPhC3FifcntTSe4pcF05vrgiABWy/gg From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" X-OriginalArrivalTime: 26 Feb 2007 17:49:37.0039 (UTC) FILETIME=[7B5101F0:01C759CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3178; t=1172512193; x=1173376193; c=relaxed/simple; s=sjdkim3002; 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=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-0 5=20[FrameworkReview] |Sender:=20; bh=fr+1S46rLT2GcQcsmI4odagRW13WWzYcNz8Cde1HJ/w=; b=Y/c4V+XqnsXya5Q9DTgLNAAOUn5Kvoo0d+FV0+fZH0qqXnJzgA35bYn1H1nVcud2L6F88C2B buWhBPypta8u+hG135xvHR+zBtBPrzaYq93HDdEJ2bH9ztLcZHqGDaTI; Authentication-Results: sj-dkim-3; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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, Please refer to my reply below with respect to your last three comments/suggestion. I have removed the remaining texts/comments for better clarity. =20 >=20 > I think we're getting close to finishing this. Please see below. =20 > I'm OK with most of your suggested changes, however there's=20 > still three outstanding items. >=20 >=20 > > Proposed Text: Will add the following paragraph > > > > "The details regarding bridge operation for MTU-s and PE-rs (e.g.,=20 > > Ethernet encapsulation format, customer's Ethernet control protocol=20 > > handling, etc.) are outside of the scope of this document=20 > as they are=20 > > covered in IEEE standards unless there is an Interaction=20 > between these=20 > > protocols and MPLS/IP protocols." >=20 > May I suggest that you re-phrase "MPLS/IP" to be "VPLS or VPWS"? >=20 O.K. > > > > Will add the following text to 4.1.1 for further clarification: > > > > "Service layer corresponds to the layer of the network, network=20 > > elements, that are service aware - e.g., if the service=20 > provided to an=20 > > end- user is > > > > a multipoint Ethernet service, then the service layer=20 > constitues the=20 > > network elements that are aware of the end-user Ethernet frames. " >=20 > These seems like a very broad definition of "service-layer". =20 > Can you instead re-phrase your definition for 'service-layer'=20 > in terms of RFC > 4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)? =20 > This would provide cohesiveness with the framework,=20 > requirements, solutions (VPLS-LDP/VPLS-BGP) and, ultimately,=20 > through OAM reqmt's of VPLS & VPWS. >=20 >=20 O.K. I will modify it based on L2VPN Requriement RFC and L2VPN Framwork RFC. >=20 >=20 > > > "The details regarding bridge OAM operation for MTU-s and=20 > PE-rs (e.g.,=20 > > OAM protocols for Ethernet) are outside of the scope of=20 > this document=20 > > as they are covered in IEEE standards unless there is an=20 > Interaction=20 > > between these protocols and MPLS/IP protocols." >=20 > May I suggest the above be rephrased as follows, and be put as a new > paragraph: > ---snip--- > The details regarding the "bridge module", as defined in the=20 > framework of L2PVN [RFC 4664], of the PE-rs as well as the=20 > native Ethernet MTU-s are outside of the scope of this=20 > document and the solutions defined as a result of this=20 > document, as they are covered in IEEE standards. The=20 > requirements in this draft apply to the "VPLS Forwarder" and=20 > the "Emulated LAN interface", which connects the VPLS=20 > Forwarder to the bridge module. > ---snip--- >=20 That is NOT correct !! If you refer to both RFC 4465 and RFC 4464, an end-to-end VPLS is defined to include bridge module, forwarder, and the set of PWs. I know better, I helped the authors with these definitions at the time of the writing of these RFCs. For example RFC4465 says: " End-to-end VPLS consists of a bridge module and a LAN emulation module ([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS service it must include bridge module. -Ali =20 From l2vpn-bounces@ietf.org Mon Feb 26 23:31:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtz2-0004hc-3e; Mon, 26 Feb 2007 23:30:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtz1-0004hT-Ck for l2vpn@ietf.org; Mon, 26 Feb 2007 23:30:35 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLtz0-0002lb-1Z for l2vpn@ietf.org; Mon, 26 Feb 2007 23:30:35 -0500 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 6E9CD647B1; Mon, 26 Feb 2007 21:30:27 -0700 (MST) In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02CF69DC@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02CF69DC@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78DA378D-8CF1-4A46-A128-B8C0B9553C96@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Mon, 26 Feb 2007 21:30:30 -0700 To: Ali Sajassi (sajassi) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 Ali, On Feb 26, 2007, at 10:49 AM, Ali Sajassi (sajassi) wrote: > Shane, > > Please refer to my reply below with respect to your last three > comments/suggestion. I have removed the remaining texts/comments for > better clarity. > > >> >> I think we're getting close to finishing this. Please see below. >> I'm OK with most of your suggested changes, however there's >> still three outstanding items. >> >> >>> Proposed Text: Will add the following paragraph >>> >>> "The details regarding bridge operation for MTU-s and PE-rs (e.g., >>> Ethernet encapsulation format, customer's Ethernet control protocol >>> handling, etc.) are outside of the scope of this document >> as they are >>> covered in IEEE standards unless there is an Interaction >> between these >>> protocols and MPLS/IP protocols." >> >> May I suggest that you re-phrase "MPLS/IP" to be "VPLS or VPWS"? >> > > O.K. > >>> >>> Will add the following text to 4.1.1 for further clarification: >>> >>> "Service layer corresponds to the layer of the network, network >>> elements, that are service aware - e.g., if the service >> provided to an >>> end- user is >>> >>> a multipoint Ethernet service, then the service layer >> constitues the >>> network elements that are aware of the end-user Ethernet frames. " >> >> These seems like a very broad definition of "service-layer". >> Can you instead re-phrase your definition for 'service-layer' >> in terms of RFC >> 4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)? >> This would provide cohesiveness with the framework, >> requirements, solutions (VPLS-LDP/VPLS-BGP) and, ultimately, >> through OAM reqmt's of VPLS & VPWS. >> >> > > O.K. I will modify it based on L2VPN Requriement RFC and L2VPN > Framwork > RFC. Can you please suggest text that you will use? >>> "The details regarding bridge OAM operation for MTU-s and >> PE-rs (e.g., >>> OAM protocols for Ethernet) are outside of the scope of >> this document >>> as they are covered in IEEE standards unless there is an >> Interaction >>> between these protocols and MPLS/IP protocols." >> >> May I suggest the above be rephrased as follows, and be put as a new >> paragraph: >> ---snip--- >> The details regarding the "bridge module", as defined in the >> framework of L2PVN [RFC 4664], of the PE-rs as well as the >> native Ethernet MTU-s are outside of the scope of this >> document and the solutions defined as a result of this >> document, as they are covered in IEEE standards. The >> requirements in this draft apply to the "VPLS Forwarder" and >> the "Emulated LAN interface", which connects the VPLS >> Forwarder to the bridge module. >> ---snip--- >> > > That is NOT correct !! If you refer to both RFC 4465 and RFC 4464, an > end-to-end VPLS is defined to include bridge module, forwarder, and > the > set of PWs. I know better, I helped the authors with these definitions > at the time of the writing of these RFCs. For example RFC4465 says: " > End-to-end VPLS consists of a bridge module and a LAN emulation module > ([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS > service it must include bridge module. I don't understand. Your explanation above is confusing for two reasons: 1) First, if you look above at the top-most comment in this thread (relative to the Framework section) you agree that the "details regarding bridge operation for MTU-s and PE-rs ... are outside the scope of this document as they are covered in the IEEE standards". Now, you seem to be saying the opposite in the Requirements section. Specifically, that the above statement was irrelevant and now you are implying that you do want/need to duplicate IEEE standards in the requirements for OAM solutions that will be proposed for VPLS/VPWS. Or, perhaps I'm misunderstanding the rationale behind your explanation or intent? 2) Second, and much more germane to the requirements section, is what portion(s) of the requirements section apply to OAM solutions that will go Standards Track and, separately, what requirement(s) apply to OAM solutions that may go Informational, (assuming they are not duplicating or interfering with standards/protocols from other SDO's)? Thanks, -shane From l2vpn-bounces@ietf.org Tue Feb 27 02:19:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLwbO-0002s6-11; Tue, 27 Feb 2007 02:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLwbM-0002nN-JI for l2vpn@ietf.org; Tue, 27 Feb 2007 02:18:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLwbK-0000iE-Tj for l2vpn@ietf.org; Tue, 27 Feb 2007 02:18:20 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 23:18:18 -0800 X-IronPort-AV: i="4.14,223,1170662400"; d="scan'208"; a="42949582:sNHT67120101" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1R7II32019051; Mon, 26 Feb 2007 23:18:18 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1R7I9V0006724; Mon, 26 Feb 2007 23:18:13 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 23:18:10 -0800 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 Date: Mon, 26 Feb 2007 23:15:47 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02D53298@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <78DA378D-8CF1-4A46-A128-B8C0B9553C96@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcdaKA4yaLuqTzh3RqazIToEJKszHwAEvzJw From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" X-OriginalArrivalTime: 27 Feb 2007 07:18:10.0788 (UTC) FILETIME=[6FC3A240:01C75A3F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11656; t=1172560698; x=1173424698; c=relaxed/simple; s=sjdkim3002; 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=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-0 5=20[FrameworkReview] |Sender:=20; bh=k1o8rRVavAT08VqE0tgIim46mVq+tNMr/ANQAGxTDcE=; b=jemvFemjiGGIgdI8l5p6TXu8oU7I+jYBJcF4gr/E2/7a7OR0c4cZPEnPal/ZHIUDGnfm/HgV uR1QD7blQ7s1lnHM4Qki/DRbViy9Cpa3DMgsS9RWohsySOEHZmdahFIM; Authentication-Results: sj-dkim-3; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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,=20 I have sent out an updated copy of the draft earlier this afternoon; however, it seems it got parked because of the attachment. Anyway, I have copied section 4 and 6 at the bottom of this email. Also please refer to my comments inline ... > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Monday, February 26, 2007 8:31 PM > To: Ali Sajassi (sajassi) > Cc: l2vpn@ietf.org > Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > [FrameworkReview] >=20 > Ali, >=20 > On Feb 26, 2007, at 10:49 AM, Ali Sajassi (sajassi) wrote: > > Shane, > > > > Please refer to my reply below with respect to your last three=20 > > comments/suggestion. I have removed the remaining=20 > texts/comments for=20 > > better clarity. > > > > > >> > >> I think we're getting close to finishing this. Please see below. > >> I'm OK with most of your suggested changes, however there's still=20 > >> three outstanding items. > >> > >> > >>> Proposed Text: Will add the following paragraph > >>> > >>> "The details regarding bridge operation for MTU-s and=20 > PE-rs (e.g.,=20 > >>> Ethernet encapsulation format, customer's Ethernet=20 > control protocol=20 > >>> handling, etc.) are outside of the scope of this document > >> as they are > >>> covered in IEEE standards unless there is an Interaction > >> between these > >>> protocols and MPLS/IP protocols." > >> > >> May I suggest that you re-phrase "MPLS/IP" to be "VPLS or VPWS"? > >> > > > > O.K. > > > >>> > >>> Will add the following text to 4.1.1 for further clarification: > >>> > >>> "Service layer corresponds to the layer of the network, network=20 > >>> elements, that are service aware - e.g., if the service > >> provided to an > >>> end- user is > >>> > >>> a multipoint Ethernet service, then the service layer > >> constitues the > >>> network elements that are aware of the end-user Ethernet frames. " > >> > >> These seems like a very broad definition of "service-layer". > >> Can you instead re-phrase your definition for 'service-layer' > >> in terms of RFC > >> 4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)? > >> This would provide cohesiveness with the framework, requirements,=20 > >> solutions (VPLS-LDP/VPLS-BGP) and, ultimately, through OAM=20 > reqmt's of=20 > >> VPLS & VPWS. > >> > >> > > > > O.K. I will modify it based on L2VPN Requriement RFC and L2VPN=20 > > Framwork RFC. >=20 > Can you please suggest text that you will use? >=20 I have pasted a copy of the proposed text at the end of this email. >=20 >=20 > >>> "The details regarding bridge OAM operation for MTU-s and > >> PE-rs (e.g., > >>> OAM protocols for Ethernet) are outside of the scope of > >> this document > >>> as they are covered in IEEE standards unless there is an > >> Interaction > >>> between these protocols and MPLS/IP protocols." > >> > >> May I suggest the above be rephrased as follows, and be=20 > put as a new > >> paragraph: > >> ---snip--- > >> The details regarding the "bridge module", as defined in the=20 > >> framework of L2PVN [RFC 4664], of the PE-rs as well as the native=20 > >> Ethernet MTU-s are outside of the scope of this document and the=20 > >> solutions defined as a result of this document, as they=20 > are covered=20 > >> in IEEE standards. The requirements in this draft apply=20 > to the "VPLS=20 > >> Forwarder" and the "Emulated LAN interface", which=20 > connects the VPLS=20 > >> Forwarder to the bridge module. > >> ---snip--- > >> > > > > That is NOT correct !! If you refer to both RFC 4465 and=20 > RFC 4464, an=20 > > end-to-end VPLS is defined to include bridge module, forwarder, and=20 > > the set of PWs. I know better, I helped the authors with these=20 > > definitions at the time of the writing of these RFCs. For example=20 > > RFC4465 says: " > > End-to-end VPLS consists of a bridge module and a LAN=20 > emulation module=20 > > ([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS=20 > > service it must include bridge module. >=20 > I don't understand. Your explanation above is confusing for two > reasons: > 1) First, if you look above at the top-most comment in this=20 > thread (relative to the Framework section) you agree that the=20 > "details regarding bridge operation for MTU-s and PE-rs ...=20 > are outside the =20 > scope of this document as they are covered in the IEEE standards". =20 > Now, you seem to be saying the opposite in the Requirements=20 > section.=20 Not really !! The two statements are consistent with each other. I am saying that we don't want to specify the details regarding the bridge module and its related protocols since they are already specified in the IEEE standards. However, we do want to cover the OAM requirements and framework for an end-to-end VPLS service as they are defined in RFC4445 and RFC4446 which include bridge module. Covering the OAM requirement and framework for an end-to-end service does NOT mean we need to specify the details regarding bridge operation !! Otherwise we need to have a 300-page spec. just for the bridge module !!=20 To put it simply, if you look at RFC4445 and RFC4446, the end-to-end VPLS service consist of bridge module and LAN emulation and sec 4.1.1 says that we need an OAM mechanism for an end-to-end service and sec. 4.1.3 says that we need an OAM mechanism for LAN emulation. Basically, we need to cover both because VPLS functionality is defined in terms of both as described in RFC4446 and RFC 4445. =20 > Specifically, that the above statement was irrelevant and now=20 > you are implying that you do want/need to duplicate IEEE=20 > standards in the =20 > requirements for OAM solutions that will be proposed for VPLS/VPWS. =20 > Or, perhaps I'm misunderstanding the rationale behind your=20 > explanation or intent? I think you have misunderstood it. I hope the above explanation is clear enough. > 2) Second, and much more germane to the requirements=20 > section, is what portion(s) of the requirements section apply=20 > to OAM solutions that will go Standards Track and,=20 > separately, what requirement(s) apply to OAM solutions that=20 > may go Informational, (assuming they are not duplicating or=20 > interfering with standards/protocols from other SDO's)? >=20 I would expect at the time the solution draft we can decide which one should go standard track and which one not but regarding the requirements in the above draft, they are very much follow the RFC4445 and RFC4446 and therefore they should be considered as standard track. Cheers, Ali > Thanks, >=20 > -shane=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4.1. VPLS as Service/Network=20 =20 4.1.1. VPLS as Bridged LAN Service=20 =20 The most common definition for VPLS is for bridged LAN service over=20 an MPLS/IP network. The service coverage is considered end-to-end=20 from UNI to UNI (or AC to AC) among the CE devices and it provides a=20 virtual LAN service to the attached CEs belonging to that service=20 instance. The reason it is called bridged LAN service is because the=20 VPLS-capable PE providing this end-to-end virtual LAN service is=20 performing bridging functions (either full or a subset) as described=20 in the [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN- REQ], includes both bridge module and LAN emulation module (as=20 specified in [L2VPN-FRWK]). =20 =20 =20 =20 Mohan & Sajassi Expires: September 2007 [Page 9] = =0C Internet Draft draft-ietf-l2vpn-oam-req-frmk-08.txt Jan 2007=20 =20 A VPLS service instance is also analogous to a VLAN provided by IEEE=20 802.1Q networks since each VLAN provides a Virtual LAN service to=20 its MAC users. Therefore, when a part of the service provider=20 network is Ethernet based (such as H-VPLS with QinQ access network),=20 there is a one-to-one correspondence between a VPLS service instance=20 and its corresponding provider VLAN in the service provider Ethernet=20 network. To check the end-to-end service integrity, the OAM=20 mechanism needs to cover the end-to-end VPLS service as defined in=20 [L2VPN-REQ] which is from AC to AC including bridge module, VPLS=20 forwarder, and the associated PWs for this service. This draft=20 specifies the framework and requirements for such OAM mechanism. =20 =20 The details regarding bridge operation for MTU-s and PE-rs (e.g.,=20 Ethernet encapsulation format, customer's Ethernet control protocol=20 handling, etc.) are outside of the scope of this document as they=20 are covered in IEEE standards unless there is an Interaction between=20 these protocols and VPLS or VPWS protocols.=20 =20 =20 =20 4.1.2. VPLS as a Network=20 =20 Sometimes VPLS is also used to refer to the underlying network that=20 supports bridged LAN services. This network can be an end-to-end=20 MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid=20 network consisting of MPLS/IP core and Ethernet access network as in=20 H-VPLS with QinQ access. In either case, the network consists of a=20 set of VPLS-capable PE devices capable of performing bridging=20 functions (either full or a subset). These VPLS-capable PE devices=20 can be arranged in a certain topology such as hierarchical topology=20 (H-VPLS) or distributed topology (D-VPLS) or some other topologies=20 such as multi-tier or star topologies. To check the network=20 integrity regardless of the network topology, network-level OAM=20 mechanisms (such as OAM for MPLS/IP networks) are needed. The=20 discussion of network-level OAM is outside of the scope of this=20 draft. =20 =20 =20 4.1.3. VPLS as (V)LAN Emulation=20 =20 Sometimes VPLS also refers to (V)LAN emulation. In such context,=20 VPLS only refers to the full mesh of PWs with split horizon that=20 emulates a LAN segment over MPLS/IP network for a given service=20 instance and its associated VPLS forwarder. Since the emulated LAN=20 segment is presented as a Virtual LAN (VLAN) to the bridge module of=20 a VPLS-capable PE, the emulated segment is also referred to as an=20 emulated VLAN. The OAM mechanisms in this context refer primarily to=20 integrity check of VPLS forwarders and its associated full-mesh of=20 PWs and the ability to detect and notify a partial mesh failure. =20 This draft also covers the OAM framework and requirements for such=20 OAM mechanism.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6. VPLS Service OAM Requirements=20 =20 These requirements are applicable to VPLS as a Bridged LAN service,=20 as described in Section 4.1.1. Further, the performance metrics used=20 in requirements are based on [MEF10] and [RFC2544].=20 =20 The details regarding "bridge module" operation and its associated=20 protocols are outside of the scope of this document as they are=20 covered in IEEE standards unless there is an Interaction between=20 these protocols and VPLS/VPWS protocols.=20 From l2vpn-bounces@ietf.org Tue Feb 27 09:26:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3Gt-0004xa-A8; Tue, 27 Feb 2007 09:25:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3Gs-0004xV-85 for l2vpn@ietf.org; Tue, 27 Feb 2007 09:25:38 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3Gq-0004oM-Ld for l2vpn@ietf.org; Tue, 27 Feb 2007 09:25:38 -0500 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 l1REHHa11263; Tue, 27 Feb 2007 09:17:17 -0500 (EST) 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 Date: Tue, 27 Feb 2007 09:25:21 -0500 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB0BF673C9@zcarhxm1.corp.nortel.com> In-Reply-To: <78DA378D-8CF1-4A46-A128-B8C0B9553C96@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcdaKCDojuIvmi2gTfe7o521HIfdOAATdRTg References: <75B2A84D9323BC4CA3977CF378CE75EB02CF69DC@xmb-sjc-21e.amer.cisco.com> <78DA378D-8CF1-4A46-A128-B8C0B9553C96@castlepoint.net> From: "Dinesh Mohan" To: "Shane Amante" , "Ali Sajassi \(sajassi\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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, Regarding your last comment: even the text proposed by you can be cited to be confusing since on one hand it implies that "bridge module" is defined in the L2VPN framework - "..."bridge module", as defined in the framework of L2PVN [RFC 4664].." - and then the text suggests that these are outside the scope since there are covered in IEEE standards - "...are outside of the scope of this document and the solutions defined as a result of this document, as they are covered in IEEE standards...." At this stage we seem to be simply wordsmithing. This document has been under review for last 2+ years and received extensive commments from you and has been updated numerous times, version -07 being a proof of that. The biggest concern regarding your proposed text is that it implies to rule out the details of the bridge module, which is OK IMO from the framework and requirements draft and if I understand correctly was stated by originally proposed text, however it also rules out from solutions perspective, and I see no reason for doing such in the framework or requirements document. Regarding the germane point, at least I am not personally aware of requirements having been qualified in this manner in past, please advise if this is not the case. Whether a solution is standards track or informational track should not influence the requirements, so far as we do not have disagreements on the requirements. This is infact a good reason why solutions should follow requirements instead of other way round. Engineering requirements from solutions will be counterproductive, in my view. Hopefully, we can get to the last call and start addressing the solutions, which is likely what you are concerned about and likely the group is also interested in addressing, including us. Cheers, --- Dinesh >>> "The details regarding bridge OAM operation for MTU-s and >> PE-rs (e.g., >>> OAM protocols for Ethernet) are outside of the scope of >> this document >>> as they are covered in IEEE standards unless there is an >> Interaction >>> between these protocols and MPLS/IP protocols." >> >> May I suggest the above be rephrased as follows, and be put as a new >> paragraph: >> ---snip--- >> The details regarding the "bridge module", as defined in the=20 >> framework of L2PVN [RFC 4664], of the PE-rs as well as the native=20 >> Ethernet MTU-s are outside of the scope of this document and the=20 >> solutions defined as a result of this document, as they are covered=20 >> in IEEE standards. The requirements in this draft apply to the "VPLS >> Forwarder" and the "Emulated LAN interface", which connects the VPLS=20 >> Forwarder to the bridge module. >> ---snip--- >> > > That is NOT correct !! If you refer to both RFC 4465 and RFC 4464, an=20 > end-to-end VPLS is defined to include bridge module, forwarder, and=20 > the set of PWs. I know better, I helped the authors with these=20 > definitions at the time of the writing of these RFCs. For example=20 > RFC4465 says: " > End-to-end VPLS consists of a bridge module and a LAN emulation module > ([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS=20 > service it must include bridge module. I don't understand. Your explanation above is confusing for two reasons: 1) First, if you look above at the top-most comment in this thread (relative to the Framework section) you agree that the "details regarding bridge operation for MTU-s and PE-rs ... are outside the =20 scope of this document as they are covered in the IEEE standards". =20 Now, you seem to be saying the opposite in the Requirements section. =20 Specifically, that the above statement was irrelevant and now you are implying that you do want/need to duplicate IEEE standards in the =20 requirements for OAM solutions that will be proposed for VPLS/VPWS. =20 Or, perhaps I'm misunderstanding the rationale behind your explanation or intent? 2) Second, and much more germane to the requirements section, is what portion(s) of the requirements section apply to OAM solutions that will go Standards Track and, separately, what requirement(s) apply to OAM solutions that may go Informational, (assuming they are not duplicating or interfering with standards/protocols from other SDO's)? Thanks, -shane=20 From l2vpn-bounces@ietf.org Tue Feb 27 17:08:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMATr-0007zA-0d; Tue, 27 Feb 2007 17:07:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMATp-0007yy-Qv for l2vpn@ietf.org; Tue, 27 Feb 2007 17:07:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMATo-0008BL-HV for l2vpn@ietf.org; Tue, 27 Feb 2007 17:07:29 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2007 14:07:28 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208"; a="394429320:sNHT236911806" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1RM7POL024050; Tue, 27 Feb 2007 14:07:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1RM7DnH022456; Tue, 27 Feb 2007 14:07:23 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 14:07:13 -0800 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 Date: Tue, 27 Feb 2007 14:07:12 -0800 Message-ID: In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB0BF673C9@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcdaKCDojuIvmi2gTfe7o521HIfdOAATdRTgAA32czA= From: "Vinit Bansal \(vbansal\)" To: "Dinesh Mohan" , "Ali Sajassi \(sajassi\)" X-OriginalArrivalTime: 27 Feb 2007 22:07:13.0458 (UTC) FILETIME=[A2792120:01C75ABB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=420; t=1172614045; x=1173478045; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vbansal@cisco.com; z=From:=20=22Vinit=20Bansal=20\(vbansal\)=22=20 |Subject:=20RE=3A=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-0 5=20[FrameworkReview] |Sender:=20; bh=1wryT2HcawqW1be6b9AuIxZLdU7rdjZukBs/RVp437c=; b=oSFRnE8TtmfcmCr3KJ2JmWOzN8R8sa8AiP4BsvG4sc3kASRxckurw86XSQxJHoiQJNIBUt5H aVtx4LTj4p7zROLsZUSFKttxKrZkjo4Jhg42MOJS4Z2AYagQDTLTvLdv; Authentication-Results: sj-dkim-5; header.From=vbansal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 =20 Hi Ali & Dinesh, I have a minor comment on the frame delay and frame delay variation requirements for VPLS and VPWS service. The frame delay variation requirements are dependent on the one-way frame delay measurement requirements and have been prioritized differently. R(4b) & R(15b): Frame Delay one-way requirement is SHOULD. R(5) & R(16) : Frame Delay Variation requirement is MUST. Thanks Vinit From l2vpn-bounces@ietf.org Tue Feb 27 17:15:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAbZ-0002qL-7X; Tue, 27 Feb 2007 17:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAbY-0002qB-Mj for l2vpn@ietf.org; Tue, 27 Feb 2007 17:15:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMAbX-00010C-DJ for l2vpn@ietf.org; Tue, 27 Feb 2007 17:15:28 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2007 14:15:27 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208"; a="43327448:sNHT54575577" 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 l1RMFQ30025418; Tue, 27 Feb 2007 14:15:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1RMEuEG007400; Tue, 27 Feb 2007 14:15:26 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 14:15:26 -0800 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 Date: Tue, 27 Feb 2007 14:15:25 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB02D535CC@xmb-sjc-21e.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] Thread-Index: AcdaKCDojuIvmi2gTfe7o521HIfdOAATdRTgAA32czAAA56I0A== From: "Ali Sajassi \(sajassi\)" To: "Vinit Bansal \(vbansal\)" , "Dinesh Mohan" X-OriginalArrivalTime: 27 Feb 2007 22:15:26.0065 (UTC) FILETIME=[C816FE10:01C75ABC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=989; t=1172614526; x=1173478526; 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=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-0 5=20[FrameworkReview] |Sender:=20; bh=YojbVMOyhk8cNMHfakVibkhxXA5mQA6QLxKmu/5FQ6A=; b=XVcOFVMuYE82o9V8uzYgPkHH+ugV4TSV5Ic+CTmqcFY5Z4P5YGYZ4uIAJH9igPSG6cN3Avz2 T2oIwHjWoMZxvRj5W46hyoxjqMafMTiVuhHm7j9OdH4U+FBEG9/lHvb3; Authentication-Results: sj-dkim-2; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 Vinit, One-way frame delay measurement requires clock synchronization in the network and that's why it is a "should"; whereas, frame delay variation doesn't require clock synch and should be lot simpler to implement. -Ali=20 =20 > -----Original Message----- > From: Vinit Bansal (vbansal)=20 > Sent: Tuesday, February 27, 2007 2:07 PM > To: Dinesh Mohan; Ali Sajassi (sajassi) > Cc: l2vpn@ietf.org > Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05=20 > [FrameworkReview] >=20 > =20 > Hi Ali & Dinesh, >=20 > I have a minor comment on the frame delay and frame delay=20 > variation requirements for VPLS and VPWS service. The frame=20 > delay variation requirements are dependent on the one-way=20 > frame delay measurement requirements and have been=20 > prioritized differently. >=20 > R(4b) & R(15b): Frame Delay one-way requirement is SHOULD. > R(5) & R(16) : Frame Delay Variation requirement is MUST. >=20 > Thanks > Vinit >=20 >=20 From l2vpn-bounces@ietf.org Wed Feb 28 02:22:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJ6x-00057h-Pl; Wed, 28 Feb 2007 02:20:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJ6w-00057Y-4n for l2vpn@ietf.org; Wed, 28 Feb 2007 02:20:26 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMJ6v-00032F-Go for l2vpn@ietf.org; Wed, 28 Feb 2007 02:20:26 -0500 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 4372364505; Wed, 28 Feb 2007 00:20:16 -0700 (MST) In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB02D53298@xmb-sjc-21e.amer.cisco.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02D53298@xmb-sjc-21e.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Shane Amante Date: Wed, 28 Feb 2007 00:20:18 -0700 To: Ali Sajassi (sajassi) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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 Ali, On Feb 27, 2007, at 12:15 AM, Ali Sajassi (sajassi) wrote: > Shane, > > I have sent out an updated copy of the draft earlier this afternoon; > however, it seems it got parked because of the attachment. Anyway, I > have copied section 4 and 6 at the bottom of this email. Also please > refer to my comments inline ... > >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Monday, February 26, 2007 8:31 PM >> To: Ali Sajassi (sajassi) >> Cc: l2vpn@ietf.org >> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 >> [FrameworkReview] >> >> Ali, >> >> On Feb 26, 2007, at 10:49 AM, Ali Sajassi (sajassi) wrote: >>> Shane, >>> >>> Please refer to my reply below with respect to your last three >>> comments/suggestion. I have removed the remaining >> texts/comments for >>> better clarity. >>> >>> >>>> >>>> I think we're getting close to finishing this. Please see below. >>>> I'm OK with most of your suggested changes, however there's still >>>> three outstanding items. >>>> >>>> >>>>> Proposed Text: Will add the following paragraph >>>>> >>>>> "The details regarding bridge operation for MTU-s and >> PE-rs (e.g., >>>>> Ethernet encapsulation format, customer's Ethernet >> control protocol >>>>> handling, etc.) are outside of the scope of this document >>>> as they are >>>>> covered in IEEE standards unless there is an Interaction >>>> between these >>>>> protocols and MPLS/IP protocols." >>>> >>>> May I suggest that you re-phrase "MPLS/IP" to be "VPLS or VPWS"? >>>> >>> >>> O.K. >>> >>>>> >>>>> Will add the following text to 4.1.1 for further clarification: >>>>> >>>>> "Service layer corresponds to the layer of the network, network >>>>> elements, that are service aware - e.g., if the service >>>> provided to an >>>>> end- user is >>>>> >>>>> a multipoint Ethernet service, then the service layer >>>> constitues the >>>>> network elements that are aware of the end-user Ethernet frames. " >>>> >>>> These seems like a very broad definition of "service-layer". >>>> Can you instead re-phrase your definition for 'service-layer' >>>> in terms of RFC >>>> 4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)? >>>> This would provide cohesiveness with the framework, requirements, >>>> solutions (VPLS-LDP/VPLS-BGP) and, ultimately, through OAM >> reqmt's of >>>> VPLS & VPWS. >>>> >>>> >>> >>> O.K. I will modify it based on L2VPN Requriement RFC and L2VPN >>> Framwork RFC. >> >> Can you please suggest text that you will use? >> > > I have pasted a copy of the proposed text at the end of this email. > >> >> >>>>> "The details regarding bridge OAM operation for MTU-s and >>>> PE-rs (e.g., >>>>> OAM protocols for Ethernet) are outside of the scope of >>>> this document >>>>> as they are covered in IEEE standards unless there is an >>>> Interaction >>>>> between these protocols and MPLS/IP protocols." >>>> >>>> May I suggest the above be rephrased as follows, and be >> put as a new >>>> paragraph: >>>> ---snip--- >>>> The details regarding the "bridge module", as defined in the >>>> framework of L2PVN [RFC 4664], of the PE-rs as well as the native >>>> Ethernet MTU-s are outside of the scope of this document and the >>>> solutions defined as a result of this document, as they >> are covered >>>> in IEEE standards. The requirements in this draft apply >> to the "VPLS >>>> Forwarder" and the "Emulated LAN interface", which >> connects the VPLS >>>> Forwarder to the bridge module. >>>> ---snip--- >>>> >>> >>> That is NOT correct !! If you refer to both RFC 4465 and >> RFC 4464, an >>> end-to-end VPLS is defined to include bridge module, forwarder, and >>> the set of PWs. I know better, I helped the authors with these >>> definitions at the time of the writing of these RFCs. For example >>> RFC4465 says: " >>> End-to-end VPLS consists of a bridge module and a LAN >> emulation module >>> ([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS >>> service it must include bridge module. >> >> I don't understand. Your explanation above is confusing for two >> reasons: >> 1) First, if you look above at the top-most comment in this >> thread (relative to the Framework section) you agree that the >> "details regarding bridge operation for MTU-s and PE-rs ... >> are outside the >> scope of this document as they are covered in the IEEE standards". >> Now, you seem to be saying the opposite in the Requirements >> section. > > Not really !! The two statements are consistent with each other. I am > saying that we don't want to specify the details regarding the bridge > module and its related protocols since they are already specified =20 > in the > IEEE standards. However, we do want to cover the OAM requirements and > framework for an end-to-end VPLS service as they are defined in =20 > RFC4445 > and RFC4446 which include bridge module. Perhaps I wasn't clear in my originally proposed text or follow-up =20 comments. Let me try again, this time using a different approach. Can we agree that there is a portion of the VPLS architecture that =20 relates to native Ethernet, for example, when the communication path =20 between an MTU-s and an upstream PE-rs is using Q-in-Q =20 encapsulation? If yes, then I have not seen any *requirement* in the =20= requirements section to acknowledge that the goal of any proposed =20 solution is to, at most, inter-work with -- but, MUST NOT break! -- =20 existing IEEE/ITU OAM standards, related to the native Ethernet =20 service-layer of VPLS, in order to provide an "end-to-end" solution =20 for VPLS OAM. There are some requirements in Section 6.11, (Transport =20 Independence), related to OAM transport independence & interworking/=20 adaptation. However, what I am recommending is that you be more =20 specific in Section 6 and clearly articulate that VPLS OAM solutions =20 MUST NOT: a) break existing IEEE/ITU OAM protocols; or, b) define =20 extensions or wholly new, competing OAM messages for IEEE/ITU OAM =20 protocols. Clearly, this would indicate to solutions designers that =20 if a solution requires (b), they had better work those changes =20 through the IEEE/ITU and, only after said changes, extensions, etc. =20 are approved in the appropriate SDO, may a VPLS OAM solution consider =20= interworking with that protocol. -shane > Covering the OAM requirement > and framework for an end-to-end service does NOT mean we need to =20 > specify > the details regarding bridge operation !! Otherwise we need to have a > 300-page spec. just for the bridge module !! > To put it simply, if you look at RFC4445 and RFC4446, the end-to-end > VPLS service consist of bridge module and LAN emulation and sec 4.1.1 > says that we need an OAM mechanism for an end-to-end service and sec. > 4.1.3 says that we need an OAM mechanism for LAN emulation. Basically, > we need to cover both because VPLS functionality is defined in =20 > terms of > both as described in RFC4446 and RFC 4445. > > >> Specifically, that the above statement was irrelevant and now >> you are implying that you do want/need to duplicate IEEE >> standards in the >> requirements for OAM solutions that will be proposed for VPLS/VPWS. >> Or, perhaps I'm misunderstanding the rationale behind your >> explanation or intent? > > I think you have misunderstood it. I hope the above explanation is =20 > clear > enough. > >> 2) Second, and much more germane to the requirements >> section, is what portion(s) of the requirements section apply >> to OAM solutions that will go Standards Track and, >> separately, what requirement(s) apply to OAM solutions that >> may go Informational, (assuming they are not duplicating or >> interfering with standards/protocols from other SDO's)? >> > > I would expect at the time the solution draft we can decide which one > should go standard track and which one not but regarding the > requirements in the above draft, they are very much follow the RFC4445 > and RFC4446 and therefore they should be considered as standard track. > > Cheers, > Ali > >> Thanks, >> >> -shane >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 4.1. VPLS as Service/Network > > 4.1.1. VPLS as Bridged LAN Service > > The most common definition for VPLS is for bridged LAN service over > an MPLS/IP network. The service coverage is considered end-to-end > from UNI to UNI (or AC to AC) among the CE devices and it =20 > provides a > virtual LAN service to the attached CEs belonging to that service > instance. The reason it is called bridged LAN service is because =20= > the > VPLS-capable PE providing this end-to-end virtual LAN service is > performing bridging functions (either full or a subset) as =20 > described > in the [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN- > REQ], includes both bridge module and LAN emulation module (as > specified in [L2VPN-FRWK]). > > > > Mohan & Sajassi Expires: September 2007 [Page =20 > 9] =0C > Internet Draft draft-ietf-l2vpn-oam-req-frmk-08.txt Jan 2007 > > A VPLS service instance is also analogous to a VLAN provided by =20 > IEEE > 802.1Q networks since each VLAN provides a Virtual LAN service to > its MAC users. Therefore, when a part of the service provider > network is Ethernet based (such as H-VPLS with QinQ access =20 > network), > there is a one-to-one correspondence between a VPLS service =20 > instance > and its corresponding provider VLAN in the service provider =20 > Ethernet > network. To check the end-to-end service integrity, the OAM > mechanism needs to cover the end-to-end VPLS service as defined in > [L2VPN-REQ] which is from AC to AC including bridge module, VPLS > forwarder, and the associated PWs for this service. This draft > specifies the framework and requirements for such OAM mechanism. > > The details regarding bridge operation for MTU-s and PE-rs (e.g., > Ethernet encapsulation format, customer's Ethernet control protocol > handling, etc.) are outside of the scope of this document as they > are covered in IEEE standards unless there is an Interaction =20 > between > these protocols and VPLS or VPWS protocols. > > > > 4.1.2. VPLS as a Network > > Sometimes VPLS is also used to refer to the underlying network that > supports bridged LAN services. This network can be an end-to-end > MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid > network consisting of MPLS/IP core and Ethernet access network =20 > as in > H-VPLS with QinQ access. In either case, the network consists of a > set of VPLS-capable PE devices capable of performing bridging > functions (either full or a subset). These VPLS-capable PE devices > can be arranged in a certain topology such as hierarchical topology > (H-VPLS) or distributed topology (D-VPLS) or some other topologies > such as multi-tier or star topologies. To check the network > integrity regardless of the network topology, network-level OAM > mechanisms (such as OAM for MPLS/IP networks) are needed. The > discussion of network-level OAM is outside of the scope of this > draft. > > > 4.1.3. VPLS as (V)LAN Emulation > > Sometimes VPLS also refers to (V)LAN emulation. In such context, > VPLS only refers to the full mesh of PWs with split horizon that > emulates a LAN segment over MPLS/IP network for a given service > instance and its associated VPLS forwarder. Since the emulated LAN > segment is presented as a Virtual LAN (VLAN) to the bridge =20 > module of > a VPLS-capable PE, the emulated segment is also referred to as an > emulated VLAN. The OAM mechanisms in this context refer =20 > primarily to > integrity check of VPLS forwarders and its associated full-mesh of > PWs and the ability to detect and notify a partial mesh failure. > This draft also covers the OAM framework and requirements for such > OAM mechanism. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 6. VPLS Service OAM Requirements > > These requirements are applicable to VPLS as a Bridged LAN service, > as described in Section 4.1.1. Further, the performance metrics =20 > used > in requirements are based on [MEF10] and [RFC2544]. > > The details regarding "bridge module" operation and its associated > protocols are outside of the scope of this document as they are > covered in IEEE standards unless there is an Interaction between > these protocols and VPLS/VPWS protocols. From l2vpn-bounces@ietf.org Wed Feb 28 02:34:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJJX-0003rW-Gm; Wed, 28 Feb 2007 02:33:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJJW-0003r9-0o for l2vpn@ietf.org; Wed, 28 Feb 2007 02:33:26 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMJJU-0005kC-Jj for l2vpn@ietf.org; Wed, 28 Feb 2007 02:33:26 -0500 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 F40A0645FC; Wed, 28 Feb 2007 00:33:06 -0700 (MST) In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB0BF673C9@zcarhxm1.corp.nortel.com> References: <75B2A84D9323BC4CA3977CF378CE75EB02CF69DC@xmb-sjc-21e.amer.cisco.com> <78DA378D-8CF1-4A46-A128-B8C0B9553C96@castlepoint.net> <183DD1B052A11A40B76125E42F1CBAAB0BF673C9@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5189EEF7-7A64-4BE2-827B-5FCA938B3258@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Wed, 28 Feb 2007 00:33:07 -0700 To: Dinesh Mohan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: l2vpn@ietf.org, "Ali Sajassi \(sajassi\)" Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview] 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, On Feb 27, 2007, at 7:25 AM, Dinesh Mohan wrote: > Shane, > > Regarding your last comment: even the text proposed by you can be > cited > to be confusing since on one hand it implies that "bridge module" is > defined in the L2VPN framework - "..."bridge module", as defined in > the > framework of L2PVN [RFC 4664].." - and then the text suggests that > these > are outside the scope since there are covered in IEEE standards - > "...are outside of the scope of this document and the solutions > defined > as a result of this document, as they are covered in IEEE > standards...." > > At this stage we seem to be simply wordsmithing. This document has > been > under review for last 2+ years and received extensive commments > from you > and has been updated numerous times, version -07 being a proof of > that. > > The biggest concern regarding your proposed text is that it implies to > rule out the details of the bridge module, which is OK IMO from the > framework and requirements draft and if I understand correctly was > stated by originally proposed text, however it also rules out from > solutions perspective, and I see no reason for doing such in the > framework or requirements document. Perhaps my point wasn't coming across clearly in my previous attempts. Please refer to the e-mail where I just responded to Ali to see if that clears things up. > Regarding the germane point, at least I am not personally aware of > requirements having been qualified in this manner in past, please > advise > if this is not the case. Whether a solution is standards track or > informational track should not influence the requirements, so far > as we > do not have disagreements on the requirements. This is infact a good > reason why solutions should follow requirements instead of other way > round. Engineering requirements from solutions will be > counterproductive, in my view. IMO, the point of requirements is to, as much as possible, constrain and guide the "scope" of proposed solutions, so that solutions: a) provide benefit to the end-users who will use them; b) avoid arguments down the road interpreting what requirements really meant; and, most importantly, c) assuming there are multiple, competing solutions, then the requirements document should be the main reference to evaluate how completely each solution satisfies the requirements. IOW, the more clear the requirements, the more benefit I believe it provides everyone down the road. -shane > Hopefully, we can get to the last call and start addressing the > solutions, which is likely what you are concerned about and likely the > group is also interested in addressing, including us. > > Cheers, > --- > Dinesh > > >>>> "The details regarding bridge OAM operation for MTU-s and >>> PE-rs (e.g., >>>> OAM protocols for Ethernet) are outside of the scope of >>> this document >>>> as they are covered in IEEE standards unless there is an >>> Interaction >>>> between these protocols and MPLS/IP protocols." >>> >>> May I suggest the above be rephrased as follows, and be put as a new >>> paragraph: >>> ---snip--- >>> The details regarding the "bridge module", as defined in the >>> framework of L2PVN [RFC 4664], of the PE-rs as well as the native >>> Ethernet MTU-s are outside of the scope of this document and the >>> solutions defined as a result of this document, as they are covered >>> in IEEE standards. The requirements in this draft apply to the >>> "VPLS > >>> Forwarder" and the "Emulated LAN interface", which connects the VPLS >>> Forwarder to the bridge module. >>> ---snip--- >>> >> >> That is NOT correct !! If you refer to both RFC 4465 and RFC 4464, an >> end-to-end VPLS is defined to include bridge module, forwarder, and >> the set of PWs. I know better, I helped the authors with these >> definitions at the time of the writing of these RFCs. For example >> RFC4465 says: " >> End-to-end VPLS consists of a bridge module and a LAN emulation >> module > >> ([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS >> service it must include bridge module. > > I don't understand. Your explanation above is confusing for two > reasons: > 1) First, if you look above at the top-most comment in this thread > (relative to the Framework section) you agree that the "details > regarding bridge operation for MTU-s and PE-rs ... are outside the > scope of this document as they are covered in the IEEE standards". > Now, you seem to be saying the opposite in the Requirements section. > Specifically, that the above statement was irrelevant and now you are > implying that you do want/need to duplicate IEEE standards in the > requirements for OAM solutions that will be proposed for VPLS/VPWS. > Or, perhaps I'm misunderstanding the rationale behind your explanation > or intent? > 2) Second, and much more germane to the requirements section, is what > portion(s) of the requirements section apply to OAM solutions that > will > go Standards Track and, separately, what requirement(s) apply to OAM > solutions that may go Informational, (assuming they are not > duplicating > or interfering with standards/protocols from other SDO's)? > > Thanks, > > -shane > From l2vpn-bounces@ietf.org Wed Feb 28 09:51:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQ8A-0003yN-3Q; Wed, 28 Feb 2007 09:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQ88-0003yF-Ox for l2vpn@ietf.org; Wed, 28 Feb 2007 09:50:08 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMQ86-00077e-GY for l2vpn@ietf.org; Wed, 28 Feb 2007 09:50:08 -0500 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 F15DE646A9 for ; Wed, 28 Feb 2007 07:49:58 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <2C9F4F32-E485-4474-91B9-7B0C36352399@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Wed, 28 Feb 2007 07:50:00 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: IETF 68: Draft L2VPN WG Agenda 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 Hi, The following is a draft L2VPN WG Agenda for our meeting in Prague, Czech Republic: WEDNESDAY, March 21, 2007, 1510-1610 ==================================== 1) Administrivia 2) WG Status and Update - 5 mins 3) UPDATE: LDP Extensions for Optimized MAC Address Withdrawal in H- VPLS http://tools.ietf.org/wg/l2vpn/draft-pdutta-l2vpn-vpls-ldp-mac- opt-01.txt Pranjal Dutta (pdutta@alcatel-lucent.com) 10 mins 4) VPLS Interoperability with Provider Backbone Bridges http://tools.ietf.org/wg/l2vpn/draft-sajassi-l2vpn-vpls-pbb- interop-00.txt Ali Sajassi 10 mins If you haven't gotten your agenda items in, please mail them to the chairs ASAP. Thanks! -shane & Vach