From l2vpn-bounces@ietf.org Mon Jun 05 11:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnH1R-0004I8-Nd; Mon, 05 Jun 2006 11:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnH1Q-00048x-FW; Mon, 05 Jun 2006 11:29:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnH1Q-0002Ex-5V; Mon, 05 Jun 2006 11:29:40 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k55FTOHp022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 15:29:24 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnH1A-0005Xm-BG; Mon, 05 Jun 2006 11:29:24 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 05 Jun 2006 11:29:24 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: l2vpn mailing list , l2vpn chair , Internet Architecture Board , l2vpn chair , RFC Editor Subject: Protocol Action: 'Provisioning, Autodiscovery, and Signaling in L2VPNs' to Proposed Standard 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 The IESG has approved the following document: - 'Provisioning, Autodiscovery, and Signaling in L2VPNs ' as a Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt Technical Summary There are a number of different kinds of "Provider Provisioned Layer 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different "provisioning models", i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any PW signaling protocol needs to have a method which allows each PW endpoint to identify the other; thus a PW signaling protocol will have the notion of an endpoint identifier. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each provisioning model. It discusses the way in which the endpoint identifiers are distributed by the discovery process, especially when the discovery process is based upon the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). Working Group Summary After WG Last Call, Luca Martini had raised an issue with respect to whether or not there needed to be coordination of AII Types between the l2vpn-signaling draft and the emergent MS-PW work. Luca proposed a solution to this dilemma on the L2VPN WG list: http://www.ietf.org/mail-archive/web/l2vpn/current/msg01121.html A discussion ensued between Bruce, Luca, Chris Metz, Florin, Mustapha, Vach & Shane to resolve it. In summary, we have all agreed that l2vpn-signaling is its own application and its use of Type-1 AII's is sufficient for it. In fact, procedures developed in l2vpn-signaling already account for PW routing/stitching & signaling as it relates to D-VPLS, (with Type-1 AII's), but do not give one the granularity of routing that MS-PW is aiming for. Another key difference is that l2vpn-signaling is focused on auto-discovery mechanisms for groups of PW's (e.g.: L2VPN's), whereas MS-PW is focused on both routing and signaling invidual PW's (not groups of PW's). In fact, it's not clear that MS-PW will initially be designed to support routing+signaling of groups of PW's, (which is another thing that distinguishes it from l2vpn-signaling). Protocol Quality The protocol is being implemented by at least two vendors. RFC Editor Note: Please add a normative reference for RFC 2119 and a citation to it at the end of section 1. Please replace: 3.3.2.1. BGP-based auto-discovery A framework for BGP-based auto-discovery for a generic L2VPN service is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this section we specify how BGP-based auto-discovery can be used to build VPWS instances. With: 3.3.2.1. BGP-based auto-discovery In this section we specify how BGP can be used to discover the information necessary to build VPWS instances. And replace: "A framework for BGP-based auto-discovery for a generic L2VPN service is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this section we specify how BGP-based auto-discovery can be used to build VPLS instances." With: "In this section we specify how BGP can be used to discover the information necessary to build a VPLS instance." Also, please remove the bibliographic reference to [I-D.ietf-l3vpn-bgpvpn-auto] in its entirety. From l2vpn-bounces@ietf.org Mon Jun 05 15:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL5Z-00052Q-Q7; Mon, 05 Jun 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL5P-0004zj-0X; Mon, 05 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnL5N-0006Hp-NW; Mon, 05 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k55Jo1Rx011421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnL5N-0002PQ-Cl; Mon, 05 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-ldp-09.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 : Virtual Private LAN Services Using LDP Author(s) : M. Lasserre, V. Kompella Filename : draft-ietf-l2vpn-vpls-ldp-09.txt Pages : 27 Date : 2006-6-5 This document describes a Virtual Private LAN Service (VPLS) solution using pseudo-wires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users, i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Multiple VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling pseudo-wire labels using LDP [RFC3036], extending [RFC4447]. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [RFC4448]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.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-vpls-ldp-09.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-vpls-ldp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-5123439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-ldp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-5123439.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Mon Jun 05 22:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnRgq-0000ld-Tg; Mon, 05 Jun 2006 22:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnRgp-0000lV-0k for l2vpn@ietf.org; Mon, 05 Jun 2006 22:53:07 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnRgn-00053e-Dp for l2vpn@ietf.org; Mon, 05 Jun 2006 22:53:06 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F006N03TT54@szxga01-in.huawei.com> for l2vpn@ietf.org; Tue, 06 Jun 2006 10:49:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F00JDZ3TT2M@szxga01-in.huawei.com> for l2vpn@ietf.org; Tue, 06 Jun 2006 10:49:05 +0800 (CST) Received: from d07358b ([10.70.153.108]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0F001NQ48Z23@szxml04-in.huawei.com> for l2vpn@ietf.org; Tue, 06 Jun 2006 10:58:11 +0800 (CST) Date: Tue, 06 Jun 2006 10:47:46 +0800 From: Du Wenhua To: l2vpn Message-id: <0J0F001NS48Z23@szxml04-in.huawei.com> Organization: Huawei Techlonogies, Co., Ltd MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Spam-Score: 0.9 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Re: I-D ACTION:draft-ietf-l2vpn-vpls-ldp-09.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: duwh@huawei.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org SGksDQoNCiAgSW4gUGFnZSAxMSBvZiB2cGxzLWxkcC0wOSBhZGRlZCBvbmUgY2xhdXNlOiBRdWFs aWZpZWQgbGVhcm5pbmcgaXMgdGhlIGRlZmF1bHQgbW9kZSBhbmQgTVVTVCBiZSBzdXBwb3J0ZWQu IFN1cHBvcnQgb2YgdW5xdWFsaWZpZWQgbGVhcm5pbmcgaXMgT1BUSU9OQUwuDQoNCiAgSSBoYXZl IHNvbWUgcXVlc3Rpb246DQoNCiAgMSkgV2h5IHF1YWxpZmllZCBsZWFyaW5nICBpcyB0aGUgZGVm YXVsdCBtb2RlIGluc3RlYWQgb2YgdW5xdWFsaXRpZWQ/DQogICAgIEluIHZwbHMtbGRwLTA4LCB0 aGVyZSBhcmUgbm8gc3VjaCBjbGF1c2UuIFdoeSB2cGxzLWxkcC0wOSBhZGQgc3VjaCBjbGF1c2U/ IA0KIA0KICAyKSBXaGVyZSBpcyB0aGUgZGVmaW5lIG9mICJhIGN1c3RvbWVyIiBpbiB0aGUgZHJh ZnQ/ICANCiAgICAgDQogICAgIENhc2UgMTogaW4gcXVhbGlmaWVkIGxlYXJuaW5nIG1vZGUsIGEg Y3VzdG9tZXIgd2l0aCAzIGN1c3RvbWVyIFZMQU5zLCBlYWNoIGN1c3RvbWVyIFZMQU4gaXMgYXNz aWduZWQgdG8gaXRzIG93bmVyIFZQTFMgaW5zdGFuY2UuIFNvIHRoZXJlIGFyZSAzIFZQTFMgaW5z dGFuY2VzLCAzIGN1c3RvbWVyIFZMQU4uDQogICAgIENhc2UgMjogaW4gdW5xdWFsaWZpZWQgbGVh cm5pbmcgbW9kZSwgMyBjdXN0b21lciB3aXRoIHRoZWlyIG93bmVyIDEgY3VzdG9tZXIgVkxBTnMo IHRoZXkgYXJlIGZyb20gMSA4MDIuMVEgZXRoZXJuZXQgcG9ydCksIGVhY2ggY3VzdG9tZXIgaXMg YXNzaWduZWQgdG8gaXRzIG93bmVyIFZQTFMgaW5zdGFuY2UuIFNvIHRoZXJlIGFyZSAzIFZQTFMg aW5zdGFuY2UsIDMgY3VzdG9tZXIgVkxBTi4NCiAgICAgVGhlIHJlc3VsdCBvZiBjYXNlIDEgaXMg c2FtZSBhcyB0aGF0IG9mIGNhc2UgMiwgYm90aCBvZiB0aGVtIGFyZSAzIFZQTFMgaW5zdGFuY2Vz LCAzIGN1c3RvbWVyIFZMQU5zLg0KICAgICAgDQogICAgIFNvIGhvdyB0byBkaXN0aW5ndWlzaCAg YmV0d2VlbiAiYSBjdXN0b21lciB3aXRoIDMgVkxBTiIgYW5kICIzIGN1c3RvbWVycyB3aXRoIDEg VkxBTiBlYWNoIj8gDQoNCg0KDQogDQoNCllvdXJzICAgDQqhoaGhoaGhoaGhoaGhoaGhRHUgV2Vu aHVhDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDYtMDYtMDYNCg0KDQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBJbnRlcm5ldC1EcmFmdHMgPEludGVybmV0LURyYWZ0c0BpZXRm Lm9yZz4NCj5TZW50OiAwMzo1MDowMSwyMDA2LTA2LTA2DQo+VG86IGktZC1hbm5vdW5jZUBpZXRm Lm9yZyA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KPlN1YmplY3Q6IEktRCBBQ1RJT046ZHJhZnQt aWV0Zi1sMnZwbi12cGxzLWxkcC0wOS50eHQNCg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4N Cj5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBMYXllciAyIFZpcnR1YWwgUHJpdmF0 ZSBOZXR3b3JrcyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPglUaXRsZQkJOiBWaXJ0 dWFsIFByaXZhdGUgTEFOIFNlcnZpY2VzIFVzaW5nIExEUA0KPglBdXRob3IocykJOiBNLiBMYXNz ZXJyZSwgVi4gS29tcGVsbGENCj4JRmlsZW5hbWUJOiBkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRw LTA5LnR4dA0KPglQYWdlcwkJOiAyNw0KPglEYXRlCQk6IDIwMDYtNi01DQo+CQ0KPlRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGEgVmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNlIChWUExTKSANCj4g IHNvbHV0aW9uIHVzaW5nIHBzZXVkby13aXJlcywgYSBzZXJ2aWNlIHByZXZpb3VzbHkgaW1wbGVt ZW50ZWQgb3ZlciANCj4gIG90aGVyIHR1bm5lbGluZyB0ZWNobm9sb2dpZXMgYW5kIGtub3duIGFz IFRyYW5zcGFyZW50IExBTiBTZXJ2aWNlcyANCj4gIChUTFMpLiAgQSBWUExTIGNyZWF0ZXMgYW4g ZW11bGF0ZWQgTEFOIHNlZ21lbnQgZm9yIGEgZ2l2ZW4gc2V0IG9mIA0KPiAgdXNlcnMsIGkuZS4s IGl0IGNyZWF0ZXMgYSBMYXllciAyIGJyb2FkY2FzdCBkb21haW4gdGhhdCBpcyBmdWxseSANCj4g IGNhcGFibGUgb2YgbGVhcm5pbmcgYW5kIGZvcndhcmRpbmcgb24gRXRoZXJuZXQgTUFDIGFkZHJl c3NlcyB0aGF0IA0KPiAgaXMgY2xvc2VkIHRvIGEgZ2l2ZW4gc2V0IG9mIHVzZXJzLiAgTXVsdGlw bGUgVlBMUyBzZXJ2aWNlcyBjYW4gYmUgDQo+ICBzdXBwb3J0ZWQgZnJvbSBhIHNpbmdsZSBQRSBu b2RlLiANCj4gICANCj4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBjb250cm9sIHBsYW5l IGZ1bmN0aW9ucyBvZiBzaWduYWxpbmcgDQo+ICBwc2V1ZG8td2lyZSBsYWJlbHMgdXNpbmcgTERQ IFtSRkMzMDM2XSwgZXh0ZW5kaW5nIFtSRkM0NDQ3XS4gIEl0IGlzIA0KPiAgYWdub3N0aWMgdG8g ZGlzY292ZXJ5IHByb3RvY29scy4gIFRoZSBkYXRhIHBsYW5lIGZ1bmN0aW9ucyBvZiANCj4gIGZv cndhcmRpbmcgYXJlIGFsc28gZGVzY3JpYmVkLCBmb2N1c2luZywgaW4gcGFydGljdWxhciwgb24g dGhlIA0KPiAgbGVhcm5pbmcgb2YgTUFDIGFkZHJlc3Nlcy4gIFRoZSBlbmNhcHN1bGF0aW9uIG9m IFZQTFMgcGFja2V0cyBpcyANCj4gIGRlc2NyaWJlZCBieSBbUkZDNDQ0OF0uDQo+DQo+QSBVUkwg Zm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC0wOS50eHQNCj4NCj5UbyByZW1vdmUg eW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVzc2FnZSB0 byANCj5pLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3b3JkIHVuc3Vic2Ny aWJlIGluIHRoZSBib2R5IG9mIHRoZSBtZXNzYWdlLiAgDQo+WW91IGNhbiBhbHNvIHZpc2l0IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZSANCj50byBj aGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuDQo+DQo+DQo+SW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3aXRoIHRoZSB1c2Vy bmFtZQ0KPiJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3Mu IEFmdGVyIGxvZ2dpbmcgaW4sDQo+dHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQgdGhlbg0K PgkiZ2V0IGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtMDkudHh0Ii4NCj4NCj5BIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbg0KPmh0dHA6Ly93d3cu aWV0Zi5vcmcvc2hhZG93Lmh0bWwgDQo+b3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRv dy1zaXRlcy50eHQNCj4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQg YnkgZS1tYWlsLg0KPg0KPlNlbmQgYSBtZXNzYWdlIHRvOg0KPgltYWlsc2VydkBpZXRmLm9yZy4N Cj5JbiB0aGUgYm9keSB0eXBlOg0KPgkiRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt bDJ2cG4tdnBscy1sZHAtMDkudHh0Ii4NCj4JDQo+Tk9URToJVGhlIG1haWwgc2VydmVyIGF0IGll dGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGluDQo+CU1JTUUtZW5jb2RlZCBmb3JtIGJ5 IHVzaW5nIHRoZSAibXBhY2siIHV0aWxpdHkuICBUbyB1c2UgdGhpcw0KPglmZWF0dXJlLCBpbnNl cnQgdGhlIGNvbW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9yZSB0aGUgIkZJTEUiDQo+CWNvbW1h bmQuICBUbyBkZWNvZGUgdGhlIHJlc3BvbnNlKHMpLCB5b3Ugd2lsbCBuZWVkICJtdW5wYWNrIiBv cg0KPglhIE1JTUUtY29tcGxpYW50IG1haWwgcmVhZGVyLiAgRGlmZmVyZW50IE1JTUUtY29tcGxp YW50IG1haWwgcmVhZGVycw0KPglleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxs eSB3aGVuIGRlYWxpbmcgd2l0aA0KPgkibXVsdGlwYXJ0IiBNSU1FIG1lc3NhZ2VzIChpLmUuIGRv Y3VtZW50cyB3aGljaCBoYXZlIGJlZW4gc3BsaXQNCj4JdXAgaW50byBtdWx0aXBsZSBtZXNzYWdl cyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbg0KPglob3cgdG8gbWFuaXB1 bGF0ZSB0aGVzZSBtZXNzYWdlcy4NCj4JCQ0KPgkJDQo+QmVsb3cgaXMgdGhlIGRhdGEgd2hpY2gg d2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPmltcGxlbWVudGF0aW9u IHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlDQo+SW50 ZXJuZXQtRHJhZnQuDQo+DQo+Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQo+Q29udGVudC1JRDog PDIwMDYtNi01MTIzNDM5LkktREBpZXRmLm9yZz4NCj4NCj5FTkNPRElORyBtaW1lDQo+RklMRSAv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtMDkudHh0DQo+DQo9ID0g PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCg== From l2vpn-bounces@ietf.org Wed Jun 07 15:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo43L-0003mk-Rx; Wed, 07 Jun 2006 15:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42Z-000290-BV; Wed, 07 Jun 2006 15:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42Z-0007Yv-8b; Wed, 07 Jun 2006 15:50:07 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo42U-0004SS-K4; Wed, 07 Jun 2006 15:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k57Jo2Rx002887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fo42U-0002kY-4E; Wed, 07 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-ipls-06.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 : IP-Only LAN Service (IPLS) Author(s) : H. Shah, et al. Filename : draft-ietf-l2vpn-ipls-06.txt Pages : 22 Date : 2006-6-7 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-06.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-ipls-06.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-ipls-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-7143048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-ipls-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-ipls-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-7143048.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Wed Jun 07 15:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo43R-00040K-4f; Wed, 07 Jun 2006 15:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42a-00029u-5n; Wed, 07 Jun 2006 15:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42a-0007ZR-2S; Wed, 07 Jun 2006 15:50:08 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo42U-0004SO-HF; Wed, 07 Jun 2006 15:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k57Jo2Rx002883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fo42U-0002kK-25; Wed, 07 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-05.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 : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : H. Shah, et al. Filename : draft-ietf-l2vpn-arp-mediation-05.txt Pages : 20 Date : 2006-6-7 The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudo-wire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudo-wire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudo-wire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. In particular, the applicability of ARP mediation to ISIS is not addressed as IS-IS PDUs are not sent over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-05.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-arp-mediation-05.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-arp-mediation-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-7142202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-arp-mediation-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-arp-mediation-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-7142202.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Thu Jun 08 11:36:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMYh-0006kx-1x; Thu, 08 Jun 2006 11:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMYg-0006kj-7N for l2vpn@ietf.org; Thu, 08 Jun 2006 11:36:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLMq-0008Qz-Bm for l2vpn@ietf.org; Thu, 08 Jun 2006 10:20:12 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoKli-0007oy-Lc for l2vpn@ietf.org; Thu, 08 Jun 2006 09:41:51 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 5122E6450A for ; Thu, 8 Jun 2006 07:41:45 -0600 (MDT) Message-ID: <4488291B.30904@castlepoint.net> Date: Thu, 08 Jun 2006 07:41:47 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) 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: -2.6 (--) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: IETF 66: l2vpn mtg 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 need to start planning for IETF 66. Can you please send a list of slot requests to Vach & I ASAP? Thanks! -shane & Vach From l2vpn-bounces@ietf.org Mon Jun 19 15:58:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPtK-0008Ty-DC; Mon, 19 Jun 2006 15:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPl9-0006l7-LC; Mon, 19 Jun 2006 15:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPl9-0000TI-J1; Mon, 19 Jun 2006 15:50:07 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsPl4-0005IE-SD; Mon, 19 Jun 2006 15:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2Hp007643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl4-0007aI-Am; Mon, 19 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-requirements-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 : Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks Author(s) : W. Augustyn, Y. Serbest Filename : draft-ietf-l2vpn-requirements-07.txt Pages : 26 Date : 2006-6-19 This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-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-requirements-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-requirements-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: <2006-6-19143125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-requirements-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-requirements-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19143125.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Jun 20 12:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsimu-0006up-Vz; Tue, 20 Jun 2006 12:09:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsimt-0006tx-Vv for l2vpn@ietf.org; Tue, 20 Jun 2006 12:09:11 -0400 Received: from [220.181.12.14] (helo=m12-14.163.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsiXd-0008E8-Oz for l2vpn@ietf.org; Tue, 20 Jun 2006 11:53:32 -0400 Received: from ZhongQiwen (unknown [59.40.154.151]) by smtp11 (Coremail) with SMTP id wKjADjFAtA_TGZhEIh7gDg==.35937S2; Tue, 20 Jun 2006 23:52:52 +0800 (CST) From: "Zhong Qiwen" To: Date: Tue, 20 Jun 2006 23:52:38 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 1.5 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Questions about the L2VPN OAM 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 DQoJSGksIEFsbDoNCgkNCglJJ2FtIHB1enpsZWQgYWJvdXQgdGhlIHRvcGljIG9mIE9BTSBpbiBM MlZQTiAhICB3b3VsZCBzb21lYm9keSBoZWxwIG1lID8NCg0KCU15IHF1ZXN0aW9ucyBhcmU6DQoN CgkxLS0tV2hhdCBleGFjdGx5IHRoZSBMMlZQTiBPQU0gaXMgPyBXaGF0IGlzIHRoZSBwb2ludCBv ZiB2aWV3IHRvIHN0dWR5IHRoZSBMMlZQTiBPQU0gPyANCgkJRm9yIGhvbW9nZW5lb3VzIEV0aGVy bmV0IFZQV1MsIA0KCQkJV291bGQgaXQgYmUgIkV0aGVybmV0IE9BTSBiYXNlZCBvbiBZLjE3MzEg b3IgODAyLjFhZyArIFBXIE9BTSAiID8NCgkJRm9yIGhvbW9nZW5lb3VzIEFUTSBWUFdTLA0KCQkJ V291bGQgaXQgYmUgIkFUTSBPQU0gKyBQVyBPQU0iPw0KCQkoIEhldGVyb2dlbmVvdXMgVlBXUywg bGVmdCBmb3IgZnVydGhlciBkaXNjdXNzICEgKQ0KCQkJDQoJCUZvciBWUExTIE9BTSAsIHNob3Vs ZCB3ZSBmb2N1cyBvbiB0aGUgIkZ1bGwgTWVzaCBWUExTIENvcmUiID8gaXQncyBmYXVsdHMsIGRl ZmVjdHMgYW5kIHBlcmZvcm1hbmNlID8gDQoNCgkyLS0tT3IsIGlzIHRoZSBMMlZQTiBPQU0gYW5v dGhlciBjb25jZXB0IGJlc2lkZXMgY3VzdG9tZXIgbmV0d29yayBPQU0gYW5kIHByb3ZpZGVyIG5l dHdvcmsgT0FNID8NCg0KDQoJCQkJCQkJCQkJCQkJCQkJCQkJYmVzdCByZWdhcmRzICE= From l2vpn-bounces@ietf.org Tue Jun 20 15:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmFI-0002e4-98; Tue, 20 Jun 2006 15:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmEe-0001SQ-5N; Tue, 20 Jun 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmEc-0003To-Hd; Tue, 20 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo2Rx015721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEc-0003bq-7k; Tue, 20 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-bgp-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 : Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-l2vpn-vpls-bgp-07.txt Pages : 34 Date : 2006-6-20 Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet Local Area Network (LAN), in contrast to the usual Layer 2 VPNs, which are point-to- point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-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-vpls-bgp-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-vpls-bgp-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: <2006-6-20120947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-bgp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bgp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20120947.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Thu Jun 22 18:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY0j-0005R3-DV; Thu, 22 Jun 2006 18:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXzu-0003yi-TV; Thu, 22 Jun 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXzu-0003Fc-F5; Thu, 22 Jun 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo1Hp029322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzt-0007sl-Rq; Thu, 22 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-bgp-08.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-l2vpn-vpls-bgp-08.txt Pages : 37 Date : 2006-6-22 Virtual Private LAN (Local Area Network) Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-bgp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-bgp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22153237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-bgp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bgp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22153237.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Fri Jun 23 02:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fter7-0005l2-QG; Fri, 23 Jun 2006 02:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fter7-0005kx-3B for l2vpn@ietf.org; Fri, 23 Jun 2006 02:09:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fter5-0007EW-R4 for l2vpn@ietf.org; Fri, 23 Jun 2006 02:09:25 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 Jun 2006 23:09:23 -0700 X-IronPort-AV: i="4.06,167,1149490800"; d="scan'208"; a="299698055:sNHT46161922" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5N69N3Z027750; Thu, 22 Jun 2006 23:09:23 -0700 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 k5N69McN014560; Thu, 22 Jun 2006 23:09:23 -0700 (PDT) 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.211); Thu, 22 Jun 2006 23:09:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 23:09:21 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB01BB4180@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: AcZcWSJ+WkzLWBJVQ+GwBeMR0WIG+wfHi6Jw From: "Ali Sajassi \(sajassi\)" To: "Shane Amante" , X-OriginalArrivalTime: 23 Jun 2006 06:09:22.0572 (UTC) FILETIME=[924C1CC0:01C6968B] DKIM-Signature: a=rsa-sha1; q=dns; l=19670; t=1151042963; x=1151906963; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=22Ali=20Sajassi=20\(sajassi\)=22=20 |Subject:RE=3A=20WG=20Last=20Call=3A=20draft-ietf-l2vpn-oam-req-frmk-05=20[Framew orkReview]; X=v=3Dcisco.com=3B=20h=3Dhje5e4u+KnnLOPqOn0nKGRTeWgg=3D; b=bPK6EdfRe4C2lhsKlg6baT6MhaHPi+N7aps/aN04Ximf2SMvFXbfWjgvxTsrdvY9rAZ7OGvr 0nNTvamWR2ChgZ52c5+aWLd7NhIFX/Z1/uoqfkXutKstZ4ImydVQF8r0; Authentication-Results: sj-dkim-8.cisco.com; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd Cc: 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, 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 =20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > 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] >=20 > Ali, Dinesh, et. al, >=20 > As stated in an earlier e-mail, below are the comments=20 > relating to 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: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > Section 1: > I understand the intent to have a comprehensive set of OAM=20 > reqmt's, but I'm not sure why the L2VPN WG specifically needs=20 > to take on the breadth of what this statement suggests,=20 > specifically "a reference model for OAM layering and=20 > furthermore emphasizes the importance of proper independent=20 > layering in design and development of OAM functionality across ..."=20 > Wouldn't proper OAM layering be a topic more suitable for the=20 > Ops Area? > ---snip--- > This document provides a description and a reference model=20 > for OAM layering and furthermore emphasizes the importance of=20 > proper independent layering in design and development of OAM=20 > functionality across L2VPN services, Pseudo Wires (PWs) and=20 > Public Switched Network (PSN) tunnels. > ---snip--- >=20 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. =20 > Section 3.3 (MEPs and MIPs) > It would be *extremely* useful to address this comment, as it=20 > relates to "Scalability" of VPLS OAM, in Sections 6 (& 7). =20 > Specifically, in a mp2p environment like VPLS, it would be=20 > useful to assert some guidelines as it relates to the number=20 > of ME's per service instance per PE, (particularly for the=20 > "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=20 > and represents a monitored entity. For example, in a VPLS=20 > service which involves n CEs, all the MEs associated with the=20 > VPLS service in the customer OAM domain (i.e. from CE to CE)=20 > can be considered to be part of a VPLS MEG, where the n-point=20 > MEG consists of a maximum of n(n-1)/2 MEs. > ---snip--- >=20 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). > 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. =20 > Specifically, I think what you're describing in Section 4.1.1=20 > is VPLS operates as a peer-layer to the native (Ethernet)=20 > service-layer. In Section 4.1.2, I think you are attempting=20 > to describe VPLS as a peer-layer as well as a client-layer to=20 > an underlying MPLS or IP substrate. Finally, I think in=20 > Section 4.1.3, you're finally up to VPLS as a service-layer=20 > 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. =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 in the context of the access-layer networks),=20 > 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. =20 > In addition, in Section 4.1.2, there's a vague statement=20 > with respect to OAM mechanisms at the "network level". The=20 > way the current sentence is phrased, I believe you are saying=20 > that network-layer OAM mechanisms are required; however, it's=20 > not in our charter to solve MPLS-layer OAM. (Note, to be=20 > fair, you do say in Section 4.2.1 that OAM at the=20 > transport-layer is out-of-scope of this doc, 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=20 > OAM mechanisms are needed for the VPLS networks. > ---snip--- > Related to the last comment, the words "network level" is=20 > IMO vague.=20 > Perhaps it would be better to state that it refers to=20 > network-layer 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 & C are properly aligned. You should fix them. >=20 Great! We will do that.=20 > Section 4.2.3: > Again, it doesn't look like the diagram in Figure 5 is=20 > properly aligned with the scenarios depicted in A, B & C. > It looks pretty align to us, but we will search for mis-alignment. If you can point out expilictly what is misaligned, it would help.=20 =20 > Section 4.2.3: > In general, this section says that it is 'expected' that MEPs=20 > and MIPs will be implemented into various components of the=20 > VPLS architecture, (VPLS forwarder/briding modules). Are you=20 > discussing the OAM framework here, or do these 'expected'=20 > details surrounding an eventual implementation which would=20 > mean these would translate into MUSTs or SHOULDs in the=20 > reqmt's sections? (I'm trying to seek clarity of what you're=20 > intent is with these statements, because I don't see anything=20 > related to MEPs and MIPs in the reqmt's section). > Our intention here is to satisfy your previous request as to show the MEPs and MIPs relate to L2VPN framework.=20 =20 > Section 4.2.3: > (D) depicts both MEPs and MIPs, however this sentence only=20 > discusses expectations around MEPs ... what about the MIPs in=20 > Scenario (D)? > ---snip--- > (D) represents the MEPs and MIPs > visible within the service provider domain. These MEPs are=20 > expected to be implemented in the bridge module/VPLS=20 > forwarder of a PE device, as per the [L2VPN-FRWK]. > ---snip--- >=20 Agreed. We will clarify it by adding MIPs to the above sentence: "These MEPs and MIPs are expected ..." > Section 4.2.3: > In which components of the VPLS architecture do you expect=20 > the MEPs and MIPs in (E) to be implemented? >=20 Agreed. We will clarify this by indicating that the MIPs for (E) would exist when you have an Ethernet access network (e.g., section 11 of vpld-ldp draft). > Section 4.2.4: > What about VPLS-BGP? What identifiers are used for it, since=20 > it doesn't use PW-id's? >=20 PW-ids are used in VPLS-BGP but instead they are signaled via BGP and we don't care about what signaling mechanism is used.=20 > Section 4.2.4: > ---snip--- > Both PW-ids and VLAN tags for a given VPLS instance are=20 > associated with a Service Identifier (e.g., VPN identifier). > ---snip--- > Which identifier do you have in mind, i.e.: VPLS-ID in=20 > l2vpn-signaling? >=20 By PW-id, it is meant the associated MPLS label. > Section 5: > Diagrams aren't aligned Figure 6, VPWS Reference Model. >=20 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 certain type. The core network connecting PEs=20 > can be IP, MPLS, etc. > ---snip--- >=20 The statement ought to be: "In common scenarios, it could 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=20 > reference back to the heterogenous & homogeneous terminology=20 > introduced in the aforementioned section? > ---snip--- > Therefore, it is important that the OAM mechanisms can be=20 > applied to all these network types. > ---snip--- >=20 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=20 > you're missing a > describing the right-most end-point in the diagram. >=20 Right, We will fix it. > Section 5.2.2: > Diagrams in Figure 8a & 8b are not aligned properly, and I=20 > believe you're missing a > describing the right-most=20 > end-point in the diagram. >=20 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=20 > defined as it related specifically to PW's or AC's. =20 > Furthermore, does ME refer to the NSP, or some other=20 > function/layer of VPWS? >=20 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 > Section 5.2.2: > ---snip--- > The > distinction between Figure 8b (C) and (D) is that (C) MEs=20 > have MEPs at CE and PEs and have no MIPs while (D) MEs have=20 > MEPs at CEs and PEs and likely MIPs in between, thereby=20 > having a visibility to Operator network. > ---snip--- > Can you clarify this part of the sentence: "(C) MEs have=20 > MEPs at CE and PEs and have no MIPs" ... specifically, it's=20 > not clear at all > (e.g.: to which devices or components of VPWS) where MEPs and=20 > MIPs are applicable. > Can you also clarify the second half of that sentence=20 > "(D) MEs have MEPs at CEs and PEs and likely MIPs in between,=20 > thereby having a visibility to Operator network." ... again,=20 > it's not clear where (e.g.:=20 > to which devices or components of VPWS) MEPs are MIPs are=20 > applicable. I think it's just the way you're phrasing it, so=20 > perhaps re-phrasing in a better way would be good. >=20 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 furthermore, MIPs may be present in between the MEPs; thereby providing visibility of the network to the operator." > Section 5.2.3: > Which option are you referring to? > ---snip--- > The advantage of this option is that end-to-end and segment=20 > OAM can be carried out in an independent manner. > ---snip--- > Agreed. We will modify the text to clarify it: "The advantage of having layered OAM is that ..." =20 > Section 5.2.3: > Suggest putting this paragraph before the diagram and=20 > changing the intro to s/Though, different possible OAM layers=20 > have been shown/Although many different OAM layers are=20 > possible, as shown in Figure 9,/. > ---snip--- > Though, different possible OAM layers have been shown in the=20 > Figure 9, not all may be realized. For example, Figure (B2)=20 > and (D) may be adequate in some cases. > ---snip--- >=20 That's fine. >=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 > 1.1) Formatting needs to be fixed/aligned > 2) Formatting needs to be fixed/aligned > 2) "CEs that are member of the same service instance=20 > communicate with each other as if they are connected via a=20 > bridged LAN." > s/member/members/ Agreed. > 4.1.1) "... and it provides a virtual LAN service to the=20 > attach CEs belonging to that service instance." > s/attach CEs/attached CEs/ Agreed. > 4.1.1) "The reason it is called bridged LAN service is=20 > because the VPLS-capable PE provide this end-to-end virtual=20 > LAN service performing bridging functions (either full or a=20 > subset) as described in the [L2VPN-FRWK]." > s/provide/providing/ > s/performing/is performing/ Agreed. > 4.1.3. "Since the emulated LAN segment is presented as a=20 > Virtual LAN (VLAN) to the bridge module of a VPLS-capable PE,=20 > emulated segment is also referred to as an emulated VLAN." > s/VPLS-capable PE, emulated/VPLS-capable PE, the emulated/ Agreed. > 4.2.4: > ---snip--- > As described in [VPLS-LDP], VPLS instance can be identified=20 > in an Ethernet domain (e.g., 8021.d domain) using VLAN tag > ---snip--- > s/VPLS instance/a VPLS instance/ > s/8021.d/802.1d/ Agreed. > 4.2.4: > "For Ethernet services e.g. VPLS," > s/e.g. VPLS,/, e.g. VPLS,/ Agreed. > Section 4.2.4: > ---snip--- > MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids must be=20 > unique within their corresponding Service Identifiers within=20 > the OAM domains. > ---snip--- > s/, i.e. MEP Ids and MIP Ids must/, i.e. MEP Ids and MIP=20 > Ids, must/=20 Agreed. > Section 5.1: > ---snip--- > . VPWS with homogeneous ACs (where both ACs are same type) .=20 > VPWS with heterogeneous ACs (where the ACs are of different > types) > ---snip--- > s/type/Layer-2 encapsulation/ Agreed. > 5.2: > ---snip--- > As an example, the access network between CE and PE on one=20 > side can be Ethernet bridged network, ATM network, etc. > ---snip--- > s/be Ethernet bridged network/be an Ethernet bridged/=20 Reject. It is intended to say "bridged network" as defined in IEEE standards > Section 5.2.1: > ---snip--- > Service provider network can be considered to be segmented=20 > into core network and two types of access network. > ---snip--- > s/Service provider network/A service provider network/ > s/into core network/into a core network/=20 Agreed. > Section 5.2.1: > ---snip--- > In most general case, a PE can be client service aware when=20 > it processes client service PDUs and is responsible for encapsulating > ---snip--- > s/In most general case/In the most general case/=20 Agreed. > Section 5.2.1: > ---snip---- > ... is responsible for encapsulating > and de-encapsulating client service PDUs onto PW and ACs. > ---snip--- > s/onto PW and ACs/onto a PW and ACs/=20 Agreed. > Section 5.2.2 > ---snip--- > PEs of a given operator and could > also be present in access if the access is > ---snip--- > s/present in access/present in the access network/ > s/if the access/if the ACs are/ Agreed. > Section 5.2.2: > "by the customer and customer" > s/and customer/and the customer/ > Section 5.2.2: > "The service provider is responsible to monitor the PW ME" > s/responsible to monitor/responsible for monitoring/=20 Agreed. > Section 5.2.2: > "responsibility shared between the customer and service provider" > Change this whole quote to be: > "the shared responsibility of the customer and the service provider" > Section 5.2.2: > ---snip--- > Figure 8b highlights another management model, where the CEs=20 > are managed by the Service Provider and where CEs and PEs are=20 > connected via access network. > ---snip--- > s/via access network/via an access network/=20 Agreed. > Section 5.2.3: > ---snip--- > to specific responsibilities within the network. > ---snip--- > s/specific responsibilities/specific areas/ Section 5.2.3: > ---snip--- > The CE interfaces support MEPs at end-to-end Service Provider=20 > OAM level for VPWS end-to-end service as shown in Figure 9=20 > (B1) and (B2). > ---snip--- > s/MEPs at end-to-end Service Provider/MEPs at the=20 > end-to-end Service Provider/ > s/VPWS end-to-end service/VPWS as an end-to-end service/=20 Agreed. > Section 5.2.3: > ---snip--- > Service Provider OAM level when PEs are client service aware,=20 > shown in Figure 9 (B2). As an example, if one considers an=20 > enc-to-end Ethernet line service offered to subscriber=20 > between between CE1 and CE2 which is realized via ATM type=20 > AC1 and AC2 and PW which encapsulates ATM over MPSL, the PEs=20 > can be considered as Ethernet service unaware, > ---snip--- > s/, shown in Figure 9 (B2)/, as shown in Figure 9 (B2)/ > s/enc-to-end/end-to-end/ > s/offered to subscriber between/offered to a subscriber/ > s/MPSL/MPLS/ Agreed > Section 5.2.4: > ---snip--- > In VPWS, the MEPs and MIPs should be identified with their=20 > native addressing schemes. MEPs and MIPs Identifiers, i.e.=20 > MEP Ids and MIP Ids must be unique within their corresponding=20 > OAM domains and must also be unique to the VPWS service instance. > ---snip--- > s/i.e. MEP Ids and MIP Ids must/i.e. MEP IDs and MIP IDs, must/ >=20 Agreed. > -shane >=20 >=20 > Shane Amante wrote: > > The authors of draft-ietf-l2vpn-oam-req-frmk-05, have requested a=20 > > L2VPN WG Last Call for this I-D, "L2VPN OAM Requirements and=20 > > Framework". It can be found at: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.t > > xt > >=20 > > Please thoroughly review the document and send any comments=20 > to the list.=20 > > Also, please indicate whether you believe this document is=20 > ready to=20 > > go to the IESG "as is", or whether there should be a cleaner=20 > > separation between the requirements and framework. In the latter=20 > > case, the I-D would not pass LC, would need to get=20 > re-drafted for WG=20 > > comments and the separate components sent out for WG Last=20 > Call again. > >=20 > > The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7). > >=20 > > -shane > >=20 >=20 From l2vpn-bounces@ietf.org Sun Jun 25 16:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FubH7-00049G-5l; Sun, 25 Jun 2006 16:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FubH5-00049B-KJ for l2vpn@ietf.org; Sun, 25 Jun 2006 16:32:07 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FubH4-00022s-Cm for l2vpn@ietf.org; Sun, 25 Jun 2006 16:32:07 -0400 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 862666450E for ; Sun, 25 Jun 2006 14:32:01 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4488291B.30904@castlepoint.net> References: <4488291B.30904@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6435931C-B729-45AF-8CD6-6BD7EE7450EF@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Sun, 25 Jun 2006 14:32:04 -0600 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: IETF 66: l2vpn mtg 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 Folks, We've only had 1 request for a timeslot for the l2vpn meeting at IETF 66, from Tom Nadeau on the VPLS/VPWS MIB work. If you have something to discuss or your request didn't make it to us for some reason, please send them to us ASAP. -shane & Vach On Jun 8, 2006, at 7:41 AM, Shane Amante wrote: > We need to start planning for IETF 66. Can you please send a list > of slot requests to Vach & I ASAP? > > Thanks! > > -shane & Vach > From l2vpn-bounces@ietf.org Mon Jun 26 14:53:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwCi-00045b-8P; Mon, 26 Jun 2006 14:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwCg-00045W-GX for l2vpn@ietf.org; Mon, 26 Jun 2006 14:52:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwCf-0001cE-6m for l2vpn@ietf.org; Mon, 26 Jun 2006 14:52:58 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2006 11:52:56 -0700 X-IronPort-AV: i="4.06,177,1149490800"; d="scan'208,217"; a="301144974:sNHT47856778" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5QIquX4006376 for ; Mon, 26 Jun 2006 11:52:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5QIqu9s023667 for ; Mon, 26 Jun 2006 11:52:56 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 11:52:40 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69951.B2F850BF" Date: Mon, 26 Jun 2006 11:52:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: draft-ietf-l2vpn-ipls-06.txt (Vinit Bansal) Thread-Index: AcaZUbKbyo41S7GORh6x/QqmlZbbVQ== From: "Vinit Bansal \(vbansal\)" To: X-OriginalArrivalTime: 26 Jun 2006 18:52:40.0301 (UTC) FILETIME=[B31C39D0:01C69951] DKIM-Signature: a=rsa-sha1; q=dns; l=2550; t=1151347976; x=1152211976; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=vbansal@cisco.com; z=From:=22Vinit=20Bansal=20\(vbansal\)=22=20 |Subject:Re=3A=20draft-ietf-l2vpn-ipls-06.txt=20(Vinit=20Bansal); X=v=3Dcisco.com=3B=20h=3DJJdB5dR5csGvTivhhZdlcac6gNA=3D; b=Aso3JERpKkYRmmhZhHRSXiidF1R2XSbSoIrurq9EIIcNIMNwvQb7LG3f4zyINwh7NQYDxFkg j5V7+MOQR3VI8KYyrnZxt26HZnlKV25wpA0pfdo/cWrWWkA/RSzhbteK; Authentication-Results: sj-dkim-1.cisco.com; header.From=vbansal@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Re: draft-ietf-l2vpn-ipls-06.txt (Vinit Bansal) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C69951.B2F850BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question on the CE auto discovery. If the CE is configured with static ARP entries,=20 then, the CE discovery will not happen and the PE router will keep dropping the IP unknown=20 unicast packets. =20 During the discovery phase, the PE router should punt the IP unicast packets to control plane=20 for CE discovery. =20 Thanks Vinit Bansal vbansal@cisco.com ------_=_NextPart_001_01C69951.B2F850BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have a question on the CE auto = discovery.=20 If the CE is configured with static ARP entries,
then, = the CE=20 discovery will not happen and the PE router will keep dropping the IP = unknown=20
unicast=20 packets.
 
During the discovery phase, the PE = router=20 should punt the IP unicast packets to control plane=20
for CE discovery.
 
Thanks
Vinit=20 Bansal
vbansal@cisco.com
------_=_NextPart_001_01C69951.B2F850BF-- From l2vpn-bounces@ietf.org Mon Jun 26 15:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwpN-0007Q8-OB; Mon, 26 Jun 2006 15:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwpM-0007Px-Iu; Mon, 26 Jun 2006 15:32:56 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwpL-0005yH-BI; Mon, 26 Jun 2006 15:32:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5QJWbWR001256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 19:32:37 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuwp3-0001pH-9N; Mon, 26 Jun 2006 15:32:37 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 26 Jun 2006 15:32:37 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: l2vpn mailing list , l2vpn chair , Internet Architecture Board , l2vpn chair , RFC Editor Subject: Protocol Action: 'Virtual Private LAN Services Using LDP' to Proposed Standard 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 The IESG has approved the following document: - 'Virtual Private LAN Services Using LDP ' as a Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt Technical Summary The service described in this document, the Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, offers a variant of a Layer 2 Virtual Private Network (L2VPN). In the case of VPLS, a multipoint network connects the VPN customers, in contrast to the more traditional Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, mechanisms for signaling a VPLS, and rules for forwarding and learning from VPLS frames across a packet switched network, how to separate traffic in different VPN and to de-multiplex traffic at the PE routers. The VPLS-LDP is agnostic when it comes to discovery of VPLS end-points. Working Group Summary The VPLS solutions have been one of the controversies of the VPN working groups. There have been two sets of solutions and much arguing on the relative merits of these solutions. An agreement was reached that it is not really the choice of signaling protocol that is the major difference between the LDP and BGP based solutions, but the kind of environment they are targeted for. VPLS-LDP targets networks (e.g., metro) where BGP is typically not run or LDP is used for other L2VPNs (e.g., VPWS). On the other hand, VPLS-BGP targets those networks where L3VPNs using BGP are also deployed. The VPLS-BGP has been through a number of reviews, including reviews in the l2vpn working group and the idr group. The same type of review has been done for vpls-ldp from the l2vpn and mpls working groups. Protocol Quality The protocol is implemented and deployed. A fair number of vendors have implemented the spec. The number of deployments is large. We have not had any reviewer standing up and saying that there is any need for major rework. Note to RFC Editor Please add a normative reference to RFC 2119 and cite it in section 1. Please retitle this document as: Virtual Private LAN Service (VPLS) using LDP Signaling IESG Note The L2VPN Working Group produced two separate documents, [RFC-draft-ietf-l2vpn-vpls-ldp] and [RFC-draft-ietf-l2vpn-vpls-bgp], that perform similar functions using different signaling protocols. Be aware that each method is commonly referred to as "VPLS" even though they are distinct and incompatible with one another. From l2vpn-bounces@ietf.org Mon Jun 26 16:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxLK-00062T-SZ; Mon, 26 Jun 2006 16:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxL8-0005VT-DV; Mon, 26 Jun 2006 16:05:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxL8-0001wG-At; Mon, 26 Jun 2006 16:05:46 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuxL6-0004TF-Uh; Mon, 26 Jun 2006 16:05:46 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QJo1jx020720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fux5t-00059q-EA; Mon, 26 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-02.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Requirements for Multicast Support in Virtual Private LAN Services Author(s) : Y. Kamite, et al. Filename : draft-ietf-l2vpn-vpls-mcast-reqts-02.txt Pages : 28 Date : 2006-6-26 This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-02.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-vpls-mcast-reqts-02.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-vpls-mcast-reqts-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-26105519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast-reqts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26105519.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Mon Jun 26 18:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzOw-0007ks-Dh; Mon, 26 Jun 2006 18:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzOu-0007hE-Oo; Mon, 26 Jun 2006 18:17:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzOu-0005IA-Mw; Mon, 26 Jun 2006 18:17:48 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuzOs-0007Gr-R5; Mon, 26 Jun 2006 18:17:48 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMGUjx024227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 22:16:30 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FuzNe-0005KG-Ji; Mon, 26 Jun 2006 18:16:30 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 26 Jun 2006 18:16:30 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: l2vpn mailing list , l2vpn chair , Internet Architecture Board , l2vpn chair , RFC Editor Subject: Document Action: 'Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks' to Informational RFC 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 The IESG has approved the following document: - 'Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks ' as an Informational RFC This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-07.txt Technical Summary This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. Working Group Summary There was little controversy in creation of L2VPN requirements. Protocol Quality Thomas Narten, when acting as co-chair of the Internet Area, has reviewed the I-D and provided valuable input to improve the quality of the document. The document was also reviewed by Mark Townsley. A significant number of vendors have implemented, and a large number of SP's have deployed, L2VPN protocols based on requirements contained within this document. From l2vpn-bounces@ietf.org Mon Jun 26 18:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzuf-0005fj-93; Mon, 26 Jun 2006 18:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzu6-0004Ot-TD; Mon, 26 Jun 2006 18:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzu6-0007eR-Dl; Mon, 26 Jun 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo1WR010144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu5-0007zv-UV; Mon, 26 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-06.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 : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : H. Shah, et al. Filename : draft-ietf-l2vpn-arp-mediation-06.txt Pages : 20 Date : 2006-6-26 The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudo-wire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudo-wire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudo-wire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. In particular, the applicability of ARP mediation to ISIS is not addressed as IS-IS PDUs are not sent over IP. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-06.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-arp-mediation-06.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-arp-mediation-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-26163845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-arp-mediation-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-arp-mediation-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26163845.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Jun 27 19:48:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNHr-0008CB-Ep; Tue, 27 Jun 2006 19:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNHX-0007CO-TJ; Tue, 27 Jun 2006 19:47:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMWY-0006PJ-A4; Tue, 27 Jun 2006 18:59:14 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvMNe-0007KL-8K; Tue, 27 Jun 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5RMo1UA006436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvMNd-0005rM-HN; Tue, 27 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-oam-req-frmk-06.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-06.txt Pages : 36 Date : 2006-6-27 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-06.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-06.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-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27152423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-oam-req-frmk-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-oam-req-frmk-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27152423.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Thu Jun 29 22:24:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8fi-0000ji-Kb; Thu, 29 Jun 2006 22:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8fg-0000dj-6T for l2vpn@ietf.org; Thu, 29 Jun 2006 22:23:52 -0400 Received: from mgw2.noc.ntt.com ([210.160.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw8fd-0000vX-GA for l2vpn@ietf.org; Thu, 29 Jun 2006 22:23:52 -0400 Received: from mop3.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id k5U2NlxZ017313 for ; Fri, 30 Jun 2006 11:23:47 +0900 (JST) Received: from mip1.noc.ntt.com (mvi3.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0J1N0069UINNEF@ntt.com> for l2vpn@ietf.org; Fri, 30 Jun 2006 11:23:47 +0900 (JST) Date: Fri, 30 Jun 2006 11:23:47 +0900 From: "Yuji KAMITE" To: l2vpn@ietf.org Message-id: <0J1N00GQBINNYO@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcaZXAgvUyptLud8TRC1XPPQYILJjwCjpbCw X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: FW: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-02.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Dear l2vpn WG, This is just a quick note for updating this. We added two new sections, though on the whole it gets fairly stable. ------ Change log: Setction 5.9. "Frame reordering prevention" (new section) Section 5.10. "Fate-Sharing between unicast and multicast" (new section) - Reflected the result of discussion in the last Dallas meeting. Originally, it was pointed out in connection with the path-congruency topic, but it was suggested that it should be clarified first in the context of fate-sharing in the requirement document. So this section shows an optional requirement taking care of customer's LAN switching application. Section 6.5. Some items raised requirement level from SHOULD to MUST. Editorial changes ------ Thanks, -Yuji -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, June 27, 2006 4:50 AM To: i-d-announce@ietf.org Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-reqts-02.txt 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 : Requirements for Multicast Support in Virtual Private LAN Services Author(s) : Y. Kamite, et al. Filename : draft-ietf-l2vpn-vpls-mcast-reqts-02.txt Pages : 28 Date : 2006-6-26 This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-02.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-vpls-mcast-reqts-02.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-vpls-mcast-reqts-02.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.