From nabil.n.bitar@verizon.com Mon Feb 3 10:10:19 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B364E1A01CE for ; Mon, 3 Feb 2014 10:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5FIrTjuN1Hr for ; Mon, 3 Feb 2014 10:10:18 -0800 (PST) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id D329C1A01C9 for ; Mon, 3 Feb 2014 10:10:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe02.verizonbusiness.com with ESMTP; 03 Feb 2014 18:10:17 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.95,773,1384300800"; d="scan'208";a="644151384" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi02.verizon.com with ESMTP; 03 Feb 2014 18:10:17 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Mon, 3 Feb 2014 13:10:16 -0500 To: "l2vpn@ietf.org" Importance: high X-Priority: 1 Date: Mon, 3 Feb 2014 13:10:16 -0500 Subject: FW: Please respond to the IPR call on the l2vpn mac flush optimization to move forward Thread-Topic: Please respond to the IPR call on the l2vpn mac flush optimization to move forward Thread-Index: Ac8hCzCXc1bLkxAASdaLGyVRnw6mTg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 18:10:19 -0000 RllJLg0KDQpPbiAxLzE3LzE0IDg6MzEgUE0sICJGbG9yaW4gQmFsdXMiIDxmbG9yaW5AbnVhZ2Vu ZXR3b3Jrcy5uZXQ+IHdyb3RlOg0KDQo+SSBhbSBub3QgYXdhcmUgb2YgYW55IGFwcGxpY2FibGUg SVBSLg0KPg0KPk9uIDEvMTcvMTQsIDM6NTkgUE0sICJCaXRhciwgTmFiaWwgTiIgPG5hYmlsLm4u Yml0YXJAdmVyaXpvbi5jb20+IHdyb3RlOg0KPg0KPj5JIG1pc3NlZCB5b3UgUHJhbmphbCBvbiB0 aGUgZmlyc3QgZW1haWwuIFBsZWFzZSwgc2VlIGJlbG93Lg0KPj4NCj4+VGhhbmtzLA0KPj5OYWJp bA0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkZyb206IEJp dGFyLCBOYWJpbCBODQo+PlNlbnQ6IEZyaWRheSwgSmFudWFyeSAxNywgMjAxNCA2OjU3IFBNDQo+ PlRvOiBnZXJhbGRpbmUuY2FsdmlnbmFjQG9yYW5nZS1mdGdyb3VwLmNvbTsgZmxvcmluQG51YWdl bmV0d29ya3MubmV0Ow0KPj5HaWxlcyBIZXJvbg0KPj5DYzogRmVkeWssIERvbjsgR2lsZXMgSGVy b24gKGdpaGVyb25AY2lzY28uY29tKQ0KPj5TdWJqZWN0OiBQbGVhc2UgcmVzcG9uZCB0byB0aGUg SVBSIGNhbGwgb24gdGhlIGwydnBuIG1hYyBmbHVzaA0KPj5vcHRpbWl6YXRpb24gdG8gbW92ZSBm b3J3YXJkDQo+Pg0KPj5IaSwNCj4+DQo+PlBsZWFzZSwgcmVzcG9uZCB0byB0aGUgaW5pdGlhbCBJ UFIgY2FsbCBiZWxvdyBieSByZXBseWluZyB0byBhbGwsDQo+PmVuc3VyaW5nIHRoYXQgdGhlIG1l c3NhZ2UgaXMgc2VudCB0byB0aGUgbDJ2cG4gV0cgbGlzdC4gV2UgY2Fubm90IG1vdmUNCj4+Zm9y d2FyZCB1bnRpbCB3ZSBoZWFyIGZyb20gYWxsIGF1dGhvcnMuDQo+Pg0KPj5UaGFua3MsDQo+Pk5h YmlsDQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+RnJvbTog RmVkeWssIERvbiBbZG9uLmZlZHlrQGhwLmNvbV0NCj4+U2VudDogVHVlc2RheSwgSmFudWFyeSAw NywgMjAxNCAxMDoyOSBBTQ0KPj5UbzogQml0YXIsIE5hYmlsIE47IGwydnBuQGlldGYub3JnDQo+ PkNjOiBvc3Rva2VzQGV4dHJlbWVuZXR3b3Jrcy5jb207IEJhbHVzLCBGbG9yaW4gU3RlbGlhbiAo RmxvcmluKTsgR2lsZXMNCj4+SGVyb24NCj4+U3ViamVjdDogUkU6IFtsMnZwbl0gUG9sbGluZyBm b3IgSVBSIG9uDQo+PmRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0wOQ0KPj4NCj4+ SGkNCj4+San2bSBub3QgYXdhcmUgb2YgYW55IGFwcGxpY2FibGUgSVBSLg0KPj4NCj4+UmVnYXJk cywNCj4+RG9uDQo+Pg0KPj5Gcm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCaXRhciwgTmFiaWwgTg0KPj5TZW50OiBNb25kYXksIEphbnVhcnkg MDYsIDIwMTQgNzoxMCBBTQ0KPj5UbzogbDJ2cG5AaWV0Zi5vcmcNCj4+Q2M6IG9zdG9rZXNAZXh0 cmVtZW5ldHdvcmtzLmNvbTsgQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBHaWxlcw0K Pj5IZXJvbg0KPj5TdWJqZWN0OiBbbDJ2cG5dIFBvbGxpbmcgZm9yIElQUiBvbiBkcmFmdC1pZXRm LWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDkNCj4+DQo+PkhpLA0KPj4NCj4+V2UgYXJlIHBvbGxp bmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0bw0KPj5kcmFmdC1pZXRm LWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDkudHh0LCBMRFAgRXh0ZW5zaW9ucyBmb3IgT3B0aW1p emVkDQo+Pk1BQyBBZGRyZXNzIFdpdGhkcmF3YWwgaW4gSC1WUExTLCBpbiBvcmRlciB0byBlbnN1 cmUgdGhhdCBJUFIgaGFzIGJlZW4NCj4+ZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OQ0KPj5hbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKS4NCj4+DQo+PklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9y LCAgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbA0KPj53aGV0aGVyIG9yIG5vdCB5b3UgYXJl IGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXMgbm90IGJlZW4NCj4+cHJvcGVybHkg ZGlzY2xvc2VkLiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNl IGhhcw0KPj5iZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0K Pj4NCj4+SWYgeW91IGFyZSBvbiB0aGUgbDJ2cG4gV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBs aXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQo+PmNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNp dGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPj5JUFIgdGhhdCBoYXMg bm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuIFRo ZQ0KPj5kcmFmdCBjYW4gYmUgZm91bmQgYXQNCj4+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTA5DQo+Pg0KPj5UaGlzIHBvbGwgY2xv c2VzIG9uIE1vbmRheSBKYW51YXJ5IDEzLCAyMDE0Lg0KPj4NCj4+VGhhbmtzLA0KPj5OYWJpbCAm IEdpbGVzDQo+DQo+DQoNCg== From internet-drafts@ietf.org Fri Feb 7 10:11:52 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9DA1ACCF6; Fri, 7 Feb 2014 10:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiL5NNEn12s6; Fri, 7 Feb 2014 10:11:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DABEC1ACCE7; Fri, 7 Feb 2014 10:11:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-evpn-req-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207181150.30586.29469.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 10:11:50 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 18:11:52 -0000 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 Ethernet VPN (EVPN) Authors : Ali Sajassi Rahul Aggarwal Nabil Bitar Aldrin Isaac Filename : draft-ietf-l2vpn-evpn-req-07.txt Pages : 16 Date : 2014-02-07 Abstract: The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution which addresses the above issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn-req/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-evpn-req-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Feb 8 07:32:48 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290AD1A03D7; Sat, 8 Feb 2014 07:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r86HYTOwErmU; Sat, 8 Feb 2014 07:32:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D25E1A03A8; Sat, 8 Feb 2014 07:32:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-inter-domain-redundancy-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140208153246.6729.34678.idtracker@ietfa.amsl.com> Date: Sat, 08 Feb 2014 07:32:46 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 15:32:48 -0000 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 : Redundancy provisioning for VPLS Inter-domain Authors : Zhihua Liu Lizhong Jin Ran Chen Dennis Cai Samer Salam Filename : draft-ietf-l2vpn-vpls-inter-domain-redundancy-04.txt Pages : 11 Date : 2014-02-08 Abstract: In many existing Virtual Private LAN Service (VPLS) deployments based on RFC4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC4762 with node and link redundancy in both domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-inter-domain-redundancy-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nabil.n.bitar@verizon.com Sun Feb 9 07:26:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EC81A06D9 for ; Sun, 9 Feb 2014 07:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBUohphv29uv for ; Sun, 9 Feb 2014 07:26:07 -0800 (PST) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 224261A06D1 for ; Sun, 9 Feb 2014 07:26:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 09 Feb 2014 15:26:06 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.95,812,1384300800"; d="scan'208";a="649478780" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi03.verizon.com with ESMTP; 09 Feb 2014 15:26:06 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.226]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Sun, 9 Feb 2014 10:26:06 -0500 To: "l2vpn@ietf.org" Date: Sun, 9 Feb 2014 10:22:50 -0500 Subject: Note: IETF 89 (London) Draft submission date for all drafts is on Friday 2/14/2014 Thread-Topic: Note: IETF 89 (London) Draft submission date for all drafts is on Friday 2/14/2014 Thread-Index: AQHPJarLG66biIk8AESYGQfhT49JMA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Giles Heron \(giheron@cisco.com\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 15:26:08 -0000 Hi, Please note that for this IETF the draft submission date is on Friday rathe= r than the usual Monday. It is on Friday 2/14/2014 per the agenda item belo= w. 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 23:59, upload using IETF ID Submission Tool. Thanks, Nabil= From nabil.n.bitar@verizon.com Sun Feb 9 07:36:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0F31A06DC for ; Sun, 9 Feb 2014 07:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lx-DAM2-yQI for ; Sun, 9 Feb 2014 07:36:07 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 195401A0105 for ; Sun, 9 Feb 2014 07:36:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 09 Feb 2014 15:36:07 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.95,812,1384300800"; d="scan'208";a="648682321" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi02.verizon.com with ESMTP; 09 Feb 2014 15:36:07 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.226]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Sun, 9 Feb 2014 10:36:06 -0500 To: "l2vpn@ietf.org" Date: Sun, 9 Feb 2014 10:36:06 -0500 Subject: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Topic: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Index: AQHPJayZuz0FE/lI5kixMOf778YlZA== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 15:36:08 -0000 Hi L2VPN WG, If you would like to request a time-slot for the L2VPN WG session at IETF 8= 9-London, please reply to us by Friday 2/14/2014 along with the following i= nformation: 1) Draft title 2) Presenter name 3) Requested duration Please, make sure that the subject of you reply is: Re:[l2vpn] L2VPN Age= nda Slot Call for IETF 89 =96 London (i.e., reply to this email and the WG = chairs and secretary (Andrew)) Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter. Please also note the following cutoff date for draft submission. This date = applies to new 00 drafts and updated drafts. 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 23:59, upload using IETF ID Submission Tool. Thanks, Nabil From nabil.n.bitar@verizon.com Sun Feb 9 14:24:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714271A060F for ; Sun, 9 Feb 2014 14:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtQGyN7oJTXk for ; Sun, 9 Feb 2014 14:24:44 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 26F171A0612 for ; Sun, 9 Feb 2014 14:24:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 09 Feb 2014 22:24:43 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.95,814,1384300800"; d="scan'208";a="667670161" Received: from fldp1lumxc7hb04.verizon.com (HELO FLDP1LUMXC7HB04.us.one.verizon.com) ([166.68.75.83]) by fldsmtpi01.verizon.com with ESMTP; 09 Feb 2014 22:24:43 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.226]) by FLDP1LUMXC7HB04.us.one.verizon.com ([166.68.75.83]) with mapi; Sun, 9 Feb 2014 17:24:43 -0500 To: "l2vpn@ietf.org" Date: Sun, 9 Feb 2014 17:24:42 -0500 Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Index: AQHPJeW6QRCH2EZWg0ChrZwysR2dEA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 22:24:46 -0000 Hi, This is an extension of the working group last call on the draft "A Framewo= rk for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching = (MPLS) Network". The draft can be found at http://tools.ietf.org/html/draf= t-ietf-l2vpn-etree-frwk-04. There was no response to an earlier call, and we want to ensure that people= are paying attention. There were quite few edits from the earlier draft ve= rsion. Please, review the draft and send any comments to the L2VPN working group e= mail list by responding to this email. Please, indicate your support for mo= ving this draft forward or any objection you might have.=20 This extended WG last call will close on Monday February 17, 2014. Regards, Nabil & Giles From wim.henderickx@alcatel-lucent.com Sun Feb 9 22:03:47 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0FE1A0798 for ; Sun, 9 Feb 2014 22:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9lPzRYib2e5 for ; Sun, 9 Feb 2014 22:03:45 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 363C51A04C6 for ; Sun, 9 Feb 2014 22:03:44 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1A63gMk022987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 00:03:43 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1A63fuA001860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 07:03:41 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.30]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 07:03:41 +0100 From: "Henderickx, Wim (Wim)" To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Index: AQHPJeW6QRCH2EZWg0ChrZwysR2dEJqt/+OA Date: Mon, 10 Feb 2014 06:03:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <5124C77DFD6D2B4C939D17525A67F411@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 06:03:47 -0000 support On 09/02/14 23:24, "Bitar, Nabil N" wrote: >Hi, >This is an extension of the working group last call on the draft "A >Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label >Switching (MPLS) Network". The draft can be found at >http://tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-04. > >There was no response to an earlier call, and we want to ensure that >people are paying attention. There were quite few edits from the earlier >draft version. > >Please, review the draft and send any comments to the L2VPN working group >email list by responding to this email. Please, indicate your support for >moving this draft forward or any objection you might have. > >This extended WG last call will close on Monday February 17, 2014. > >Regards, >Nabil & Giles From raymond.key@hotmail.com Sun Feb 9 22:29:31 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD1E1A07B0 for ; Sun, 9 Feb 2014 22:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1wdAht_nKea for ; Sun, 9 Feb 2014 22:29:29 -0800 (PST) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id 001F91A069B for ; Sun, 9 Feb 2014 22:29:28 -0800 (PST) Received: from BLU175-W49 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Feb 2014 22:29:28 -0800 X-TMN: [e7Du9W/4G+DBTG3Jh04rUOvD/J8buZ6XPndwdPUO80w=] X-Originating-Email: [raymond.key@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_dcc2a6ff-6d4b-4b28-ae29-ea2963c27621_" From: Raymond Key Sender: To: , Subject: RE: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Date: Mon, 10 Feb 2014 17:29:28 +1100 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2014 06:29:28.0653 (UTC) FILETIME=[734637D0:01CF2629] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 06:29:31 -0000 --_dcc2a6ff-6d4b-4b28-ae29-ea2963c27621_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support > From: nabil.n.bitar@verizon.com > To: l2vpn@ietf.org > Date: Sun=2C 9 Feb 2014 17:24:42 -0500 > Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree = framework) - extended. Please=2C provide comments=2C and indicate objection= or support for moving this draft forward >=20 > Hi=2C > This is an extension of the working group last call on the draft "A Frame= work for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switchin= g (MPLS) Network". The draft can be found at http://tools.ietf.org/html/dr= aft-ietf-l2vpn-etree-frwk-04. >=20 > There was no response to an earlier call=2C and we want to ensure that pe= ople are paying attention. There were quite few edits from the earlier draf= t version. >=20 > Please=2C review the draft and send any comments to the L2VPN working gro= up email list by responding to this email. Please=2C indicate your support = for moving this draft forward or any objection you might have.=20 >=20 > This extended WG last call will close on Monday February 17=2C 2014. >=20 > Regards=2C > Nabil & Giles = --_dcc2a6ff-6d4b-4b28-ae29-ea2963c27621_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Support

> From:=3B nab= il.n.bitar@=3Bverizon.com
> To:=3B l2vpn@=3Bietf.org
> Date&= #58=3B Sun=2C 9 Feb 2014 17:=3B24:=3B42 -0500
> Subject:=3B = 1=3Bl2vpn]=3B WG last call for draft-ietf-l2vpn-etree-frwk-04 (=3Bet= ree framework)=3B - extended. Please=2C provide comments=2C and indicate= objection or support for moving this draft forward
>
> Hi=2C
> T= his is an extension of the working group last call on the draft "=3BA Fr= amework for Ethernet Tree (=3BE-Tree)=3B Service over a Multiprotocol= Label Switching (=3BMPLS)=3B Network"=3B. The draft can be found= at http:=3B//tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-04.
> <= br>> There was no response to an earlier call=2C and we want to ensure that= people are paying attention. There were quite few edits from the earlier d= raft version.
>
> Please=2C review the draft and send any comments t= o the L2VPN working group email list by responding to this email. Please=2C= indicate your support for moving this draft forward or any objection you m= ight have.
>
> This extended WG last call will close on Monday Febr= uary 17=2C 2014.
>
> Regards=2C
> Nabil &=3B Giles
=
= --_dcc2a6ff-6d4b-4b28-ae29-ea2963c27621_-- From andrew.dolganow@alcatel-lucent.com Mon Feb 10 18:07:48 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979561A065F for ; Mon, 10 Feb 2014 18:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCesrRX1Iub2 for ; Mon, 10 Feb 2014 18:07:46 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D122A1A0724 for ; Mon, 10 Feb 2014 18:07:45 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1B27ius017569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 20:07:45 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s1B27il0000677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 21:07:44 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.71]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 21:07:44 -0500 From: "Dolganow, Andrew (Andrew)" To: "Henderickx, Wim (Wim)" , "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Index: AQHPJeW6QRCH2EZWg0ChrZwysR2dEJqt/+OAgAJcpYA= Date: Tue, 11 Feb 2014 02:07:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:07:49 -0000 support On 2/10/2014, 5:03 PM, "Henderickx, Wim (Wim)" wrote: >support > >On 09/02/14 23:24, "Bitar, Nabil N" wrote: > >>Hi, >>This is an extension of the working group last call on the draft "A >>Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label >>Switching (MPLS) Network". The draft can be found at >>http://tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-04. >> >>There was no response to an earlier call, and we want to ensure that >>people are paying attention. There were quite few edits from the earlier >>draft version. >> >>Please, review the draft and send any comments to the L2VPN working group >>email list by responding to this email. Please, indicate your support for >>moving this draft forward or any objection you might have. >> >>This extended WG last call will close on Monday February 17, 2014. >> >>Regards, >>Nabil & Giles > From shares@ndzh.com Mon Feb 10 18:34:21 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF881A0734 for ; Mon, 10 Feb 2014 18:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUJrPvTY3PL4 for ; Mon, 10 Feb 2014 18:34:19 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 69E201A0724 for ; Mon, 10 Feb 2014 18:34:19 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Bitar, Nabil N'" , References: In-Reply-To: Subject: RE: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Date: Mon, 10 Feb 2014 21:34:12 -0500 Message-ID: <013601cf26d1$c0c21940$42464bc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGoWFZ1bO/OlZMedUpfzepsYyczWQKGFzATAcuXDnaa2mTvsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:34:21 -0000 Support. Sue Hares ----- >>Hi, >>This is an extension of the working group last call on the draft "A >>Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol >>Label Switching (MPLS) Network". The draft can be found at >>http://tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-04. >> >>There was no response to an earlier call, and we want to ensure that >>people are paying attention. There were quite few edits from the >>earlier draft version. >> >>Please, review the draft and send any comments to the L2VPN working >>group email list by responding to this email. Please, indicate your >>support for moving this draft forward or any objection you might have. >> >>This extended WG last call will close on Monday February 17, 2014. >> >>Regards, >>Nabil & Giles > From lizhenbin@huawei.com Mon Feb 10 19:01:14 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE701A0760 for ; Mon, 10 Feb 2014 19:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdNKAtOChJDe for ; Mon, 10 Feb 2014 19:01:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C60FC1A0733 for ; Mon, 10 Feb 2014 19:01:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL49002; Tue, 11 Feb 2014 03:01:12 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 03:00:16 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 03:01:10 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 11:01:06 +0800 From: Lizhenbin To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: =?gb2312?B?tPC4tDogW2wydnBuXSAgV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLWwy?= =?gb2312?B?dnBuLWV0cmVlLWZyd2stMDQgKGV0cmVlIGZyYW1ld29yaykgLSBleHRlbmRl?= =?gb2312?B?ZC4gUGxlYXNlLCBwcm92aWRlIGNvbW1lbnRzLCBhbmQgaW5kaWNhdGUgb2Jq?= =?gb2312?Q?ection_or_support_for_moving_this_draft_forward?= Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Index: AQHPJeW6QRCH2EZWg0ChrZwysR2dEJqvXzDQ Date: Tue, 11 Feb 2014 03:01:05 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA06E@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 03:01:14 -0000 U3VwcG9ydC4NCg0KDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEwydnBuIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6 IDIwMTTE6jLUwjEwyNUgNjoyNQ0KytW8/sjLOiBsMnZwbkBpZXRmLm9yZw0K1vfM4jogW2wydnBu XSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtbDJ2cG4tZXRyZWUtZnJ3ay0wNCAoZXRyZWUg ZnJhbWV3b3JrKSAtIGV4dGVuZGVkLiBQbGVhc2UsIHByb3ZpZGUgY29tbWVudHMsIGFuZCBpbmRp Y2F0ZSBvYmplY3Rpb24gb3Igc3VwcG9ydCBmb3IgbW92aW5nIHRoaXMgZHJhZnQgZm9yd2FyZA0K DQpIaSwNClRoaXMgaXMgYW4gZXh0ZW5zaW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbiB0aGUgZHJhZnQgIkEgRnJhbWV3b3JrIGZvciBFdGhlcm5ldCBUcmVlIChFLVRyZWUpIFNl cnZpY2Ugb3ZlciBhIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSBOZXR3b3Jr Ii4gIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1sMnZwbi1ldHJlZS1mcndrLTA0Lg0KDQpUaGVyZSB3YXMgbm8gcmVzcG9uc2Ug dG8gYW4gZWFybGllciBjYWxsLCBhbmQgd2Ugd2FudCB0byBlbnN1cmUgdGhhdCBwZW9wbGUgYXJl IHBheWluZyBhdHRlbnRpb24uIFRoZXJlIHdlcmUgcXVpdGUgZmV3IGVkaXRzIGZyb20gdGhlIGVh cmxpZXIgZHJhZnQgdmVyc2lvbi4NCg0KUGxlYXNlLCByZXZpZXcgdGhlIGRyYWZ0IGFuZCBzZW5k IGFueSBjb21tZW50cyB0byB0aGUgTDJWUE4gd29ya2luZyBncm91cCBlbWFpbCBsaXN0IGJ5IHJl c3BvbmRpbmcgdG8gdGhpcyBlbWFpbC4gUGxlYXNlLCBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgZm9y IG1vdmluZyB0aGlzIGRyYWZ0IGZvcndhcmQgb3IgYW55IG9iamVjdGlvbiB5b3UgbWlnaHQgaGF2 ZS4gDQoNClRoaXMgZXh0ZW5kZWQgV0cgbGFzdCBjYWxsIHdpbGwgY2xvc2Ugb24gTW9uZGF5IEZl YnJ1YXJ5IDE3LCAyMDE0Lg0KDQpSZWdhcmRzLA0KTmFiaWwgJiBHaWxlcw0K From ravis@juniper.net Tue Feb 11 12:11:36 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591441A0711 for ; Tue, 11 Feb 2014 12:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1_SUtN6bIfZ for ; Tue, 11 Feb 2014 12:11:33 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E01A06F4 for ; Tue, 11 Feb 2014 12:11:33 -0800 (PST) Received: from mail79-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Tue, 11 Feb 2014 20:11:33 +0000 Received: from mail79-tx2 (localhost [127.0.0.1]) by mail79-tx2-R.bigfish.com (Postfix) with ESMTP id 143D53A03B2 for ; Tue, 11 Feb 2014 20:11:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL17326ah8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail79-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ravis@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(74366001)(54316002)(76482001)(56776001)(92566001)(51856001)(54356001)(53806001)(76176001)(77096001)(76786001)(81542001)(79102001)(76576001)(66066001)(4396001)(80022001)(33646001)(50986001)(47736001)(49866001)(47976001)(65816001)(95666001)(74876001)(74706001)(63696002)(46102001)(74316001)(81686001)(59766001)(77982001)(81342001)(81816001)(87266001)(31966008)(85306002)(94316002)(83072002)(85852003)(83322001)(95416001)(87936001)(56816005)(90146001)(19580395003)(2656002)(76796001)(575784001)(15202345003)(93516002)(74502001)(94946001)(47446002)(69226001)(93136001)(74662001)(86362001)(15975445006)(80976001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB554; H:CO1PR05MB457.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:6E1BD90A.8CF2D988.B9DD6197.15048F51.20883; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail79-tx2 (localhost.localdomain [127.0.0.1]) by mail79-tx2 (MessageSwitch) id 1392149490239952_15384; Tue, 11 Feb 2014 20:11:30 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.232]) by mail79-tx2.bigfish.com (Postfix) with ESMTP id 2B4AB1C005F for ; Tue, 11 Feb 2014 20:11:30 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 11 Feb 2014 20:11:29 +0000 Received: from CO2PR05MB554.namprd05.prod.outlook.com (10.141.196.141) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 11 Feb 2014 20:11:27 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO2PR05MB554.namprd05.prod.outlook.com (10.141.196.141) with Microsoft SMTP Server (TLS) id 15.0.873.15; Tue, 11 Feb 2014 20:11:25 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com ([169.254.4.60]) by CO1PR05MB457.namprd05.prod.outlook.com ([169.254.4.60]) with mapi id 15.00.0873.009; Tue, 11 Feb 2014 20:11:25 +0000 From: Ravi Singh To: "l2vpn@ietf.org" Subject: Requesting comments on draft-singh-l2vpn-bgp-vpls-control-flags-00 Thread-Topic: Requesting comments on draft-singh-l2vpn-bgp-vpls-control-flags-00 Thread-Index: Ac8nZWqEysjEG95BRbaHlupASwcMxA== Date: Tue, 11 Feb 2014 20:11:24 +0000 Message-ID: <37d22ea81547490a8d7f864be7c65b46@CO1PR05MB457.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 0119DC3B5E Content-Type: multipart/alternative; boundary="_000_37d22ea81547490a8d7f864be7c65b46CO1PR05MB457namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:11:36 -0000 --_000_37d22ea81547490a8d7f864be7c65b46CO1PR05MB457namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: I'd like to request comments from the WG in regards to http://tools.ietf.or= g/html/draft-singh-l2vpn-bgp-vpls-control-flags-00 Thanks Ravi --_000_37d22ea81547490a8d7f864be7c65b46CO1PR05MB457namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello:
I’d like to request comments from the WG in regards to http://tools.ietf.org/html/draft-singh-l2vpn-bgp-v= pls-control-flags-00 
 
Thanks
Ravi
 
 
 --_000_37d22ea81547490a8d7f864be7c65b46CO1PR05MB457namprd05pro_-- From wwwrun@rfc-editor.org Tue Feb 11 13:56:15 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C4C1A0785; Tue, 11 Feb 2014 13:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTk-Nzluu3og; Tue, 11 Feb 2014 13:56:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 681B91A0789; Tue, 11 Feb 2014 13:56:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D36DF7FC3AC; Tue, 11 Feb 2014 13:56:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7117 on Multicast in Virtual Private LAN Service (VPLS) From: rfc-editor@rfc-editor.org Message-Id: <20140211215606.D36DF7FC3AC@rfc-editor.org> Date: Tue, 11 Feb 2014 13:56:06 -0800 (PST) Cc: l2vpn@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:56:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7117 Title: Multicast in Virtual Private LAN Service (VPLS) Author: R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya Status: Standards Track Stream: IETF Date: February 2014 Mailbox: raggarwa_1@yahoo.com, y.kamite@ntt.com, lufang@microsoft.com, yakov@juniper.net, chaitk@yahoo.com Pages: 50 Characters: 126280 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-vpls-mcast-16.txt URL: http://www.rfc-editor.org/rfc/rfc7117.txt RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported. This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Tue Feb 11 20:26:12 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB19F1A0830; Tue, 11 Feb 2014 20:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuCgeyydfKH8; Tue, 11 Feb 2014 20:26:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D01A079B; Tue, 11 Feb 2014 20:26:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-ipls-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212042610.25184.14390.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 20:26:10 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 04:26:13 -0000 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) Authors : Himanshu Shah Eric Rosen Francois Le Faucheur Giles Heron Filename : draft-ietf-l2vpn-ipls-13.txt Pages : 31 Date : 2014-02-11 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-ipls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-ipls-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangyuanlong@huawei.com Tue Feb 11 22:28:55 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624201A07FF for ; Tue, 11 Feb 2014 22:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y54FhB0y3t8C for ; Tue, 11 Feb 2014 22:28:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 711371A07E9 for ; Tue, 11 Feb 2014 22:28:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDM67101; Wed, 12 Feb 2014 06:28:51 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 06:27:52 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 06:28:49 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.204]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 14:28:43 +0800 From: Jiangyuanlong To: "l2vpn@ietf.org" Subject: RE: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 Thread-Index: AQHPJ7usdowM14sFVEa65FsCx/kzrg== Date: Wed, 12 Feb 2014 06:28:42 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6D3F85@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:28:55 -0000 Support. Regards, Yuanlong ---------------------------------------------------------------------- Date: Sun, 9 Feb 2014 17:24:42 -0500 From: "Bitar, Nabil N" To: "l2vpn@ietf.org" Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi, This is an extension of the working group last call on the draft "A Framewo= rk for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching = (MPLS) Network". The draft can be found at http://tools.ietf.org/html/draf= t-ietf-l2vpn-etree-frwk-04. There was no response to an earlier call, and we want to ensure that people= are paying attention. There were quite few edits from the earlier draft ve= rsion. Please, review the draft and send any comments to the L2VPN working group e= mail list by responding to this email. Please, indicate your support for mo= ving this draft forward or any objection you might have.=20 This extended WG last call will close on Monday February 17, 2014. Regards, Nabil & Giles From rbonica@juniper.net Wed Feb 12 06:26:31 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE4A1A0333 for ; Wed, 12 Feb 2014 06:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PAj-JDi-nUr for ; Wed, 12 Feb 2014 06:26:29 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 905261A0389 for ; Wed, 12 Feb 2014 06:26:28 -0800 (PST) Received: from mail47-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Feb 2014 14:26:27 +0000 Received: from mail47-ch1 (localhost [127.0.0.1]) by mail47-ch1-R.bigfish.com (Postfix) with ESMTP id 5559880169; Wed, 12 Feb 2014 14:26:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI9371Ic89bh936eI542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail47-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(13464003)(377424004)(377454003)(479174003)(189002)(199002)(47976001)(50986001)(47736001)(49866001)(81542001)(74706001)(74876001)(4396001)(69226001)(81342001)(54356001)(77982001)(59766001)(76482001)(47446002)(74502001)(74662001)(31966008)(74366001)(46102001)(74316001)(51856001)(66066001)(53806001)(79102001)(63696002)(65816001)(77096001)(94946001)(93136001)(76796001)(76786001)(93516002)(94316002)(86362001)(95416001)(54316002)(56776001)(76576001)(83072002)(85852003)(90146001)(56816005)(95666001)(81686001)(92566001)(81816001)(80022001)(33646001)(83322001)(19580395003)(19580405001)(80976001)(87266001)(87936001)(2656002)(85306002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:FCDFF31F.ACC265D9.71EB0C7B.C4C0698F.20249; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail47-ch1 (localhost.localdomain [127.0.0.1]) by mail47-ch1 (MessageSwitch) id 1392215185620225_31521; Wed, 12 Feb 2014 14:26:25 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail47-ch1.bigfish.com (Postfix) with ESMTP id 885EDE0082; Wed, 12 Feb 2014 14:26:25 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 12 Feb 2014 14:26:25 +0000 Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Wed, 12 Feb 2014 14:26:25 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.873.15; Wed, 12 Feb 2014 14:26:22 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.179]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.179]) with mapi id 15.00.0873.009; Wed, 12 Feb 2014 14:26:22 +0000 From: Ronald Bonica To: "l2vpn@ietf.org" Subject: RE: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Topic: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Index: AQHPJayZuz0FE/lI5kixMOf778YlZJqw6h5QgADFmlA= Date: Wed, 12 Feb 2014 14:26:21 +0000 Message-ID: <56b58b3e99cd4cb7a6eccea9e92aac35@CO1PR05MB442.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 01208B1E18 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Giles Heron \(giheron\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:26:31 -0000 Rm9sa3MsDQoNClBsZWFzZSBjb25zaWRlciB0aGlzIHJlcXVlc3QgZm9yIGFnZW5kYSB0aW1lLiBB IG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxsIGJlIHBvc3RlZCB0b2RheSBhbmQgaXQgd2ls bCBjb250YWluIGEgc2VjdGlvbiByZWxldmFudCB0byBMMlZQTi4NCg0KDQoxKSBkcmFmdC1ib25p Y2EtbDN2cG4tb3JmLWNvdmVyaW5nLXByZWZpeGVzLTAxDQoyKSBSb24gQm9uaWNhDQozKSAxNSBt aW51dGVzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQog LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlCaXRhciwgTmFiaWwgTg0KU2VudDoJ U3VuZGF5LCBGZWJydWFyeSAwOSwgMjAxNCAxMDoyOSBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUN ClRvOglsMnZwbkBpZXRmLm9yZw0KQ2M6CUdpbGVzIEhlcm9uOyBhbWNsYWNobEBjaXNjby5jb20N ClN1YmplY3Q6CVtsMnZwbl0gTDJWUE4gQWdlbmRhIFNsb3QgQ2FsbCBmb3IgSUVURiA4OSAtIExv bmRvbg0KDQpIaSBMMlZQTiBXRywNCg0KSWYgeW91IHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIHRp bWUtc2xvdCBmb3IgdGhlIEwyVlBOIFdHIHNlc3Npb24gYXQgSUVURiA4OS1Mb25kb24sIHBsZWFz ZSByZXBseSB0byB1cyBieSBGcmlkYXkgMi8xNC8yMDE0IGFsb25nIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjoNCg0KMSkgRHJhZnQgdGl0bGUNCjIpIFByZXNlbnRlciBuYW1lDQozKSBS ZXF1ZXN0ZWQgZHVyYXRpb24NCg0KUGxlYXNlLCBtYWtlIHN1cmUgdGhhdCB0aGUgc3ViamVjdCBv ZiB5b3UgcmVwbHkgaXM6ICAgIFJlOltsMnZwbl0gTDJWUE4gQWdlbmRhIFNsb3QgQ2FsbCBmb3Ig SUVURiA4OSDigJMgTG9uZG9uIChpLmUuLCByZXBseSB0byB0aGlzIGVtYWlsIGFuZCB0aGUgV0cg Y2hhaXJzIGFuZCBzZWNyZXRhcnkgKEFuZHJldykpDQoNClBsZWFzZSBub3RlIHRoYXQgcHJpb3Jp dHkgd2lsbCBiZSBnaXZlbiB0byBkcmFmdHMgdGhhdCBhcmUgY2xlYXJseSB3aXRoaW4gdGhlIHNj b3BlIG9mIHRoZSBjdXJyZW50IEwyVlBOIGNoYXJ0ZXIuDQpQbGVhc2UgYWxzbyBub3RlIHRoZSBm b2xsb3dpbmcgY3V0b2ZmIGRhdGUgZm9yIGRyYWZ0IHN1Ym1pc3Npb24uIFRoaXMgZGF0ZSBhcHBs aWVzIHRvIG5ldyAwMCBkcmFmdHMgYW5kIHVwZGF0ZWQgZHJhZnRzLg0KDQoyMDE0LTAyLTE0IChG cmlkYXkpOiBJbnRlcm5ldCBEcmFmdCBzdWJtaXNzaW9uIGN1dC1vZmYgKGZvciBhbGwgZHJhZnRz LCBpbmNsdWRpbmcgLTAwKSBieSBVVEMgMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIElEIFN1Ym1p c3Npb24gVG9vbC4NCg0KVGhhbmtzLA0KTmFiaWwNCg== From ietf-ipr@ietf.org Wed Feb 12 09:11:45 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191B61A09B0; Wed, 12 Feb 2014 09:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlqITY9GCdfV; Wed, 12 Feb 2014 09:11:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8820A1A062C; Wed, 12 Feb 2014 09:11:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: mlasserre@lucent.com,vach.kompella@alcatel.com Subject: IPR Disclosure: Juniper's Statement of IPR related to RFC 4762 X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212171143.24678.77559.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 09:11:43 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:11:45 -0000 Dear Marc Lasserre, Vach Kompella: An IPR disclosure that pertains to your RFC entitled "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling" (RFC4762) was submitted to the IETF Secretariat on 2014-02-11 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2317/). The title of the IPR disclosure is "Juniper's Statement of IPR related to RFC 4762.""); The IETF Secretariat From ietf-ipr@ietf.org Wed Feb 12 09:14:56 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846061A0645; Wed, 12 Feb 2014 09:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOMq9NvJqytJ; Wed, 12 Feb 2014 09:14:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C11A047A; Wed, 12 Feb 2014 09:14:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: yakov@juniper.net,kireeti@juniper.net Subject: IPR Disclosure: Juniper's Statement of IPR related to RFC 4761 X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212171454.1383.23833.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 09:14:54 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:14:56 -0000 Dear Yakov Rekhter, Kireeti Kompella: An IPR disclosure that pertains to your RFC entitled "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling" (RFC4761) was submitted to the IETF Secretariat on 2014-02-11 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2318/). The title of the IPR disclosure is "Juniper's Statement of IPR related to RFC 4761.""); The IETF Secretariat From nobody Thu Feb 13 15:57:51 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCAA1A0518 for ; Thu, 13 Feb 2014 15:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GGbNP7vPT68 for ; Thu, 13 Feb 2014 15:57:40 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 977BA1A0509 for ; Thu, 13 Feb 2014 15:57:40 -0800 (PST) Received: from mail82-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 23:57:39 +0000 Received: from mail82-va3 (localhost [127.0.0.1]) by mail82-va3-R.bigfish.com (Postfix) with ESMTP id 0B2274E0132 for ; Thu, 13 Feb 2014 23:57:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(z579ehz936eIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail82-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(377424004)(87266001)(80022001)(65816001)(74316001)(87936001)(77096001)(95666001)(56816005)(92566001)(90146001)(83072002)(31966008)(76796001)(15975445006)(76576001)(76786001)(76176001)(85852003)(81686001)(81816001)(66066001)(2656002)(85306002)(74502001)(47446002)(69226001)(93136001)(33646001)(95416001)(86362001)(93516002)(94946001)(74706001)(81542001)(46102001)(54356001)(53806001)(15202345003)(51856001)(94316002)(54316002)(56776001)(76482001)(4396001)(49866001)(47736001)(50986001)(74876001)(47976001)(81342001)(59766001)(74366001)(74662001)(19580395003)(63696002)(79102001)(77982001)(83322001)(80976001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:7C1A793E.1DF42FCA.47FFBF7F.D0C318B0.20178; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail82-va3 (localhost.localdomain [127.0.0.1]) by mail82-va3 (MessageSwitch) id 1392335856440786_2169; Thu, 13 Feb 2014 23:57:36 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.240]) by mail82-va3.bigfish.com (Postfix) with ESMTP id 5C82A3001F0 for ; Thu, 13 Feb 2014 23:57:36 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 23:57:36 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 23:57:35 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 23:57:33 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.51]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.51]) with mapi id 15.00.0878.008; Thu, 13 Feb 2014 23:57:32 +0000 From: Ronald Bonica To: "l2vpn@ietf.org" Subject: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-01.txt Thread-Topic: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-01.txt Thread-Index: AQHPKRZrr26td+OsPk+fJ9YX2c1DVZqz3DPA Date: Thu, 13 Feb 2014 23:57:32 +0000 Message-ID: <17d179f8eabd465bace08ceea778f931@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/zLLROrjJSwxoDd9vA6iWftRk_5M X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:57:45 -0000 Rm9sa3MsDQoNClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuIFRoaXMgZHJhZnQgbm93IHRvdWNo ZXMgb24gTDJWUE4sIGFsc28uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib25pY2EtbDN2cG4tb3JmLWNvdmVy aW5nLXByZWZpeGVzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBS b24gQm9uaWNhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJpbmctcHJlZml4ZXMNClJldmlzaW9uOgkwMQ0KVGl0 bGU6CQlDb3ZlcmluZyBQcmVmaXhlcyBPdXRib3VuZCBSb3V0ZSBGaWx0ZXIgZm9yIEJHUC00DQpE b2N1bWVudCBkYXRlOgkyMDE0LTAyLTEzDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6CQkxNQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJpbmctcHJlZml4ZXMtMDEudHh0DQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9u aWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib25pY2EtbDN2cG4tb3JmLWNvdmVyaW5nLXByZWZp eGVzLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy0wMQ0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBPUkYtdHlwZSwgY2FsbGVkIHRoZSAiQ292 ZXJpbmcgUHJlZml4ZXMNCiAgIE9SRiAoQ1AtT1JGKSIuICBDUC1PUkYgaXMgYXBwbGljYWJsZSBp biBWaXJ0dWFsIEh1Yi1hbmQtU3Bva2UgVlBOcy4NCiAgIEl0IGFsc28gaXMgYXBwbGljYWJsZSBp biBCR1AvTVBMUyBFdGhlcm5ldCBWUE4gKEVWUE4pIE5ldHdvcmtzLg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQoNCg== From nobody Thu Feb 13 16:11:14 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2071A052F; Thu, 13 Feb 2014 16:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RDUPBUUDXoc; Thu, 13 Feb 2014 16:11:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1B91A0026; Thu, 13 Feb 2014 16:11:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-evpn-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214001110.27377.41608.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 16:11:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/4Mo100lrkqHEFdqNZH41Q7v2Vt0 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:11:12 -0000 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 : BGP MPLS Based Ethernet VPN Authors : Ali Sajassi Rahul Aggarwal Wim Henderickx Aldrin Isaac James Uttaro Filename : draft-ietf-l2vpn-evpn-05.txt Pages : 49 Date : 2014-02-13 Abstract: This document describes procedures for BGP MPLS based Ethernet VPNs (EVPN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-evpn-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 13 16:30:12 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE93A1A0010 for ; Thu, 13 Feb 2014 16:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHEcoUQVJXzc for ; Thu, 13 Feb 2014 16:30:07 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A55401A0006 for ; Thu, 13 Feb 2014 16:30:07 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-80-52fd638f4723 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B0.B1.11484.F836DF25; Fri, 14 Feb 2014 01:30:07 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 19:30:05 -0500 From: Jakob Heitz To: "l2vpn@ietf.org" Subject: RE: I-D Action: draft-ietf-l2vpn-evpn-05.txt Thread-Topic: I-D Action: draft-ietf-l2vpn-evpn-05.txt Thread-Index: AQHPKRlaBOeuoQN9AUW/blu0KCbkPZqz5Hlg Date: Fri, 14 Feb 2014 00:30:04 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F89932@eusaamb109.ericsson.se> References: <20140214001110.27377.41608.idtracker@ietfa.amsl.com> In-Reply-To: <20140214001110.27377.41608.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyuXRPoG5/8t8gg0XvxCwefzvE7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC/nbzAX7BKsuPPtFVMDY4NgFyMnh4SAicS024+ZIWwxiQv3 1rOB2EICRxglFu3w72LkArKXM0pM+/SNHSTBJqAj8e16F1ADB4eIgKrE7hYukLCwgKnEh3Nn GEFsEQEzieMPzrNC2EYSB9dvYQKxWYDKn628D2bzCvhK3Nl+ih1il6PE7b8PwXo5BZwkuncd AIszAt3z/dQasHpmAXGJW0/mM0HcKSCxZM95qJtFJV4+/scKYStJTFp6jhXkNGYBTYn1u/Qh WhUlpnQ/ZIdYKyhxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMXKUFqeW5aYbGW5iBIb8MQk2 xx2MCz5ZHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj3ktZGUZDccWS PxL3juz49sI15sCFz0XSzZ93R4iVJfaof14ew2CZwOh6+J1kunLp3YlON0JTnBnL/grUeF0X y+JKsF55eaP0eY7JDFqHu35tmV646PRBW373rO5Dczr1fxypd4lMk/7i9CEmnclL79KLb9Nt JhZyyi67Y1du7uX7smajykolluKMREMt5qLiRAA2QVwiRwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/k60Yz5vN0Iv6ZPBjTNr73xb4Sgo X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:30:10 -0000 VGhlIGRpZmYgaXMgbGFyZ2UsIGJ1dCBtdWNoIHNlZW1zIHRvIGJlIGxhbmd1YWdlIHJld3JpdGVz IGFuZCBjbGFyaWZpY2F0aW9uLg0KQ291bGQgdGhlIGF1dGhvcnMgcGxlYXNlIHN1Ym1pdCBhIGxp c3Qgb2Ygc3Vic3RhbnRpdmUgY2hhbmdlcy4NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAxMywgMjAxNCA0OjExIFBNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3Jn DQpDYzogbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbDJ2 cG4tZXZwbi0wNS50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTGF5ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0d29ya3MgV29y a2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBCR1Ag TVBMUyBCYXNlZCBFdGhlcm5ldCBWUE4NCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQWxpIFNh amFzc2kNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUmFodWwgQWdnYXJ3YWwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgV2ltIEhlbmRlcmlja3gNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgQWxkcmluIElzYWFjDQogICAgICAgICAgICAgICAgICAgICAgICAgIEphbWVzIFV0dGFybw0K CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbDJ2cG4tZXZwbi0wNS50eHQNCglQYWdlcyAg ICAgICAgICAgOiA0OQ0KCURhdGUgICAgICAgICAgICA6IDIwMTQtMDItMTMNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBwcm9jZWR1cmVzIGZvciBCR1AgTVBMUyBiYXNl ZCBFdGhlcm5ldCBWUE5zDQogICAoRVZQTikuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWwydnBuLWV2cG4vDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl cnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1sMnZwbi1ldnBuLTA1DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt bDJ2cG4tZXZwbi0wNQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From nobody Thu Feb 13 17:07:19 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4491A0017 for ; Thu, 13 Feb 2014 17:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aERx9xo21_r for ; Thu, 13 Feb 2014 17:07:15 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 42C1F1A0006 for ; Thu, 13 Feb 2014 17:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2419; q=dns/txt; s=iport; t=1392340034; x=1393549634; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=M0GC/BugF6Ed0BOUDq/TUl4KsI55dI0lDVquHtNg/bM=; b=Sx8cz2syXK0tYWEsDqbQ058lyAfD8H4H52tB/4bLhrQx8sBp4ihoVybX I9zUD6saUgQeZJv7QZP9GfCqWgE4zC6r9gqeDE4rV4gAN7axEo2GQ97sB y9W/BbZXu6P+HNinMLZI1mbSnZFTHaYlYB4brb+UacsFG5Mox7GBsHqrS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANpq/VKtJV2Z/2dsb2JhbABZgmUhOFEGv1KBGRZ0giUBAQEEOksGAQgRBAEBHwk5FAkIAgQBEgmHfAEHBchZF44iXgaEMgSYLIEykHGDLYFpQQ X-IronPort-AV: E=Sophos;i="4.95,841,1384300800"; d="scan'208";a="20341164" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 14 Feb 2014 01:07:13 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1E17DgS015356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 01:07:13 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 19:07:13 -0600 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt Thread-Topic: I-D Action: draft-ietf-l2vpn-evpn-05.txt Thread-Index: AQHPKRlYwzOqISXTKkKuRYQ1yRavy5q0SjEA//+EQoA= Date: Fri, 14 Feb 2014 01:07:12 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F89932@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.71.173] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D3EDB8C11CC2644B8B492C241CD219C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/VOl-uxnCPxjiwnGZ1QM-WPQqFGE X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 01:07:17 -0000 Hi Jakob, The reason the diff looks large is because some of the sections have been reshuffled. Here are the main changes to this rev: 1. Modified section 5 to have a generalized format for ESI w/ additional ESI types 2. Clarified the advertisement of Ethernet A-D per ES route when the number of associated RTs is more than the limit to be advertised with a single route. In such case, instead of a single Ethernet A-D per ES route, a set of such routes is advertised =20 3. Added a 2nd MPLS label to the MAC route. This label is optional 4. Added text to security section 5. Added text to IANA section Cheers, Ali On 2/13/14 4:30 PM, "Jakob Heitz" wrote: >The diff is large, but much seems to be language rewrites and >clarification. >Could the authors please submit a list of substantive changes. > >Thanks, >Jakob. > >-----Original Message----- >From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Thursday, February 13, 2014 4:11 PM >To: i-d-announce@ietf.org >Cc: l2vpn@ietf.org >Subject: I-D Action: draft-ietf-l2vpn-evpn-05.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 : BGP MPLS Based Ethernet VPN > Authors : Ali Sajassi > Rahul Aggarwal > Wim Henderickx > Aldrin Isaac > James Uttaro > Filename : draft-ietf-l2vpn-evpn-05.txt > Pages : 49 > Date : 2014-02-13 > >Abstract: > This document describes procedures for BGP MPLS based Ethernet VPNs > (EVPN). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-evpn-05 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > From nobody Thu Feb 13 23:53:51 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F121A0119 for ; Thu, 13 Feb 2014 23:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Px-giz8ZVFH for ; Thu, 13 Feb 2014 23:53:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DABE01A00E9 for ; Thu, 13 Feb 2014 23:53:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBC51997; Fri, 14 Feb 2014 07:53:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 07:52:38 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 07:53:41 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 15:53:32 +0800 From: Haoweiguo To: Lizhenbin , "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: =?gb2312?B?tPC4tDogW2wydnBuXSAgV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLWwy?= =?gb2312?B?dnBuLWV0cmVlLWZyd2stMDQgKGV0cmVlIGZyYW1ld29yaykgLSBleHRlbmRl?= =?gb2312?B?ZC4gUGxlYXNlLCBwcm92aWRlIGNvbW1lbnRzLCBhbmQgaW5kaWNhdGUgb2Jq?= =?gb2312?Q?ection_or_support_for_moving_this_draft_forward?= Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Index: AQHPJeW6QRCH2EZWg0ChrZwysR2dEJqvXzDQgAUIkcQ= Date: Fri, 14 Feb 2014 07:53:32 +0000 Message-ID: References: , <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA06E@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA06E@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.22.248] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ovDllnPQNvbw1_l3XgFaaYkHCKw X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 07:53:49 -0000 U3VwcG9ydCENCldlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IEwydnBuIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpemhlbmJp biBbbGl6aGVuYmluQGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxNMTqMtTCMTHI1SAxMTowMQ0K ytW8/sjLOiBCaXRhciwgTmFiaWwgTjsgbDJ2cG5AaWV0Zi5vcmcNCtb3zOI6ILTwuLQ6IFtsMnZw bl0gIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1sMnZwbi1ldHJlZS1mcndrLTA0IChldHJl ZSBmcmFtZXdvcmspIC0gZXh0ZW5kZWQuIFBsZWFzZSwgcHJvdmlkZSBjb21tZW50cywgYW5kIGlu ZGljYXRlIG9iamVjdGlvbiBvciBzdXBwb3J0IGZvciBtb3ZpbmcgdGhpcyBkcmFmdCBmb3J3YXJk DQoNClN1cHBvcnQuDQoNCg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMMnZwbiBb bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQml0YXIsIE5hYmlsIE4NCreiy83K sbzkOiAyMDE0xOoy1MIxMMjVIDY6MjUNCsrVvP7IyzogbDJ2cG5AaWV0Zi5vcmcNCtb3zOI6IFts MnZwbl0gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLWwydnBuLWV0cmVlLWZyd2stMDQgKGV0 cmVlIGZyYW1ld29yaykgLSBleHRlbmRlZC4gUGxlYXNlLCBwcm92aWRlIGNvbW1lbnRzLCBhbmQg aW5kaWNhdGUgb2JqZWN0aW9uIG9yIHN1cHBvcnQgZm9yIG1vdmluZyB0aGlzIGRyYWZ0IGZvcndh cmQNCg0KSGksDQpUaGlzIGlzIGFuIGV4dGVuc2lvbiBvZiB0aGUgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24gdGhlIGRyYWZ0ICJBIEZyYW1ld29yayBmb3IgRXRoZXJuZXQgVHJlZSAoRS1UcmVl KSBTZXJ2aWNlIG92ZXIgYSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgTmV0 d29yayIuICBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbDJ2cG4tZXRyZWUtZnJ3ay0wNC4NCg0KVGhlcmUgd2FzIG5vIHJlc3Bv bnNlIHRvIGFuIGVhcmxpZXIgY2FsbCwgYW5kIHdlIHdhbnQgdG8gZW5zdXJlIHRoYXQgcGVvcGxl IGFyZSBwYXlpbmcgYXR0ZW50aW9uLiBUaGVyZSB3ZXJlIHF1aXRlIGZldyBlZGl0cyBmcm9tIHRo ZSBlYXJsaWVyIGRyYWZ0IHZlcnNpb24uDQoNClBsZWFzZSwgcmV2aWV3IHRoZSBkcmFmdCBhbmQg c2VuZCBhbnkgY29tbWVudHMgdG8gdGhlIEwyVlBOIHdvcmtpbmcgZ3JvdXAgZW1haWwgbGlzdCBi eSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwuIFBsZWFzZSwgaW5kaWNhdGUgeW91ciBzdXBwb3J0 IGZvciBtb3ZpbmcgdGhpcyBkcmFmdCBmb3J3YXJkIG9yIGFueSBvYmplY3Rpb24geW91IG1pZ2h0 IGhhdmUuDQoNClRoaXMgZXh0ZW5kZWQgV0cgbGFzdCBjYWxsIHdpbGwgY2xvc2Ugb24gTW9uZGF5 IEZlYnJ1YXJ5IDE3LCAyMDE0Lg0KDQpSZWdhcmRzLA0KTmFiaWwgJiBHaWxlcw== From nobody Fri Feb 14 06:49:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B7E1A0254 for ; Fri, 14 Feb 2014 06:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7KtIA7EIBjV for ; Fri, 14 Feb 2014 06:49:41 -0800 (PST) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 93BBF1A025B for ; Fri, 14 Feb 2014 06:49:37 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id e53so5761090eek.13 for ; Fri, 14 Feb 2014 06:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=Ci1ocfrOMVPiX1nKqEJ8IVa91AF34tWzq/kMJnoJO+w=; b=Bv7mevXwjrQ/XIpcc5Y+rV6klzfwaBSbE39QVBlyhRCbUw8OllUnAfS9Vx6Qcu7ZNG fVk2kbI8u59JDwmddsw60D80A6GonxAW0nrG5Qja2CDRfO40xh83YjkqQ+dRBeSBVgg+ x2+P51UG77u35ZmpvxKKGi7FHhDhZEryk7jAkNCzLmrw0Dzk5WKx/AZgMlbaBjYQHRee J4kCobZIw6lNx0FhxtJfsFUg2COJrDILOxbwsUj01R5jkvEqT1mpL5z+cKFNhCvw3C5h WXic8NRgsVgH6lWjXDtmeWXcDiPdIl9nJmkCdgi1PxARrt4rqJssM4odCEKWOXxP/vPL c+Pg== X-Received: by 10.14.110.68 with SMTP id t44mr3063973eeg.74.1392389375640; Fri, 14 Feb 2014 06:49:35 -0800 (PST) Received: from ams3-vpn-dhcp7025.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id j41sm20581285eeg.10.2014.02.14.06.49.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 06:49:34 -0800 (PST) From: Giles Heron Content-Type: multipart/alternative; boundary="Apple-Mail=_D5DE569D-E4C2-49E0-A464-3D9D5C6C1D59" Subject: Fwd: [netmod] [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Date: Fri, 14 Feb 2014 14:49:26 +0000 References: <876DDDF4-C991-4C03-81C3-81417F48FE0A@lucidvision.com> To: "l2vpn@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/B7d2Icd3xy2FBgI2n2W3N7A4Mbw X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:49:44 -0000 --Apple-Mail=_D5DE569D-E4C2-49E0-A464-3D9D5C6C1D59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Worth noting. Giles Begin forwarded message: > From: Thomas Nadeau > Subject: [netmod] Fwd: [OPS-AREA] configuration: writable MIB modules = versus NETCONF/YANG modules > Date: 14 February 2014 01:41:34 GMT > To: netmod@ietf.org >=20 >=20 > FYI in case you are not on the ops dir list... >=20 > --Tom >=20 >=20 > Begin forwarded message: >=20 >> From: Benoit Claise >> Subject: [OPS-AREA] configuration: writable MIB modules versus = NETCONF/YANG modules >> Date: February 13, 2014 at 7:39:57 PM EST >> To: "ops-area@ietf.org" >>=20 >> Dear all, >>=20 >> We occasionally see read-write MIB module proposals within the IETF. >> However, the write capabilities of those MIB modules are rarely = implemented. >>=20 >> While discussing this issue with the MIB doctors, we arrive to the = conclusion that it's now time to set the direction for future MIB = developments within the IETF. Basically, let's not specify read-write = MIB modules unless we have a good reason. Read-only MIB modules are = still fine though, as SNMP is clearly used for monitoring purposes. >>=20 >> Here is the statement we came up with: >> The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the = NETCONF/YANG standards for configuration, specifically in new charters. = SNMP MIB modules modifying persistent configuration state should only be = produced by working groups in cases of clear utility=20 >> and consensus to use SNMP write operations for configuration. >> Ideally, this should become an IESG statement. >> Your feedback is most welcome. >>=20 >> Regards, the MIB doctors & Benoit >>=20 >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_D5DE569D-E4C2-49E0-A464-3D9D5C6C1D59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Worth = noting.

Giles

Begin = forwarded message:

From: Thomas Nadeau = <tnadeau@lucidvision.com>
Subject: [netmod] Fwd: [OPS-AREA] configuration: writable = MIB modules versus NETCONF/YANG modules
Date: 14 February 2014 = 01:41:34 GMT


FYI in case you are not on the = ops dir list...

= --Tom


Begin forwarded = message:

From: Benoit Claise <bclaise@cisco.com>
Subject: = [OPS-AREA] = configuration: writable MIB modules versus NETCONF/YANG = modules
Date: February 13, 2014 at 7:39:57 PM = EST
To: "ops-area@ietf.org" <ops-area@ietf.org>

=20 =20
Dear all,

We occasionally see read-write MIB module proposals within the = IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

_______________________________________________
OPS-AREA mailing = list
OPS-AREA@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ops-area

_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

= --Apple-Mail=_D5DE569D-E4C2-49E0-A464-3D9D5C6C1D59-- From nobody Fri Feb 14 06:58:18 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859E11A022E for ; Fri, 14 Feb 2014 06:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-2DcD4NtRhz for ; Fri, 14 Feb 2014 06:58:15 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 90BD61A0294 for ; Fri, 14 Feb 2014 06:58:13 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.95,845,1384318800"; d="scan'208,217";a="199562232" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Feb 2014 09:58:10 -0500 Received: from PRVPEXVS13.corp.twcable.com ([10.136.163.47]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 14 Feb 2014 09:58:11 -0500 From: "Rogers, Josh" To: Giles Heron , "l2vpn@ietf.org" Date: Fri, 14 Feb 2014 09:58:17 -0500 Subject: Re: [netmod] [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-Topic: [netmod] [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-Index: Ac8plS2oNgR3/SJmQ3iFMwCBQCRWrA== Message-ID: References: <876DDDF4-C991-4C03-81C3-81417F48FE0A@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF2389E45B811joshrogerstwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/mKSHCUHyAiKsfM2jqrtdPKsrUUw X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:58:17 -0000 --_000_CF2389E45B811joshrogerstwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is unfortunate to see RW abandoned. I believe that SNMP R/W is not adop= ted more because of poor documentation, than because SNMP is not a good con= figuration vehicle. I know of one vendor that provides a "CLI to SNMP" dic= tionary that provides OID's for every CLI command in their cli guide. I th= ink if everyone did something similar, tools that leverage SNMP R/W would = be more prolific. Honestly, I don't see netconf adopted much better (although I wish it was, = its an excellent configuration vehicle). -Josh From: Giles Heron > Date: Friday, February 14, 2014 8:49 AM To: "l2vpn@ietf.org" > Subject: Fwd: [netmod] [OPS-AREA] configuration: writable MIB modules versu= s NETCONF/YANG modules Worth noting. Giles Begin forwarded message: From: Thomas Nadeau > Subject: [netmod] Fwd: [OPS-AREA] configuration: writable MIB modules versu= s NETCONF/YANG modules Date: 14 February 2014 01:41:34 GMT To: netmod@ietf.org FYI in case you are not on the ops dir list... --Tom Begin forwarded message: From: Benoit Claise > Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG= modules Date: February 13, 2014 at 7:39:57 PM EST To: "ops-area@ietf.org" > Dear all, We occasionally see read-write MIB module proposals within the IETF. However, the write capabilities of those MIB modules are rarely implemented= . While discussing this issue with the MIB doctors, we arrive to the conclusi= on that it's now time to set the direction for future MIB developments with= in the IETF. Basically, let's not specify read-write MIB modules unless we = have a good reason. Read-only MIB modules are still fine though, as SNMP is= clearly used for monitoring purposes. Here is the statement we came up with: The OPS area recommends the use of NETCONF/YANG standards for configuration= . IETF working groups are therefore encouraged to use the NETCONF/YANG stan= dards for configuration, specifically in new charters. SNMP MIB modules mod= ifying persistent configuration state should only be produced by working gr= oups in cases of clear utility and consensus to use SNMP write operations for configuration. Ideally, this should become an IESG statement. Your feedback is most welcome. Regards, the MIB doctors & Benoit _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CF2389E45B811joshrogerstwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It is unfortunate to see RW abandoned.  I believe that SNMP R/W i= s not adopted more because of poor documentation, than because SNMP is not = a good configuration vehicle.  I know of one vendor that provides a &q= uot;CLI to SNMP" dictionary that provides OID's for every CLI command in their cli guide.  I think if everyone did so= mething similar,  tools that leverage SNMP R/W would be more= prolific.

Honestly, I don't see netconf adopted much better (although I wish it = was, its an excellent configuration vehicle).

-Josh

From: Giles Heron <giles.heron@gmail.com>
Date: Friday, February 14, 2014 8:4= 9 AM
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: Fwd: [netmod] [OPS-AREA] c= onfiguration: writable MIB modules versus NETCONF/YANG modules

Worth noting.

Giles

Begin forwarded message:

From: Thoma= s Nadeau <tnadeau@lucidvision= .com>
Subject: [n= etmod] Fwd: [OPS-AREA] configuration: writable MIB modules versus NETCONF/Y= ANG modules
Date: 14 Fe= bruary 2014 01:41:34 GMT


FYI in case= you are not on the ops dir list...

--Tom<= /div>


Begin forwarded message:

From: Benoit Claise <bclaise@cisco.com>
Subject: [OPS-AREA] configuration: writable MIB mod= ules versus NETCONF/YANG modules
Date: February 13, 2014 at 7:39:57 PM EST

Dear all,

We occasionally see read-write MIB module proposals within the IETF.
However, the write capabilities of those MIB modules are rarely implemented= .

While discussing this issue with the MIB doctors, we arrive to the conclusi= on that it's now time to set the direction for future MIB developments with= in the IETF. Basically, let's not specify read-write MIB modules unless we = have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purp= oses.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for c= onfiguration. IETF working groups are therefore encouraged to use the NETCO= NF/YANG standards for configuration, specifically in new charters. SNMP MIB= modules modifying persistent configuration state should only be produced by working groups in cases of clear utility =
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf= .org/mailman/listinfo/ops-area

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netmod


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CF2389E45B811joshrogerstwcablecom_-- From nobody Fri Feb 14 07:48:30 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A21A02D6 for ; Fri, 14 Feb 2014 07:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOaU19JEhr2k for ; Fri, 14 Feb 2014 07:48:22 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9EA1A02D9 for ; Fri, 14 Feb 2014 07:48:17 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b15so5778623eek.1 for ; Fri, 14 Feb 2014 07:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=URCADZYp0AB7gQFUZAYeyAlkh9tqilgpLUI0VWIr+S0=; b=mWZ+Ks5ZVK3v4ZKKGcj9J1bUD53dC5Y+cg+NyDuuD2PyQy5f9VPvTadZ0H4wqZ0E9V XwZSSiF2mZLyo6qG5gih5Enm6oFAHN3z6XN40foRrQWGHAyvGsg3CJNBCYPZsbdL7tbJ uMNP9i4P36kkYsz2vJ9mXhlJ30bYPMazZr1GVuNtz1Lq+Yh1PxokDivq9hT07JppsdJA e0VtyVtlvq2hmOXMpvpTvbjbLhNrYsVV+X1QUQkmL0nMA+99o+UU3jfLJlyr8msocFmM m+YW8XYMi438r8Kx4djisMS8kcBojvxvb1YX4AFjRMvEpElutlVyxm3zTXyYD9ZCVp8d NvfQ== X-Received: by 10.14.216.3 with SMTP id f3mr3423683eep.66.1392392895419; Fri, 14 Feb 2014 07:48:15 -0800 (PST) Received: from ams3-vpn-dhcp7025.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id f45sm21121643eeg.5.2014.02.14.07.48.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 07:48:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [netmod] [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules From: Giles Heron In-Reply-To: Date: Fri, 14 Feb 2014 15:48:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <876DDDF4-C991-4C03-81C3-81417F48FE0A@lucidvision.com> To: "Rogers, Josh" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/X-1qy9U-_iLDXFddgkwsJj_HvJ4 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:48:29 -0000 Hi Josh, Fair comment. I have to say though that the vast majority of the pain in shepherding = the VPLS MIB has been in read-write. IIRC the main issue was around = references from one table to another where there's an implied order of = creation (so if X points to Y you have to either create Y before X, or = allow a "dangling reference"). NETCONF resolves a lot of that by = wrapping changes into a single edit-config operation which either = succeeds or fails. Giles On 14 Feb 2014, at 14:58, "Rogers, Josh" = wrote: > It is unfortunate to see RW abandoned. I believe that SNMP R/W is not = adopted more because of poor documentation, than because SNMP is not a = good configuration vehicle. I know of one vendor that provides a "CLI = to SNMP" dictionary that provides OID's for every CLI command in their = cli guide. I think if everyone did something similar, tools that = leverage SNMP R/W would be more prolific. >=20 > Honestly, I don't see netconf adopted much better (although I wish it = was, its an excellent configuration vehicle). >=20 > -Josh >=20 > From: Giles Heron > Date: Friday, February 14, 2014 8:49 AM > To: "l2vpn@ietf.org" > Subject: Fwd: [netmod] [OPS-AREA] configuration: writable MIB modules = versus NETCONF/YANG modules >=20 > Worth noting. >=20 > Giles >=20 > Begin forwarded message: >=20 >> From: Thomas Nadeau >> Subject: [netmod] Fwd: [OPS-AREA] configuration: writable MIB modules = versus NETCONF/YANG modules >> Date: 14 February 2014 01:41:34 GMT >> To: netmod@ietf.org >>=20 >>=20 >> FYI in case you are not on the ops dir list... >>=20 >> --Tom >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Benoit Claise >>> Subject: [OPS-AREA] configuration: writable MIB modules versus = NETCONF/YANG modules >>> Date: February 13, 2014 at 7:39:57 PM EST >>> To: "ops-area@ietf.org" >>>=20 >>> Dear all, >>>=20 >>> We occasionally see read-write MIB module proposals within the IETF. >>> However, the write capabilities of those MIB modules are rarely = implemented. >>>=20 >>> While discussing this issue with the MIB doctors, we arrive to the = conclusion that it's now time to set the direction for future MIB = developments within the IETF. Basically, let's not specify read-write = MIB modules unless we have a good reason. Read-only MIB modules are = still fine though, as SNMP is clearly used for monitoring purposes. >>>=20 >>> Here is the statement we came up with: >>>> The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the = NETCONF/YANG standards for configuration, specifically in new charters. = SNMP MIB modules modifying persistent configuration state should only be = produced by working groups in cases of clear utility=20 >>>> and consensus to use SNMP write operations for configuration. >>> Ideally, this should become an IESG statement. >>> Your feedback is most welcome. >>>=20 >>> Regards, the MIB doctors & Benoit >>>=20 >>> _______________________________________________ >>> OPS-AREA mailing list >>> OPS-AREA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-area >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From nobody Fri Feb 14 07:52:11 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1B1A02D2 for ; Fri, 14 Feb 2014 07:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-eWYODwCEq7 for ; Fri, 14 Feb 2014 07:52:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1111A02E3 for ; Fri, 14 Feb 2014 07:51:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDP13977; Fri, 14 Feb 2014 15:51:48 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 15:47:16 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 15:48:20 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 07:48:11 -0800 From: Linda Dunbar To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: RE: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-frwk-04 (etree framework) - extended. Please, provide comments, and indicate objection or support for moving this draft forward Thread-Index: AQHPJeW6QRCH2EZWg0ChrZwysR2dEJqvXzDQgAUIkcSAAIStUA== Date: Fri, 14 Feb 2014 15:48:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7FFE1@dfweml701-chm.china.huawei.com> References: , <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA06E@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/zV-pLNrCnHvBhk3RDhd20qkRNMI X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:52:06 -0000 DQoNClN1cHBvcnQhDQoNCkxpbmRhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMMnZwbiBbbWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQml0YXIsIE5hYmlsIE4NCreiy83KsbzkOiAyMDE0xOoy 1MIxMMjVIDY6MjUNCsrVvP7IyzogbDJ2cG5AaWV0Zi5vcmcNCtb3zOI6IFtsMnZwbl0gV0cgbGFz dCBjYWxsIGZvciBkcmFmdC1pZXRmLWwydnBuLWV0cmVlLWZyd2stMDQgKGV0cmVlIGZyYW1ld29y aykgLSBleHRlbmRlZC4gUGxlYXNlLCBwcm92aWRlIGNvbW1lbnRzLCBhbmQgaW5kaWNhdGUgb2Jq ZWN0aW9uIG9yIHN1cHBvcnQgZm9yIG1vdmluZyB0aGlzIGRyYWZ0IGZvcndhcmQNCg0KSGksDQpU aGlzIGlzIGFuIGV4dGVuc2lvbiBvZiB0aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gdGhl IGRyYWZ0ICJBIEZyYW1ld29yayBmb3IgRXRoZXJuZXQgVHJlZSAoRS1UcmVlKSBTZXJ2aWNlIG92 ZXIgYSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgTmV0d29yayIuICBUaGUg ZHJhZnQgY2FuIGJlIGZvdW5kIGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbDJ2cG4tZXRyZWUtZnJ3ay0wNC4NCg0KVGhlcmUgd2FzIG5vIHJlc3BvbnNlIHRvIGFuIGVh cmxpZXIgY2FsbCwgYW5kIHdlIHdhbnQgdG8gZW5zdXJlIHRoYXQgcGVvcGxlIGFyZSBwYXlpbmcg YXR0ZW50aW9uLiBUaGVyZSB3ZXJlIHF1aXRlIGZldyBlZGl0cyBmcm9tIHRoZSBlYXJsaWVyIGRy YWZ0IHZlcnNpb24uDQoNClBsZWFzZSwgcmV2aWV3IHRoZSBkcmFmdCBhbmQgc2VuZCBhbnkgY29t bWVudHMgdG8gdGhlIEwyVlBOIHdvcmtpbmcgZ3JvdXAgZW1haWwgbGlzdCBieSByZXNwb25kaW5n IHRvIHRoaXMgZW1haWwuIFBsZWFzZSwgaW5kaWNhdGUgeW91ciBzdXBwb3J0IGZvciBtb3Zpbmcg dGhpcyBkcmFmdCBmb3J3YXJkIG9yIGFueSBvYmplY3Rpb24geW91IG1pZ2h0IGhhdmUuDQoNClRo aXMgZXh0ZW5kZWQgV0cgbGFzdCBjYWxsIHdpbGwgY2xvc2Ugb24gTW9uZGF5IEZlYnJ1YXJ5IDE3 LCAyMDE0Lg0KDQpSZWdhcmRzLA0KTmFiaWwgJiBHaWxlcw0K From nobody Fri Feb 14 13:40:32 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF751A0407 for ; Fri, 14 Feb 2014 13:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zTrSZp-ERxC for ; Fri, 14 Feb 2014 13:40:24 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7B1A03D3 for ; Fri, 14 Feb 2014 13:40:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 14 Feb 2014 21:40:22 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="653037836" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi02.verizon.com with ESMTP; 14 Feb 2014 21:40:22 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Fri, 14 Feb 2014 16:40:22 -0500 To: "l2vpn@ietf.org" Date: Fri, 14 Feb 2014 16:40:21 -0500 Subject: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Topic: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Index: Ac8pzVxFpd+xbO5QQFigS9d7vjhcjA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/wHEYRcxRgaMqQNDVSfaOZQwywU8 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:40:29 -0000 Hi, This is a friendly reminder. Please, also note that draft submission cutoff date is today (please, see below). Thanks, Nabil On 2/9/14 10:36 AM, "Bitar, Nabil N" wrote: >Hi L2VPN WG, > >If you would like to request a time-slot for the L2VPN WG session at IETF >89-London, please reply to us by Friday 2/14/2014 along with the >following information: > >1) Draft title >2) Presenter name >3) Requested duration > >Please, make sure that the subject of you reply is: Re:[l2vpn] L2VPN >Agenda Slot Call for IETF 89 =AD London (i.e., reply to this email and the >WG chairs and secretary (Andrew)) > >Please note that priority will be given to drafts that are clearly within >the scope of the current L2VPN charter. >Please also note the following cutoff date for draft submission. This >date applies to new 00 drafts and updated drafts. > >2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, >including -00) by UTC 23:59, upload using IETF ID Submission Tool. > >Thanks, >Nabil From nobody Mon Feb 17 10:52:16 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745031A050A for ; Mon, 17 Feb 2014 10:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-xl8Qeut5z0 for ; Mon, 17 Feb 2014 10:52:12 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A35901A01D6 for ; Mon, 17 Feb 2014 10:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3603; q=dns/txt; s=iport; t=1392663130; x=1393872730; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mrFNHZnaRW6UAMsJV2OjscL8JIDN/APmyFxMLniJwfY=; b=a3ebYOwPuqoX3UUdjP0PQv0UiHoOheqjVrG8BBmVaUg21Rcye9wkd2rv VT/huEmT66REY/w3juDDFXjI+R2NXXbG4Mp7961Vy34qhb//aVpXTCsYQ VI4gLA8GePcs2d4vqClLmOCsARKmQ+NsbP6+bUq23DlqiXF4GXnT5ekIM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAKVZAlOtJV2Z/2dsb2JhbABZgwaBD788gSAWdIIlAQEBAwEdUQsFCwIBCBguMiUCBA4Fh3EDCQjKRxeMZ4E4DgMBHTMHgySBFASJEI8ckiODLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,862,1384300800"; d="scan'208";a="21055188" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 17 Feb 2014 18:52:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1HIq86t001254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 18:52:08 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 12:52:08 -0600 From: "Andrew McLachlan (amclachl)" To: "l2vpn@ietf.org" Subject: Re: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Topic: [l2vpn] L2VPN Agenda Slot Call for IETF 89 - London Thread-Index: AQHPLBFbkJdCUwlNJU2qeR0aV6dcPQ== Date: Mon, 17 Feb 2014 18:52:08 +0000 Message-ID: <19256ABF-F669-4AC9-A9B2-D5563C3D20EB@cisco.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.81.215] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <79EBA039EC460047B23714E26E7AD418@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Hyu06STwVhvvAF2liUmtdmB8oWQ Cc: "Giles Heron \(giheron\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:52:14 -0000 Dear All Thank you to those of you who have already submitted requests for slots, we= also still have a few available. As you will be aware we do need to publish the draft agenda ASAP, in fact w= e are past the cut off date. Therefore please respond directly to Giles/Nab= il/ myself in the next 48 hours. An additional note: =09 Following on from the last session in Vancouver, where some great discussi= ons happened at the mic , we would like to continue this theme.=20 Therefore for those of you presenting please consider tailoring your slide= s to provoke discussion in London so we once again have a lively debate at = the mic and then onwards to the mailing list. It would be appreciated if the slides focus the key points you wish to make= , changes and/or updates to a draft etc, instead of a blow by blow detail o= f what a draft contents.=20 This is both for the sake of the agenda and to allow time for discussion at= the mic in your slot. A draft is available to read online, hence the reque= sts. In essence, less might be more. Andrew On 14 Feb 2014, at 21:40, "Bitar, Nabil N" wrot= e: > Hi, > This is a friendly reminder. Please, also note that draft submission > cutoff date is today (please, see below). >=20 > Thanks, > Nabil >=20 > On 2/9/14 10:36 AM, "Bitar, Nabil N" wrot= e: >=20 >> Hi L2VPN WG, >>=20 >> If you would like to request a time-slot for the L2VPN WG session at IET= F >> 89-London, please reply to us by Friday 2/14/2014 along with the >> following information: >>=20 >> 1) Draft title >> 2) Presenter name >> 3) Requested duration >>=20 >> Please, make sure that the subject of you reply is: Re:[l2vpn] L2VPN >> Agenda Slot Call for IETF 89 =AD London (i.e., reply to this email and t= he >> WG chairs and secretary (Andrew)) >>=20 >> Please note that priority will be given to drafts that are clearly withi= n >> the scope of the current L2VPN charter. >> Please also note the following cutoff date for draft submission. This >> date applies to new 00 drafts and updated drafts. >>=20 >> 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, >> including -00) by UTC 23:59, upload using IETF ID Submission Tool. >>=20 >> Thanks, >> Nabil On 14 Feb 2014, at 21:40, "Bitar, Nabil N" wrot= e: > Hi, > This is a friendly reminder. Please, also note that draft submission > cutoff date is today (please, see below). >=20 > Thanks, > Nabil >=20 > On 2/9/14 10:36 AM, "Bitar, Nabil N" wrot= e: >=20 >> Hi L2VPN WG, >>=20 >> If you would like to request a time-slot for the L2VPN WG session at IET= F >> 89-London, please reply to us by Friday 2/14/2014 along with the >> following information: >>=20 >> 1) Draft title >> 2) Presenter name >> 3) Requested duration >>=20 >> Please, make sure that the subject of you reply is: Re:[l2vpn] L2VPN >> Agenda Slot Call for IETF 89 =AD London (i.e., reply to this email and t= he >> WG chairs and secretary (Andrew)) >>=20 >> Please note that priority will be given to drafts that are clearly withi= n >> the scope of the current L2VPN charter. >> Please also note the following cutoff date for draft submission. This >> date applies to new 00 drafts and updated drafts. >>=20 >> 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, >> including -00) by UTC 23:59, upload using IETF ID Submission Tool. >>=20 >> Thanks, >> Nabil >=20 From nobody Mon Feb 17 15:13:04 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA751A03CB; Mon, 17 Feb 2014 15:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2GKs4TESlX5; Mon, 17 Feb 2014 15:13:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C03451A0564; Mon, 17 Feb 2014 15:12:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Document Action: 'Requirements for Ethernet VPN (EVPN)' to Informational RFC (draft-ietf-l2vpn-evpn-req-07.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140217231252.22173.70247.idtracker@ietfa.amsl.com> Date: Mon, 17 Feb 2014 15:12:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/LB1feE4Tb5GcxnJW0BmW_ek4ezg Cc: l2vpn mailing list , l2vpn chair , RFC Editor X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:13:02 -0000 The IESG has approved the following document: - 'Requirements for Ethernet VPN (EVPN)' (draft-ietf-l2vpn-evpn-req-07.txt) as Informational RFC This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn-req/ Technical Summary The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution which addresses the above issues. Working Group Summary This document is an L2VPN Working Group document, and has been reviewed in the working group through multiple iterations of the draft. There was considerable debate during and after the WG last call which resulted in new revisions being issued to resolve various comments. Document Quality The document provides a clear and concise set of requirements for E-VPN - broken down into different requirement areas. As a requirements draft there is no protocol to implement. Personnel Document Shepherd: Giles Heron (giheron@cisco.com) Area Director: Stewart Bryant (stbryant@cisco.com) From nobody Thu Feb 20 00:43:31 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E71A004B for ; Thu, 20 Feb 2014 00:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV6ktD49mLOz for ; Thu, 20 Feb 2014 00:43:28 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF11A0037 for ; Thu, 20 Feb 2014 00:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=151; q=dns/txt; s=iport; t=1392885804; x=1394095404; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rSk5AwOPYDxHDlVhnhGTn6zXRehWOwTx9A47DtpLE6o=; b=Ik+bFQo4LVTdcKWZ8BSsLSlSBoZQb+9q5THNOAt10cJMww8h4VOaqj61 FaR+U5sVaBg5Y5OfjlnBpgEihqf+Nld2NWHpjbFbT/Nt6nyF1Qt2EJwxL YMX0OM/bSxEFDa9pQnICmAYDrdDh4lVdHsHoVWZo6zPyN+bqqwrY5zsCE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAB2/BVOtJXG//2dsb2JhbABZgwY4V8AHgRUWdIImAQEEgQkCAU4yJQIEHId8Dc5SF44QW4MkgRQEiRCPIJIkgy2CKg X-IronPort-AV: E=Sophos;i="4.97,511,1389744000"; d="scan'208";a="21823602" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-2.cisco.com with ESMTP; 20 Feb 2014 08:43:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1K8hLPL004816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Feb 2014 08:43:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 02:43:21 -0600 From: "Andrew McLachlan (amclachl)" To: "l2vpn@ietf.org" Subject: L2VPN Agenda for IETF 89 - London Thread-Topic: L2VPN Agenda for IETF 89 - London Thread-Index: AQHPLhfO0a1PlJq4G0uRhM30Rz2NtQ== Date: Thu, 20 Feb 2014 08:43:21 +0000 Message-ID: <2ADDEC61-9429-436C-A158-20D0E38C3834@cisco.com> References: <19256ABF-F669-4AC9-A9B2-D5563C3D20EB@cisco.com> In-Reply-To: <19256ABF-F669-4AC9-A9B2-D5563C3D20EB@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <093C1B53FBD3D9428E8B49BF8385F4FF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/p4692F3Wyz8p8Ge4pRcJTWkkPC4 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 08:43:29 -0000 We have now published the agenda for IETF 89 which you can find at the link= below. http://www.ietf.org/proceedings/89/agenda/agenda-89-l2vpn= From nobody Fri Feb 21 00:03:51 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9461A04C5 for ; Fri, 21 Feb 2014 00:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2n9W0bk1ACG for ; Fri, 21 Feb 2014 00:03:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC5301A04C3 for ; Fri, 21 Feb 2014 00:03:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBI84235; Fri, 21 Feb 2014 08:03:39 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:03:22 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:03:38 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.180]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 16:03:32 +0800 From: Mingui Zhang To: "l2vpn@ietf.org" Subject: Pease read and comment//FW: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt Thread-Topic: Pease read and comment//FW: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt Thread-Index: AQHPKWS6aSOstAPL2EecTUfYvrxjqJq95Jvg Date: Fri, 21 Feb 2014 08:03:32 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73369FFB1@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/badXTP0nSKIs5Ue_xB-lTeZ7bKU X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:03:49 -0000 Hi, Service providers are facing a heavy provisioning overhead in VPLS since a = mass of PWs need to be maintained. If PEs can use Customer VLAN ID as a ser= vice discriminator in VPLS, the required number of PWs will be greatly redu= ced. Therefore, the provision overhead can be significantly relieved. Authors compose the draft to justify the solutions on recognizing Customer = VLAN IDs in VPLS. We wish to receive your comments and suggestions.=20 Thanks, Mingui >-----Original Message----- >From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Friday, February 14, 2014 5:10 PM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > > Title : Tagging Customer Bridge Domains in VPLS > Authors : Mingui Zhang > Bin Wang > Liang Xia > Jie Hu > Filename : draft-zhang-l2vpn-vpls-bd-tagging-01.txt > Pages : 8 > Date : 2014-02-14 > >Abstract: > This document proposes to use Customer VLAN ID as a identifier for > traffic isolation in Virtual Private LAN Service (VPLS). In this way, > multiple bridge domains of customers can share a single VPLS instance > while their traffic are separated. With this proposal, Service > Providers can be relieved from the heavy provisioning overhead of > large number of pseudowires in the environment where a mass of bridge > domains need be connected. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-zhang-l2vpn-vpls-bd-tagging/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-zhang-l2vpn-vpls-bd-tagging-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l2vpn-vpls-bd-tagging-01 > > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Feb 21 00:05:00 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDA51A0132 for ; Fri, 21 Feb 2014 00:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MG313-6Q0NL for ; Fri, 21 Feb 2014 00:04:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 886391A005B for ; Fri, 21 Feb 2014 00:04:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBI84333; Fri, 21 Feb 2014 08:04:54 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:04:37 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:04:53 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.180]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 16:04:51 +0800 From: Mingui Zhang To: "l2vpn@ietf.org" Subject: Recall: Pease read and comment//FW: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt Thread-Topic: Pease read and comment//FW: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt Thread-Index: Ac8u25goaSOstAPL2EecTUfYvrxjqA== X-CallingTelephoneNumber: IPM.Note X-VoiceMessageDuration: 1 X-FaxNumberOfPages: 0 Date: Fri, 21 Feb 2014 08:04:50 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73369FFBF@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vZCXSznp7RCBnxZMWKhnVqze_yY X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:05:00 -0000 Mingui Zhang would like to recall the message, "Pease read and comment//FW:= I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt".= From nobody Fri Feb 21 00:39:38 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A085A1A000B for ; Fri, 21 Feb 2014 00:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqZ0OgA4qKQY for ; Fri, 21 Feb 2014 00:39:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F246E1A04E8 for ; Fri, 21 Feb 2014 00:39:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBI87231; Fri, 21 Feb 2014 08:39:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:39:11 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:39:28 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.180]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 16:39:22 +0800 From: Mingui Zhang To: "l2vpn@ietf.org" Subject: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Topic: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Index: Ac8u4Gqu/H9yqftdSB2s9awjRmSgCw== Date: Fri, 21 Feb 2014 08:39:22 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73369FFF1@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/BYp-S1UPDBrfbNb6FMQOrq4M8jc X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:39:37 -0000 Hi, Service providers are facing a heavy provisioning overhead in VPLS since a = mass of PWs need to be maintained. If PEs can use Customer VLAN ID as a ser= vice discriminator in VPLS, the required number of PWs will be greatly redu= ced. Therefore, the provision overhead can be significantly relieved. Authors compose the draft to justify the solutions on recognizing Customer = VLAN IDs in VPLS. We wish to receive your comments and suggestions.=20 Thanks, Mingui >-----Original Message----- >From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 >internet-drafts@ietf.org >Sent: Friday, February 14, 2014 5:10 PM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > > Title : Tagging Customer Bridge Domains in VPLS > Authors : Mingui Zhang > Bin Wang > Liang Xia > Jie Hu > Filename : draft-zhang-l2vpn-vpls-bd-tagging-01.txt > Pages : 8 > Date : 2014-02-14 > >Abstract: > This document proposes to use Customer VLAN ID as a identifier for > traffic isolation in Virtual Private LAN Service (VPLS). In this way, > multiple bridge domains of customers can share a single VPLS instance > while their traffic are separated. With this proposal, Service > Providers can be relieved from the heavy provisioning overhead of > large number of pseudowires in the environment where a mass of bridge > domains need be connected. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-zhang-l2vpn-vpls-bd-tagging/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-zhang-l2vpn-vpls-bd-tagging-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l2vpn-vpls-bd-tagging-01 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at tools.ietf= .org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Feb 21 03:27:53 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED701A0519 for ; Fri, 21 Feb 2014 03:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyVk-9amuHPX for ; Fri, 21 Feb 2014 03:27:49 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 81E401A04E9 for ; Fri, 21 Feb 2014 03:27:49 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 23837035.2b8702429940.2413577.00-2434.6805441.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 21 Feb 2014 11:27:46 +0000 (UTC) X-MXL-Hash: 5307383219f05476-5cb545bc0d69232b1db9410ef44f0a2c66bcd8f8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 72837035.0.2413536.00-2336.6805316.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 21 Feb 2014 11:27:37 +0000 (UTC) X-MXL-Hash: 530738296405ab08-b70666d7fab26169d24731d9a3fbf4c39bef5ffe Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LBRYgB025876; Fri, 21 Feb 2014 06:27:34 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LBRRfS025844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 06:27:30 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 21 Feb 2014 11:27:20 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 06:27:20 -0500 From: "UTTARO, JAMES" To: Mingui Zhang , "l2vpn@ietf.org" Subject: RE: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Topic: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Index: Ac8u4Gqu/H9yqftdSB2s9awjRmSgCwAFtv5A Date: Fri, 21 Feb 2014 11:27:19 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E73369FFF1@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E73369FFF1@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.138.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OL2QK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=4WijGsFk-CkA:10 a=ofMgfj31e3cA:10 a=F4jEe0iCTpwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=8UtOOl-MPwsA:10 a=48vgC7mUAAAA:8 a=C3X6C57q9iJrDW] X-AnalysisOut: [cCum8A:9 a=CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=8y2B7u0mA38moT9-:21 a=EesadEb-C9qjkY5j:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ZqRTEdZK35mDBoi697iaG_IAVfA X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 11:27:52 -0000 The assumption being that the majority of customer are building more than a= two or three point VPLS domain.. My experience does not indicate that VPLS= is a service that supports many endpoints per VPLS VPN. Anyway why not sim= ply use EVPN for this purpose? There are no PWs, traffic traverses the sam= e LSPs used for any other service.=20 Jim Uttaro -----Original Message----- From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Friday, February 21, 2014 3:39 AM To: l2vpn@ietf.org Subject: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Hi, Service providers are facing a heavy provisioning overhead in VPLS since a = mass of PWs need to be maintained. If PEs can use Customer VLAN ID as a ser= vice discriminator in VPLS, the required number of PWs will be greatly redu= ced. Therefore, the provision overhead can be significantly relieved. Authors compose the draft to justify the solutions on recognizing Customer = VLAN IDs in VPLS. We wish to receive your comments and suggestions.=20 Thanks, Mingui >-----Original Message----- >From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 >internet-drafts@ietf.org >Sent: Friday, February 14, 2014 5:10 PM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > > Title : Tagging Customer Bridge Domains in VPLS > Authors : Mingui Zhang > Bin Wang > Liang Xia > Jie Hu > Filename : draft-zhang-l2vpn-vpls-bd-tagging-01.txt > Pages : 8 > Date : 2014-02-14 > >Abstract: > This document proposes to use Customer VLAN ID as a identifier for > traffic isolation in Virtual Private LAN Service (VPLS). In this way, > multiple bridge domains of customers can share a single VPLS instance > while their traffic are separated. With this proposal, Service > Providers can be relieved from the heavy provisioning overhead of > large number of pseudowires in the environment where a mass of bridge > domains need be connected. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-zhang-l2vpn-vpls-bd-tagging/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-zhang-l2vpn-vpls-bd-tagging-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l2vpn-vpls-bd-tagging-01 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at tools.ietf= .org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Feb 21 05:14:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E91A00B2 for ; Fri, 21 Feb 2014 05:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpVUl5TIsz54 for ; Fri, 21 Feb 2014 05:14:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE81A00B8 for ; Fri, 21 Feb 2014 05:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=441; q=dns/txt; s=iport; t=1392988438; x=1394198038; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ngfB9UAh3cQXNkGargSEBritn/No9YzppB5ncdSxakE=; b=hQnkM/+/zybTg3eeUn7glBY5OyhT2+zxHuNBfYDxR2M3R6AoMhYTOgUJ nfmg7Su/a95x0McMudS2piNXaD8I33GqC0BeK6JjxVsv1TNAwEG26pgMT B0gvDcTkCz4LUyoqH1zSu3a8bm5zkBx47sDi6Hn5QHpNd0dUcmV9W03zf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFACZQB1OtJXG9/2dsb2JhbABZgwaBEsA5gRAWdIImAQEEgQkCAU4yJQIEiBjLYheOAhEBV4MkgRQEiRCPJJIngy2BcTk X-IronPort-AV: E=Sophos;i="4.97,519,1389744000"; d="scan'208";a="305694357" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2014 13:13:57 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1LDDvcL013451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 13:13:57 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 07:13:57 -0600 From: "Andrew McLachlan (amclachl)" To: "l2vpn@ietf.org" Subject: IETF 89 - Presentation submission and final agenda dates Thread-Topic: IETF 89 - Presentation submission and final agenda dates Thread-Index: AQHPLwbG3D+20TdELEi3bgXGLFnvVw== Date: Fri, 21 Feb 2014 13:13:56 +0000 Message-ID: <8CE2733B-7E70-46CD-9E8E-03CFAF51DEC3@cisco.com> References: <19256ABF-F669-4AC9-A9B2-D5563C3D20EB@cisco.com> <2ADDEC61-9429-436C-A158-20D0E38C3834@cisco.com> In-Reply-To: <2ADDEC61-9429-436C-A158-20D0E38C3834@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.81.215] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8BC0176F921AAD46B64370ECD8A1A3AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ZwkKqWW6N_iKopkGd5Wa_L4M9eg X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 13:14:04 -0000 Dear all=20 Key cut off dates for IETF 89 L2VPN are as follows. Presentations - Friday 28th Feb 2014 Agenda Cutoff - Monday 24th Feb 2014 Please email your slides to either Giles, Nabil or myself before the cut of= f.=20 Also please focus your presentations on the key points you wish to make, ch= anges and/or updates to a draft etc, instead of a blow by blow detail of wh= at a draft contains.=20 cheers Andrew= From nobody Fri Feb 21 08:20:00 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E56D1A0351 for ; Fri, 21 Feb 2014 08:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehBL_AMCLGsf for ; Fri, 21 Feb 2014 08:19:49 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 532FB1A01EC for ; Fri, 21 Feb 2014 08:19:49 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-69-53077ca1a046 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 77.90.11484.1AC77035; Fri, 21 Feb 2014 17:19:45 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Fri, 21 Feb 2014 11:19:43 -0500 From: Jeff Tantsura To: "UTTARO, JAMES" , Mingui Zhang , "l2vpn@ietf.org" Subject: Re: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Topic: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Index: Ac8u4Gqu/H9yqftdSB2s9awjRmSgCwAFtv5AAAQUXAA= Date: Fri, 21 Feb 2014 16:19:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXSPt+7CGvZggz87FSyezzrAavH42yF2 iytzG9kcmD1e9s9h9Gg58pbVY8mSn0wBzFFcNimpOZllqUX6dglcGZObNQreSlfs2fqBvYFx n1gXIyeHhICJxO1/c5ghbDGJC/fWs3UxcnEICRxhlFh98SEjhLOcUaLr028mkCo2AQOJ/9+O s4DYIgIFEpc+3wTq5uAQFvCWaOwKhwj7SEz6uZgVwraSON7UwQZiswioSvy+OZ0RxOYVMJfo vzWPHaSVUyBK4s0HWZAwI9AN30+tAdvELCAucevJfCaI2wQkluw5D3WnqMTLx//AxosK6Em0 HTvDDhFXkpi09BwrRK+OxILdn9ggbGuJ7x272SFsbYllC18zQ5wgKHFy5hOWCYxis5Csm4Wk fRaS9llI2mchaV/AyLqKkaO0OLUsN93IcBMjMJqOSbA57mBc8MnyEKM0B4uSOO+Xt85BQgLp iSWp2ampBalF8UWlOanFhxiZODilGhinL8j0nzgjnIv54o2FFw4xvnvbtZV7Z8Dujedy3dqZ H112rWhSFv3sNlH3OF+apM6bDU9Vmja9/xCUZvNqqvK2INN0wflzXC4+vNCysn/5gtPfpH9F i6T0qO/fe0Mi4czOCVdvKlizVvU/vZ11la8vUv62y4Ufn9InPXzCfG+hyS2rh27arT9zlFiK MxINtZiLihMBlVYleHQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/NDTmUSSX9nZGdFdnuBGDgC0QzSk X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:19:57 -0000 I fully subscribe to Jim's point of view. Cheers, Jeff -----Original Message----- From: , JAMES Date: Friday, February 21, 2014 3:27 AM To: Mingui Zhang , "l2vpn@ietf.org" Subject: RE: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" >The assumption being that the majority of customer are building more than >a two or three point VPLS domain.. My experience does not indicate that >VPLS is a service that supports many endpoints per VPLS VPN. Anyway why >not simply use EVPN for this purpose? There are no PWs, traffic >traverses the same LSPs used for any other service. > >Jim Uttaro > >-----Original Message----- >From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Mingui Zhang >Sent: Friday, February 21, 2014 3:39 AM >To: l2vpn@ietf.org >Subject: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" > >Hi, > >Service providers are facing a heavy provisioning overhead in VPLS since >a mass of PWs need to be maintained. If PEs can use Customer VLAN ID as a >service discriminator in VPLS, the required number of PWs will be greatly >reduced. Therefore, the provision overhead can be significantly relieved. > >Authors compose the draft to justify the solutions on recognizing >Customer VLAN IDs in VPLS. We wish to receive your comments and >suggestions.=20 > >Thanks, >Mingui > >>-----Original Message----- >>From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>internet-drafts@ietf.org >>Sent: Friday, February 14, 2014 5:10 PM >>To: i-d-announce@ietf.org >>Subject: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Tagging Customer Bridge Domains in VPLS >> Authors : Mingui Zhang >> Bin Wang >> Liang Xia >> Jie Hu >> Filename : draft-zhang-l2vpn-vpls-bd-tagging-01.txt >> Pages : 8 >> Date : 2014-02-14 >> >>Abstract: >> This document proposes to use Customer VLAN ID as a identifier for >> traffic isolation in Virtual Private LAN Service (VPLS). In this way, >> multiple bridge domains of customers can share a single VPLS instance >> while their traffic are separated. With this proposal, Service >> Providers can be relieved from the heavy provisioning overhead of >> large number of pseudowires in the environment where a mass of bridge >> domains need be connected. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-zhang-l2vpn-vpls-bd-tagging/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-zhang-l2vpn-vpls-bd-tagging-01 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l2vpn-vpls-bd-tagging-01 >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Feb 21 08:29:31 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68261A048B for ; Fri, 21 Feb 2014 08:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg5m0UxdFEZB for ; Fri, 21 Feb 2014 08:29:28 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 93DA21A0466 for ; Fri, 21 Feb 2014 08:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1393000165; x=1394209765; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Km2OcEaM06FuJsPUkCzEZstdvrLWMj/7S6F7XlX+J1o=; b=IHILMQDqSZLvAfs3A8Gp2Qkr/rzNWr+aHyjcvwW8tNnPOggi6URmQiSZ aOjUzYhgVyL+L7A/o4kM6V2MjFHFAC6oM75NPS8Z6RrbxcFY4Knnsliks BmID8ZN5hqgEkBrToTs3oTonsq8WM27XGkURvFO/FNqOShbW6WW6CYvWB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAA9+B1OtJV2c/2dsb2JhbABagmUhO1EGwD2BDhZ0giUBAQEEAQEBNzQXBgEIEQMBAQENEgkuCxQJCAEBBAESCRKHagEHBcthF445LQUGhDIEmDSBMosxhUSDLYIq X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="22212949" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 21 Feb 2014 16:29:24 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1LGTOPl026202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 16:29:24 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 10:29:23 -0600 From: "Ali Sajassi (sajassi)" To: Jeff Tantsura , "UTTARO, JAMES" , Mingui Zhang , "l2vpn@ietf.org" Subject: Re: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Topic: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Index: Ac8u4Gqu/H9yqftdSB2s9awjRmSgCwAFtv5AAAQUXAAAAm4ggA== Date: Fri, 21 Feb 2014 16:29:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.69.231] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/_V50M7ofORiOnhPfrfwE9uLRW1Q X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:29:30 -0000 Two points: 1) First vlan-aware bundle service is already supported in EVPN and per Jim's suggestion "why not simply use EVPN". 2) Second, there is already a draft published about a year and half ago to address this issue for VPLS :-) http://tools.ietf.org/id/draft-cai-l2vpn-vpls-vlan-aware-bundling-00.txt Cheers, Ali On 2/21/14 8:19 AM, "Jeff Tantsura" wrote: >I fully subscribe to Jim's point of view. > >Cheers, >Jeff > > >-----Original Message----- >From: , JAMES >Date: Friday, February 21, 2014 3:27 AM >To: Mingui Zhang , "l2vpn@ietf.org" > >Subject: RE: Ask for comments on >"draft-zhang-l2vpn-vpls-bd-tagging-01.txt" > >>The assumption being that the majority of customer are building more than >>a two or three point VPLS domain.. My experience does not indicate that >>VPLS is a service that supports many endpoints per VPLS VPN. Anyway why >>not simply use EVPN for this purpose? There are no PWs, traffic >>traverses the same LSPs used for any other service. >> >>Jim Uttaro >> >>-----Original Message----- >>From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Mingui Zhang >>Sent: Friday, February 21, 2014 3:39 AM >>To: l2vpn@ietf.org >>Subject: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" >> >>Hi, >> >>Service providers are facing a heavy provisioning overhead in VPLS since >>a mass of PWs need to be maintained. If PEs can use Customer VLAN ID as a >>service discriminator in VPLS, the required number of PWs will be greatly >>reduced. Therefore, the provision overhead can be significantly relieved. >> >>Authors compose the draft to justify the solutions on recognizing >>Customer VLAN IDs in VPLS. We wish to receive your comments and >>suggestions.=20 >> >>Thanks, >>Mingui >> >>>-----Original Message----- >>>From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>>internet-drafts@ietf.org >>>Sent: Friday, February 14, 2014 5:10 PM >>>To: i-d-announce@ietf.org >>>Subject: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : Tagging Customer Bridge Domains in VPLS >>> Authors : Mingui Zhang >>> Bin Wang >>> Liang Xia >>> Jie Hu >>> Filename : draft-zhang-l2vpn-vpls-bd-tagging-01.txt >>> Pages : 8 >>> Date : 2014-02-14 >>> >>>Abstract: >>> This document proposes to use Customer VLAN ID as a identifier for >>> traffic isolation in Virtual Private LAN Service (VPLS). In this way, >>> multiple bridge domains of customers can share a single VPLS instance >>> while their traffic are separated. With this proposal, Service >>> Providers can be relieved from the heavy provisioning overhead of >>> large number of pseudowires in the environment where a mass of bridge >>> domains need be connected. >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-zhang-l2vpn-vpls-bd-tagging/ >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-zhang-l2vpn-vpls-bd-tagging-01 >>> >>>A diff from the previous version is available at: >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l2vpn-vpls-bd-tagging-01 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>Internet-Draft directories: http://www.ietf.org/shadow.html or >>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > From nobody Fri Feb 21 10:43:43 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F911A04AD; Fri, 21 Feb 2014 10:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD6GEOVfDpTr; Fri, 21 Feb 2014 10:43:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 696321A0533; Fri, 21 Feb 2014 10:43:38 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mib-15.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140221184338.12874.93004.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2014 10:43:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/zY4xlzr5-Y2Pj4zqifBKv2IF8_w Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:43:40 -0000 --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 (VPLS) Management Information Base Author(s) : T. Nadeau, et al Filename : draft-ietf-l2vpn-vpls-mib Pages : 48 Date : 2014-02-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with The Pseudowire (PW) Management Information Base. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mib-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-l2vpn-vpls-mib"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-21104338.I-D@ietf.org> --NextPart-- From nobody Fri Feb 21 18:38:45 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9B1A0103 for ; Fri, 21 Feb 2014 18:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU-Liud-MPgV for ; Fri, 21 Feb 2014 18:38:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 09FB71A0373 for ; Fri, 21 Feb 2014 18:38:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDV48510; Sat, 22 Feb 2014 02:38:33 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 02:38:11 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 02:38:31 +0000 Received: from NKGEML508-MBS.china.huawei.com ([169.254.8.12]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 10:38:28 +0800 From: Mingui Zhang To: "Ali Sajassi (sajassi)" , Jeff Tantsura , "UTTARO, JAMES" , "l2vpn@ietf.org" Subject: RE: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Topic: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" Thread-Index: Ac8u4Gqu/H9yqftdSB2s9awjRmSgCwAFtv5AAAQUXAAAAm4ggAAXwTrg Date: Sat, 22 Feb 2014 02:38:28 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7336A9BD5@nkgeml508-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/2XWmOlS_S3lO1fhkNmj7c1mOOQA X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 02:38:44 -0000 Hi Jim, Jeff and Ali, Thanks for your comments! Please let me reply all your comments in this ema= il. 1) First, I approve EVPN is a good choice. However, we cannot let all servi= ce providers wait for its coming out. The bd-tagging approach can serve as = the transitional technique. Since VPLS networks are widely deployed in prac= tice, a mass of such devices will act as legacy devices for years. So this = proposal is still valid for those legacy networks.=20 2) Second, I knew the draft on vlan-aware-bundling. If you read through our= draft, you will find the vlan-aware-bundling proposal was included as an e= nabling technique. In other words, our draft is proposed to justify that ki= nd of proposals. As you may know, besides LDP extension, some vendors also = implemented the U-tag recognizing feature in VPLS utilizing VLAN Registrati= on Protocols, such as MVRP. The U-tag recognizing feature is required by lots of VPLS service providers= . And I know vendors have already provided this feature in their VPLS produ= cts. Thanks, Mingui=20 >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Saturday, February 22, 2014 12:29 AM >To: Jeff Tantsura; UTTARO, JAMES; Mingui Zhang; l2vpn@ietf.org >Subject: Re: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt= " > > >Two points: > >1) First vlan-aware bundle service is already supported in EVPN and per Ji= m's >suggestion "why not simply use EVPN". > >2) Second, there is already a draft published about a year and half ago to >address this issue for VPLS :-) >http://tools.ietf.org/id/draft-cai-l2vpn-vpls-vlan-aware-bundling-00.txt > >Cheers, >Ali > > > >On 2/21/14 8:19 AM, "Jeff Tantsura" wrote: > >>I fully subscribe to Jim's point of view. >> >>Cheers, >>Jeff >> >> >>-----Original Message----- >>From: , JAMES >>Date: Friday, February 21, 2014 3:27 AM >>To: Mingui Zhang , "l2vpn@ietf.org" >> >>Subject: RE: Ask for comments on >>"draft-zhang-l2vpn-vpls-bd-tagging-01.txt" >> >>>The assumption being that the majority of customer are building more >>>than a two or three point VPLS domain.. My experience does not >>>indicate that VPLS is a service that supports many endpoints per VPLS >>>VPN. Anyway why not simply use EVPN for this purpose? There are no >>>PWs, traffic traverses the same LSPs used for any other service. >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Mingui Zhang >>>Sent: Friday, February 21, 2014 3:39 AM >>>To: l2vpn@ietf.org >>>Subject: Ask for comments on "draft-zhang-l2vpn-vpls-bd-tagging-01.txt" >>> >>>Hi, >>> >>>Service providers are facing a heavy provisioning overhead in VPLS >>>since a mass of PWs need to be maintained. If PEs can use Customer >>>VLAN ID as a service discriminator in VPLS, the required number of PWs >>>will be greatly reduced. Therefore, the provision overhead can be signif= icantly >relieved. >>> >>>Authors compose the draft to justify the solutions on recognizing >>>Customer VLAN IDs in VPLS. We wish to receive your comments and >>>suggestions. >>> >>>Thanks, >>>Mingui >>> >>>>-----Original Message----- >>>>From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf >>>>Of internet-drafts@ietf.org >>>>Sent: Friday, February 14, 2014 5:10 PM >>>>To: i-d-announce@ietf.org >>>>Subject: I-D Action: draft-zhang-l2vpn-vpls-bd-tagging-01.txt >>>> >>>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>directories. >>>> >>>> >>>> Title : Tagging Customer Bridge Domains in VPLS >>>> Authors : Mingui Zhang >>>> Bin Wang >>>> Liang Xia >>>> Jie Hu >>>> Filename : draft-zhang-l2vpn-vpls-bd-tagging-01.txt >>>> Pages : 8 >>>> Date : 2014-02-14 >>>> >>>>Abstract: >>>> This document proposes to use Customer VLAN ID as a identifier for >>>> traffic isolation in Virtual Private LAN Service (VPLS). In this way= , >>>> multiple bridge domains of customers can share a single VPLS instanc= e >>>> while their traffic are separated. With this proposal, Service >>>> Providers can be relieved from the heavy provisioning overhead of >>>> large number of pseudowires in the environment where a mass of bridg= e >>>> domains need be connected. >>>> >>>> >>>>The IETF datatracker status page for this draft is: >>>>https://datatracker.ietf.org/doc/draft-zhang-l2vpn-vpls-bd-tagging/ >>>> >>>>There's also a htmlized version available at: >>>>http://tools.ietf.org/html/draft-zhang-l2vpn-vpls-bd-tagging-01 >>>> >>>>A diff from the previous version is available at: >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l2vpn-vpls-bd-tagging-01 >>>> >>>> >>>>Please note that it may take a couple of minutes from the time of >>>>submission until the htmlized version and diff are available at >>>>tools.ietf.org. >>>> >>>>Internet-Drafts are also available by anonymous FTP at: >>>>ftp://ftp.ietf.org/internet-drafts/ >>>> >>>>_______________________________________________ >>>>I-D-Announce mailing list >>>>I-D-Announce@ietf.org >>>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>>Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> From nobody Tue Feb 25 12:52:32 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C621A0810; Tue, 25 Feb 2014 12:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUlifzNdIu8Q; Tue, 25 Feb 2014 12:52:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3EA1A081F; Tue, 25 Feb 2014 12:52:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Virtual Private Lan Services (VPLS) Management Information Base' to Proposed Standard (draft-ietf-l2vpn-vpls-mib-15.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140225205213.9349.29668.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2014 12:52:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/8hegnvHj-YaTra0vrKMtLo_fSqY Cc: l2vpn mailing list , l2vpn chair , RFC Editor X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:52:26 -0000 The IESG has approved the following document: - 'Virtual Private Lan Services (VPLS) Management Information Base' (draft-ietf-l2vpn-vpls-mib-15.txt) as Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-mib/ Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with The Pseudowire (PW) Management Information Base. Working Group Summary This document is an L2VPN Working Group document, adopted in August 2007, and which passed WG last call in July 2010. The doc was well reviewed in the WG up to WG last call, and has subsequently been further reviewed by the WG chairs and by a MIB doctor. We believe it is now stable and complete. Document Quality In the view of the chairs the document is now of sufficient quality to be published as an RFC. There are now multiple implementations by multiple vendors. Personnel Document Shepherd: Giles Heron (giheron@cisco.com) Area Director: Stewart Bryant (stbryant@cisco.com) From nobody Thu Feb 27 07:46:39 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E970D1A0328 for ; Thu, 27 Feb 2014 07:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV3gW0SFcuJA for ; Thu, 27 Feb 2014 07:46:36 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id D887A1A031B for ; Thu, 27 Feb 2014 07:46:35 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wp18so880549obc.35 for ; Thu, 27 Feb 2014 07:46:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=758uV7BD08hNPghgNHgezlIcaBpN2sedQ+dVAIPbGpM=; b=B5q63QcChGZQFXltCRAxcEOg3p2i45haTMKu5DnXumjFOg/rgJt0oT0jORHv9iIVd+ hKGyfc/Xk4Ixz9+naKOBe0laliLcfMBC1k/1rB9k+KGZYBOED/QerttnplIjEYe+z9ZB MT0fxtVgRwFgT1ppD4BDFyXBhU2NWNGNrKnlW1ypIpdyvd0WHvKFbwwsVhRVDmOOadFD aazdxSuTKS1SVYHplEJMM0pCr/s74F+yiVkP7UsMn/hOEUIYePzpBqFHjIeWGbNEn0JY 8fvkEfY7Fm5v4yaDinXnZ3b9h9OjybonmjnTPSUtUcp+ACpk/CGfo6cajct38g8rMmiq ZwIw== X-Gm-Message-State: ALoCoQm7A667y2WAGR7Lh42+WTBX3abbtZzmyQjoowg9WyGNLap2+mjUOA1FIUIE4eitbA4pw8KX MIME-Version: 1.0 X-Received: by 10.182.112.130 with SMTP id iq2mr7572052obb.57.1393515994261; Thu, 27 Feb 2014 07:46:34 -0800 (PST) Received: by 10.76.169.7 with HTTP; Thu, 27 Feb 2014 07:46:34 -0800 (PST) Date: Thu, 27 Feb 2014 07:46:34 -0800 Message-ID: Subject: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Kanwar Singh To: l2vpn@ietf.org Content-Type: multipart/alternative; boundary=089e01229a06d3db9b04f3653918 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/WgICrZVOTowZrVOv8aTzzaBJ4j0 Cc: Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:46:38 -0000 --089e01229a06d3db9b04f3653918 Content-Type: text/plain; charset=ISO-8859-1 Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Failure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --089e01229a06d3db9b04f3653918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

We have submitted the below d= raft that proposes Generic OAM and Datapath Failure Detection Mechanism(s) = for Overlay Networks.

We would like to solicit inp= uts from the members of L2VPN WG.

Please review the= same and update us with your inputs/feedback.

Warm Regards
- Kanwar


A new version =
of I-D, draft-jain-nvo3-overlay-oam-01.txt=A0has bee=
n successfully submitted by Kanwar Singh and posted to the
IETF repository.



Name: =A0 =A0 =A0 =A0 =A0 draft-jain-nvo3-overlay-oam

Revision: =A0 =A0 =A0 01
Title: =A0 =A0 =A0 =A0 =A0Generic =
Overlay OAM and Datapath Failure Detection


Document date: =A02014-02-12

Group: =A0 =A0 =A0 =A0 =A0Individual Submission

Pages: =A0 =A0 =A0 =A0 =A044
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-jain=
-nvo3-overlay-oam-01.txt


Status: =A0 =A0 =A0 =A0=A0https://datatracker.iet=
f.org/doc/draft-jain-nvo3-overlay-oam/


Htmlized: =A0 =A0 =A0http://tools.ietf.org/html/draft=
-jain-nvo3-overlay-oam-01


Diff: =A0 =A0 =A0 =A0 =A0=A0 =A0=A0http://www=
.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01



Abstract:


=A0 =A0This proposal describes a mechanism that can be used to detect D=
ata


=A0 =A0Path Failures of various overlay technologies as VXLAN, NVGRE,


=A0 =A0MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and =
Data


=A0 =A0Plane for given Overlay Segment. =A0This document defines the fo=
llowing


=A0 =A0for each of the above Overlay Technologies:


=A0 =A0o =A0Encapsulation of OAM Packet, such that it has same Outer =
and


=A0 =A0 =A0 Overlay Header as any End-System's data going over the =
same


=A0 =A0 =A0 Overlay Segment.


=A0 =A0o =A0The mechanism to trace the Underlay that is exercised by =
any


=A0 =A0 =A0 Overlay Segment.


=A0 =A0o =A0Procedure to verify presence of any given Tenant VM or En=
d-System


=A0 =A0 =A0 within a given Overlay Segment at Overlay End-Point.=



=A0 =A0Even though the present proposal addresses Overlay OAM for VXL=
AN,


=A0 =A0NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are


=A0 =A0generic enough to accommodate OAM for any other Overlay Technolo=
gy.
--089e01229a06d3db9b04f3653918-- From nobody Thu Feb 27 07:58:17 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FA71A033E for ; Thu, 27 Feb 2014 07:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHhq-t66xCXK for ; Thu, 27 Feb 2014 07:58:10 -0800 (PST) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6F1A00B2 for ; Thu, 27 Feb 2014 07:58:10 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,555,1389772800"; d="scan'208,217"; a="16696187" Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw3-out.broadcom.com with ESMTP; 27 Feb 2014 08:09:47 -0800 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 07:58:08 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 07:58:08 -0800 From: Shahram Davari To: Kanwar Singh Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mh8gEtCy0e4EuWLz1WxAmt5prJQcOt Date: Thu, 27 Feb 2014 15:58:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B23247FA7CED4F788858076CA83F613Cbroadcomcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/O_uNJbX9xEZFFZxjZQ9h6QyS4tI Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:58:16 -0000 --_000_B23247FA7CED4F788858076CA83F613Cbroadcomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_B23247FA7CED4F788858076CA83F613Cbroadcomcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us = with your inputs/feedback.

Warm Regards
- Kanwar


A new version of I-D, draft-jain-nv=
o3-overlay-oam-01.txt has been successfully subm=
itted by Kanwar Singh and posted to the
IETF repository.



Name:           draft-jain-nvo3-overlay-oam

Revision:       01
Title:     &nbs=
p;    Generic Overlay OAM and Datapath Failure Detection

Document date:  2014-02-12

Group:          Individual Submission
Pages:          44
URL:   &nb=
sp;        http://www.ie=
tf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt


Status:         https:/=
/datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/


Htmlized:      http://tools.ietf.org/h=
tml/draft-jain-nvo3-overlay-oam-01


Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oa=
m-01



Abstract:


   This proposal describes a mechanism that can be used to de=
tect Data


   Path Failures of various overlay technologies as VXLAN, NV=
GRE,


   MPLSoGRE and MPLSoUDP and verifying/sanity of their Contro=
l and Data


   Plane for given Overlay Segment.  This document defin=
es the following


   for each of the above Overlay Technologies:


   o  Encapsulation of OAM Packet, such that it has sa=
me Outer and


      Overlay Header as any End-System's data going over=
 the same


      Overlay Segment.


   o  The mechanism to trace the Underlay that is exer=
cised by any


      Overlay Segment.


   o  Procedure to verify presence of any given Tenant=
 VM or End-System


      within a given Overlay Segment at Overlay End-Poin=
t.


   Even though the present proposal addresses Overlay OAM f=
or VXLAN,


   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described=
 are


   generic enough to accommodate OAM for any other Overlay Te=
chnology.
--_000_B23247FA7CED4F788858076CA83F613Cbroadcomcom_-- From nobody Thu Feb 27 08:02:57 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A0E1A038C for ; Thu, 27 Feb 2014 08:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPItCt8c-dtN for ; Thu, 27 Feb 2014 08:02:53 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 324141A0361 for ; Thu, 27 Feb 2014 08:02:53 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1RG2lpr003653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 10:02:49 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1RG2kmL022206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:02:46 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:02:46 +0100 From: "Henderickx, Wim (Wim)" To: Shahram Davari , Kanwar Singh Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9MqTlu9S0SqbE+B4eOK279kpJrJMP6AgAASA4A= Date: Thu, 27 Feb 2014 16:02:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_CF351FD5B21EAwimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/zQMCzjRzj4UhOp_nP3LJxU1TSqE Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:02:56 -0000 --_000_CF351FD5B21EAwimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF351FD5B21EAwimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <564EA5764A0F6C4EB76296CA7B144EAF@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:= 58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar


A new version of I-D, draft-=
jain-nvo3-overlay-oam-01.txt has b=
een successfully submitted by Kanwar Singh and posted to the
IETF repository.
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; white-space:=
 normal;">Name:           draft-jain-nvo3-overlay-=
oam
Revision:       01
Title:          Generic Overlay OAM and Datapath =
Failure Detection
Document date:  2014-02-12=

Group:          Individual Submission=

Pages:          44
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-0=
1.txt
Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/=

Htmlized:      http://tools.i=
etf.org/html/draft-jain-nvo3-overlay-oam-01
Diff:   &n=
bsp;          http:=
//www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   Pa=
th Failures of various overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of their Contr=
ol and Data
   Plane for given Overlay Segment=
.  This document defines the following
   =
;for each of the above Overlay Technologies:

  &n=
bsp;o  Encapsulation of OAM Packet, such that it has same Outer and
      Overlay Header as any End-System's da=
ta going over the same
      Overlay Segm=
ent.

   o  The mechanism to trace the U=
nderlay that is exercised by any
      Ov=
erlay Segment.

   o  Procedure to verif=
y presence of any given Tenant VM or End-System
  &=
nbsp;   within a given Overlay Segment at Overlay End-Point.<=
br style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"=
>   Even though the present proposal addresses Overlay=
 OAM for VXLAN,
   NVGRE, MPLSoGRE and MPLSoUD=
P, but the procedures described are
   generic=
 enough to accommodate OAM for any other Overlay Technology.
 --_000_CF351FD5B21EAwimhenderickxalcatellucentcom_-- From nobody Thu Feb 27 08:04:05 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199EB1A0382 for ; Thu, 27 Feb 2014 08:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS4M2hpKeN6G for ; Thu, 27 Feb 2014 08:03:53 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9101A0395 for ; Thu, 27 Feb 2014 08:03:53 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 145C5270AFB0; Thu, 27 Feb 2014 11:03:51 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_1C7DE350-0450-4D97-BEF8-E2FEB7785CDF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Thomas Nadeau In-Reply-To: Date: Thu, 27 Feb 2014 11:03:49 -0500 Message-Id: <9F1DDAAE-BF29-48A8-BFDD-960F8F5A65F3@lucidvision.com> References: To: Shahram Davari X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/1rh6OiuAVsle5BtMGzXyIk8Rdmw Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:03:59 -0000 --Apple-Mail=_1C7DE350-0450-4D97-BEF8-E2FEB7785CDF Content-Type: multipart/alternative; boundary="Apple-Mail=_9127BB88-33AC-4032-898C-53B9719FB27E" --Apple-Mail=_9127BB88-33AC-4032-898C-53B9719FB27E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I had precisely the same question. Most DCs simply use IP/Enet = which allow for the use of the "regular suspects" in the tools = department.=20 The other concern I have with specifying new tools on top of the = underlay is that the underlay probably is running some diag tools for = failure detection/trouble-shooting too (like Ethernet OAM/BFD/etc...), = so once again we have the issue to consider of OAM traffic consuming = significant amounts of actual BW. Given how modern applications are = built and run, its unlikely we need anything heavy weight in the overlay = and can instead allow for application resiliency to handle failure = detection, and instead have the "normal" tools available for = trouble-shooting on an as-needed basis. --Tom > Hi >=20 > Why don't you use existing IP based OAM messages such as BFD, OWAMP, = TWAMP, etc. >=20 > Regards, > Shahram >=20 >=20 > On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" = wrote: >=20 >> Dear All, >>=20 >> We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks. >>=20 >> We would like to solicit inputs from the members of L2VPN WG. >>=20 >> Please review the same and update us with your inputs/feedback. >>=20 >> Warm Regards >> - Kanwar >>=20 >>=20 >> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been = successfully submitted by Kanwar Singh and posted to the >> IETF repository. >>=20 >>=20 >>=20 >> Name: draft-jain-nvo3-overlay-oam >>=20 >> Revision: 01 >> Title: Generic Overlay OAM and Datapath Failure Detection >>=20 >>=20 >> Document date: 2014-02-12 >>=20 >> Group: Individual Submission >>=20 >> Pages: 44 >> URL: = http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt >>=20 >>=20 >> Status: = https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ >>=20 >>=20 >> Htmlized: = http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 >>=20 >>=20 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01 >>=20 >>=20 >>=20 >> Abstract: >>=20 >>=20 >> This proposal describes a mechanism that can be used to detect = Data >>=20 >>=20 >> Path Failures of various overlay technologies as VXLAN, NVGRE, >>=20 >>=20 >> MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and = Data >>=20 >>=20 >> Plane for given Overlay Segment. This document defines the = following >>=20 >>=20 >> for each of the above Overlay Technologies: >>=20 >>=20 >> o Encapsulation of OAM Packet, such that it has same Outer and >>=20 >>=20 >> Overlay Header as any End-System's data going over the same >>=20 >>=20 >> Overlay Segment. >>=20 >>=20 >> o The mechanism to trace the Underlay that is exercised by any >>=20 >>=20 >> Overlay Segment. >>=20 >>=20 >> o Procedure to verify presence of any given Tenant VM or = End-System >>=20 >>=20 >> within a given Overlay Segment at Overlay End-Point. >>=20 >>=20 >> Even though the present proposal addresses Overlay OAM for VXLAN, >>=20 >>=20 >> NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are >>=20 >>=20 >> generic enough to accommodate OAM for any other Overlay = Technology. >>=20 >>=20 --Apple-Mail=_9127BB88-33AC-4032-898C-53B9719FB27E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I had precisely the same = question.  Most DCs simply use IP/Enet which allow for the use of = the "regular suspects" in the tools = department. 

The other concern I have with = specifying new tools on top of the underlay is that the underlay = probably is running some diag tools for failure = detection/trouble-shooting too (like Ethernet OAM/BFD/etc...), so once = again we have the issue to consider of OAM traffic consuming significant = amounts of actual BW.  Given how modern applications are built and = run, its unlikely we need anything heavy weight in the overlay and can = instead allow for application resiliency to handle failure detection, = and instead have the "normal" tools available for trouble-shooting on an = as-needed basis.

= --Tom



Hi

Why don't you use existing IP based OAM messages such as BFD, = OWAMP, TWAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> = wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update = us with your inputs/feedback.

Warm Regards
- Kanwar
<=
br>
<=
br>
A=
 new version of I-D, draft-jain-nvo3-overlay-oam-0=
1.txt h=
as been successfully submitted by Kanwar Singh and posted to =
the
I=
ETF repository.
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">

N=
ame:           =
draft-jain-nvo3-overlay-oam

R=
evision:       01
<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">T=
itle:          Generic Overlay OAM and Datapath =
Failure Detection


D=
ocument date:  2014-02-12

G=
roup:          Individual Submission

P=
ages:          44
<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">U=
RL:            h=
ttp://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">

S=
tatus:         h=
ttps://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/


H=
tmlized:      h=
ttp://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01


D=
iff:              h=
ttp://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01



<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">A=
bstract:


&=
nbsp;  This proposal describes a mechanism that can be used to =
detect Data


&=
nbsp;  Path Failures of various overlay technologies as VXLAN, =
NVGRE,


&=
nbsp;  MPLSoGRE and MPLSoUDP and verifying/sanity of their Control =
and Data


&=
nbsp;  Plane for given Overlay Segment.  This document defines =
the following


&=
nbsp;  for each of the above Overlay Technologies:


<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">&=
nbsp;  o  Encapsulation of OAM Packet, such that it has same =
Outer and


&=
nbsp;     Overlay Header as any End-System's data going over =
the same


&=
nbsp;     Overlay Segment.


<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">&=
nbsp;  o  The mechanism to trace the Underlay that is =
exercised by any


&=
nbsp;     Overlay Segment.


<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">&=
nbsp;  o  Procedure to verify presence of any given Tenant VM =
or End-System


&=
nbsp;     within a given Overlay Segment at Overlay =
End-Point.


<=
span =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal">&=
nbsp;  Even though the present proposal addresses Overlay OAM for =
VXLAN,


&=
nbsp;  NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described =
are


&=
nbsp;  generic enough to accommodate OAM for any other Overlay =
Technology.

= --Apple-Mail=_9127BB88-33AC-4032-898C-53B9719FB27E-- --Apple-Mail=_1C7DE350-0450-4D97-BEF8-E2FEB7785CDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTD2HlAAoJEPcO+I7eiUJZFBMP/RtyMWJdF80/elGwGCJEAXhR 3pjXVS+j1wm8OGkhyICymMPp8clshbMB4+oQPAsuq87wSSFsPmmAIrni1WOBB+oK omYVQ0CIGAhbmyolcBhxXCR9Cqy47QaKrZMX6ZUAU4xLodNp5u/Y7lhtkwSh+sFk rWZ4XIbe4PfED9JEQj/+GR6qlPQJ6L5/cvi9bXSgwNw4FV8wYAmIG46Hyrtb72rF IYIzxC8aTMSE78e3bjV6KTICz5OWmaH+7At3ruU5v6+wPTG42HTYqn0xmG6MKJJk l3K5gQio0riPY9siNcGv1gmqmBUww+jqN8dQE94UnGM7Sdimo79HAqUDe4fExAUk YiHXFbGXxYNl/+f3UdhjZIr+5h+9SG/nZu5oxDFOoFjsmLGYUZv17tmvAvxYyKlc 1x/jaVhjSasiTkAVqkRtsVX+i97ZBrYLVzwMizF/5izyDIcVti7uCJhi2H2dKpjV EuNJY9nM+CsnXNB/4qv/uK+SO75MqqGxscHdAUzxXmaC7mfGTOSemF9AjSSv+Zmk iWF2IzfLNjXKKVcULuDJQFFVwFBt5dfg7lzkH0toyxo6gi0O8UFx2lmfYsUMThmZ +/auMRMyw5R4MXvipI/yFMg+SyRSf1WqDEktamo/udAg3kEOpGkS00Ngjz3UjixL aaO4IHxAwnNX+M15CY1H =Zjuw -----END PGP SIGNATURE----- --Apple-Mail=_1C7DE350-0450-4D97-BEF8-E2FEB7785CDF-- From nobody Thu Feb 27 08:05:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B511A027E for ; Thu, 27 Feb 2014 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFgZ0_1BZxId for ; Thu, 27 Feb 2014 08:05:43 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 186211A0286 for ; Thu, 27 Feb 2014 08:05:43 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5ADBF270AFD1; Thu, 27 Feb 2014 11:05:41 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_1EC42B37-1AB7-4504-AD3A-B9DAFC113AC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Thomas Nadeau In-Reply-To: Date: Thu, 27 Feb 2014 11:05:40 -0500 Message-Id: References: To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/KUB4-IB6nBPGsFs4IJOzA2htRIA Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:05:45 -0000 --Apple-Mail=_1EC42B37-1AB7-4504-AD3A-B9DAFC113AC9 Content-Type: multipart/alternative; boundary="Apple-Mail=_E5B8821E-91B1-462E-9AED-9BEE0604C61D" --Apple-Mail=_E5B8821E-91B1-462E-9AED-9BEE0604C61D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The question is, and perhaps the draft could explain this, is = why existing tools a) are insufficient and b) cannot be modified. Operationally speaking, b is preferred if you ask me as learning a new = tool/model for diagnosis and trouble-shooting is expensive and painful. For example, if we took the tact of reinventing say IP ping for every = underlying transport, then we'd have 50 tools by now. --Tom On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) = wrote: > Because we also need to trace L2 endpoints besides IP endpoint. >=20 > From: Shahram Davari > Date: Thursday 27 February 2014 16:58 > To: Kanwar Singh > Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >=20 > Hi >=20 > Why don't you use existing IP based OAM messages such as BFD, OWAMP, = TWAMP, etc. >=20 > Regards, > Shahram >=20 >=20 > On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" = wrote: >=20 >> Dear All, >>=20 >> We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks. >>=20 >> We would like to solicit inputs from the members of L2VPN WG. >>=20 >> Please review the same and update us with your inputs/feedback. >>=20 >> Warm Regards >> - Kanwar >>=20 >>=20 >> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been = successfully submitted by Kanwar Singh and posted to the >> IETF repository. >>=20 >> Name: draft-jain-nvo3-overlay-oam >> Revision: 01 >> Title: Generic Overlay OAM and Datapath Failure Detection >> Document date: 2014-02-12 >> Group: Individual Submission >> Pages: 44 >> URL: = http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt >> Status: = https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ >> Htmlized: = http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01 >>=20 >> Abstract: >> This proposal describes a mechanism that can be used to detect = Data >> Path Failures of various overlay technologies as VXLAN, NVGRE, >> MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and = Data >> Plane for given Overlay Segment. This document defines the = following >> for each of the above Overlay Technologies: >>=20 >> o Encapsulation of OAM Packet, such that it has same Outer and >> Overlay Header as any End-System's data going over the same >> Overlay Segment. >>=20 >> o The mechanism to trace the Underlay that is exercised by any >> Overlay Segment. >>=20 >> o Procedure to verify presence of any given Tenant VM or = End-System >> within a given Overlay Segment at Overlay End-Point. >>=20 >> Even though the present proposal addresses Overlay OAM for VXLAN, >> NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are >> generic enough to accommodate OAM for any other Overlay = Technology. --Apple-Mail=_E5B8821E-91B1-462E-9AED-9BEE0604C61D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The question is, and perhaps the = draft could explain this, is why existing tools a) are insufficient and = b) cannot be modified.
Operationally speaking, b is preferred if you = ask me as learning a new tool/model for diagnosis and trouble-shooting = is expensive and painful.
For example, if we took the tact of = reinventing say IP ping for every underlying transport, then we'd have = 50 tools by now.

= --Tom



On = Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-l= ucent.com> wrote:

Because we also need to trace L2 endpoints besides IP = endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 = 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net><= br> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain = <pradeep@nuagenetworks.net>= ;, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for = comments: draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, = OWAMP, TWAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> = wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update = us with your inputs/feedback.

Warm Regards
- Kanwar


A new version of =
I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully =
submitted by Kanwar Singh and posted to the
IETF =
repository.
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Name:           =
draft-jain-nvo3-overlay-oam
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Revision:       01
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Title:          Generic =
Overlay OAM and Datapath Failure Detection
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Document date:  2014-02-12
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Group:         =
 Individual Submission
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Pages:         =
 44
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">URL:           =
 h=
ttp://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Status:         h=
ttps://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Htmlized:      h=
ttp://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Diff:            =
  h=
ttp://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">Abstract:
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   This proposal describes a mechanism =
that can be used to detect Data
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   Path Failures of various overlay =
technologies as VXLAN, NVGRE,
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   MPLSoGRE and MPLSoUDP and =
verifying/sanity of their Control and Data
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   Plane for given Overlay Segment. =
 This document defines the following
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   for each of the above Overlay =
Technologies:
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   o  Encapsulation of OAM Packet, =
such that it has same Outer and
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">      Overlay Header as any =
End-System's data going over the same
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">      Overlay Segment.
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   o  The mechanism to trace the =
Underlay that is exercised by any
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">      Overlay Segment.
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   o  Procedure to verify presence =
of any given Tenant VM or End-System
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">      within a given Overlay =
Segment at Overlay End-Point.
<=
br =
style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"><=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   Even though the present proposal =
addresses Overlay OAM for VXLAN,
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   NVGRE, MPLSoGRE and MPLSoUDP, but the =
procedures described are
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; =
white-space: normal;">   generic enough to accommodate OAM for =
any other Overlay Technology.
<=
/pre>

= --Apple-Mail=_E5B8821E-91B1-462E-9AED-9BEE0604C61D-- --Apple-Mail=_1EC42B37-1AB7-4504-AD3A-B9DAFC113AC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTD2JUAAoJEPcO+I7eiUJZ+vkP/3f5oBqQCCIU2ZlPDPPUYWj2 dUQdj01GTeU5tz0Zvwtbi0WT6QnsAkkHXeTMUULG2YZ8S6M3FBO+etnIhxcaIFvX Gy4mW6DcS+d44iVI+KTMGP69XKM3kRvLz9NJnI0fsIy1ep4BvTX+4ZHPbubWaHjI FL5dNNtTAJp/+slJh9Jx0h05X2O2dsf2xSILUVZi3Go7MjueBrFBBiYdiIziDSL1 aFEFPTPXDeItk0ctIAVOBrCxM4BEz90wLbK32i+w0L8KYrzX9a1QR1Ej24pJ3368 /Xb7lygsfrhp9hsIEwdGTGsG2wr8i66WGZJNMKpHuaL7mQ+pzAuJnZ6gnYK6p2Xv tdf3s+m/Y/KP+vALkwC5QI+XkSX7JMG/mYxg6E1zu/FHRGkJHlH0WTgHIYPqg9kM 7MlBGdYKFzHV42NTH8ETYCKR+9RLtM8Q9b5A+kK1M8INU5+nrYZtlrdPnVA32Lra ogg8v0WlyLDMerNyW17Sq+MQEzswS8YK3XhSSGvXzpZB0HHvRYaRp3BPG6uUXyrV 0E0R3sBhrFrYNDoslT+MxHHbseO+oXvfhtYm7M+UStwD1OoyEgBQUw/BFVtnjfMB Wa54j8RRxW+GCXYlVFIIWn5z3PXgHSZZJ+ABh/c1G1kGZ055f9U9azn60StmUkWh Wozyzn3qfpL9UrSrU4gu =pqwY -----END PGP SIGNATURE----- --Apple-Mail=_1EC42B37-1AB7-4504-AD3A-B9DAFC113AC9-- From nobody Thu Feb 27 08:23:03 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA121A0320 for ; Thu, 27 Feb 2014 08:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kePhSTHB3Nay for ; Thu, 27 Feb 2014 08:22:59 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBE1A0104 for ; Thu, 27 Feb 2014 08:22:56 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1RGMqXs002584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 10:22:54 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1RGMpIH011221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:22:51 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:22:51 +0100 From: "Henderickx, Wim (Wim)" To: Thomas Nadeau Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9MqTlu9S0SqbE+B4eOK279kpJrJMP6AgAASA4D///AZAIAAFYkA Date: Thu, 27 Feb 2014 16:22:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CF352443B2210wimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Uj7w7l8AbBVaWSiE1TUJBmlZuKE Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:23:02 -0000 --_000_CF352443B2210wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We can do this + we leveraged as much as possible the LSP ping solutions wi= th minor extensions From: Tom Nadeau > Date: Thursday 27 February 2014 17:05 To: Wim Henderickx > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt The question is, and perhaps the draft could explain this, is why existing = tools a) are insufficient and b) cannot be modified. Operationally speaking, b is preferred if you ask me as learning a new tool= /model for diagnosis and trouble-shooting is expensive and painful. For example, if we took the tact of reinventing say IP ping for every under= lying transport, then we'd have 50 tools by now. --Tom On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) > wrote: Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF352443B2210wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <47E70F2355A3214F85E5E1C245AC21E4@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
We can do this + we leveraged as much as possible the LSP ping sol= utions with minor extensions

From: Tom Nadeau <tnadeau@lucidvision.com>
Date: Thursday 27 February 2014 17:= 05
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt


The questio= n is, and perhaps the draft could explain this, is why existing tools a) ar= e insufficient and b) cannot be modified.
Operationally speaking, b is preferred if you ask me as learning a new= tool/model for diagnosis and trouble-shooting is expensive and painful.
For example, if we took the tact of reinventing say IP ping for every = underlying transport, then we'd have 50 tools by now.

--Tom<= /div>



On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-luce= nt.com> wrote:

Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:= 58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar


A new version of I-D, draft-=
jain-nvo3-overlay-oam-01.txt has b=
een successfully submitted by Kanwar Singh and posted to the
IETF repository.
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; white-space:=
 normal;">Name:           draft-jain-nvo3-overlay-=
oam
Revision:       01
Title:          Generic Overlay OAM and Datapath =
Failure Detection
Document date:  2014-02-12=

Group:          Individual Submission=

Pages:          44
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-0=
1.txt
Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/=

Htmlized:      http://tools.i=
etf.org/html/draft-jain-nvo3-overlay-oam-01
Diff:   &n=
bsp;          http:=
//www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   Pa=
th Failures of various overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of their Contr=
ol and Data
   Plane for given Overlay Segment=
.  This document defines the following
   =
;for each of the above Overlay Technologies:

  &n=
bsp;o  Encapsulation of OAM Packet, such that it has same Outer and
      Overlay Header as any End-System's da=
ta going over the same
      Overlay Segm=
ent.

   o  The mechanism to trace the U=
nderlay that is exercised by any
      Ov=
erlay Segment.

   o  Procedure to verif=
y presence of any given Tenant VM or End-System
  &=
nbsp;   within a given Overlay Segment at Overlay End-Point.<=
br style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"=
>   Even though the present proposal addresses Overlay=
 OAM for VXLAN,
   NVGRE, MPLSoGRE and MPLSoUD=
P, but the procedures described are
   generic=
 enough to accommodate OAM for any other Overlay Technology.

--_000_CF352443B2210wimhenderickxalcatellucentcom_-- From nobody Thu Feb 27 08:27:09 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634311A0323 for ; Thu, 27 Feb 2014 08:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQvfkhuRdofT for ; Thu, 27 Feb 2014 08:27:05 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 11BAF1A0033 for ; Thu, 27 Feb 2014 08:27:04 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so2679460vcb.39 for ; Thu, 27 Feb 2014 08:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JLwRxLUlzKr83DdWAdz5thTsgCQWB5mi1aT9daAVpos=; b=EJsNvR17eOHEkdsu86YqW+eSj8gv4KH/5yqWqLxakE+V/ljiieLAGVxlmT9u5OTsKV njxlMl6rW/WwnylGkPG1kS45QD6fz9b8uKp34nu6IDSul3K+MbSFoY72i0VeFyYRI7x2 91F2hvQ1I/7GipqBpSW366tH48Tw89v1o9OswLqi2+A6FPZ1GDvM3og+pxHmBWwgsaNZ lY8GWWDQCAfhZvst0Hw5aHyyKaFr+HxmhV5ayAjfmy4NKC8EfXU+C6K237H06ZR3CpIt MMZziwngoPyvcFwcGl+6qGAXRQ44hmxV/Z25XJhmble6El7/RYLtgJxo6C8ic1N9LZXU xfoQ== MIME-Version: 1.0 X-Received: by 10.220.188.70 with SMTP id cz6mr99617vcb.59.1393518423184; Thu, 27 Feb 2014 08:27:03 -0800 (PST) Received: by 10.220.129.207 with HTTP; Thu, 27 Feb 2014 08:27:03 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Feb 2014 08:27:03 -0800 Message-ID: Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Greg Mirsky To: Kanwar Singh Content-Type: multipart/alternative; boundary=089e012951269a1b8f04f365ca0f Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/jOYmzX6vXCg3rIFN2n7JXS3nvV8 Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:27:07 -0000 --089e012951269a1b8f04f365ca0f Content-Type: text/plain; charset=ISO-8859-1 Hi Kanwar, et. al, the document is certainly interesting and very detailed. But I believe that it is rather too early to discuss applicability of particular OAM tools without agreed upon set of requirements for NVO3 OAM and comprehensive gap analysis. Regards, Greg On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh wrote: > Dear All, > > We have submitted the below draft that proposes Generic OAM and Datapath > Failure Detection Mechanism(s) for Overlay Networks. > > We would like to solicit inputs from the members of L2VPN WG. > > Please review the same and update us with your inputs/feedback. > > Warm Regards > > - Kanwar > > > > A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh and posted to the > > IETF repository. > > > Name: draft-jain-nvo3-overlay-oam > Revision: 01 > Title: Generic Overlay OAM and Datapath Failure Detection > > Document date: 2014-02-12 > Group: Individual Submission > Pages: 44 > URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt > > Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ > > Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01 > > > Abstract: > > This proposal describes a mechanism that can be used to detect Data > > Path Failures of various overlay technologies as VXLAN, NVGRE, > > MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data > > Plane for given Overlay Segment. This document defines the following > > for each of the above Overlay Technologies: > > o Encapsulation of OAM Packet, such that it has same Outer and > > Overlay Header as any End-System's data going over the same > > Overlay Segment. > > o The mechanism to trace the Underlay that is exercised by any > > Overlay Segment. > > o Procedure to verify presence of any given Tenant VM or End-System > > within a given Overlay Segment at Overlay End-Point. > > Even though the present proposal addresses Overlay OAM for VXLAN, > > NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are > > generic enough to accommodate OAM for any other Overlay Technology. > > --089e012951269a1b8f04f365ca0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kanwar, et. al,
the document is= certainly interesting and very detailed. But I believe that it is rather t= oo early to discuss applicability of particular OAM tools without agreed up= on set of requirements for NVO3 OAM and comprehensive gap analysis.

Regards,
Greg

On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh = <kanwar@nuagenetworks.net> wrote:
Dear All,

We have submitted the below draft that proposes Generic OAM and Datapath = Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2V= PN WG.

Please review the= same and update us with your inputs/feedback.

Warm Regards
- Kanwar


A new version =
of I-D, draft-jain-nvo3-overlay-oam-01.txt=A0has bee=
n successfully submitted by Kanwar Singh and posted to the
IETF repository.




Name: =A0 =A0 =A0 =A0 =A0 draft-jain-nvo3-overlay-oam

Revision: =A0 =A0 =A0 01
Title: =A0 =A0 =A0 =A0 =A0Generic =
Overlay OAM and Datapath Failure Detection



Document date: =A02014-02-12

Group: =A0 =A0 =A0 =A0 =A0Individual Submission

Pages: =A0 =A0 =A0 =A0 =A044
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-jain=
-nvo3-overlay-oam-01.txt



Status: =A0 =A0 =A0 =A0=A0https://datatracker.iet=
f.org/doc/draft-jain-nvo3-overlay-oam/



Htmlized: =A0 =A0 =A0http://tools.ietf.org/html/draft=
-jain-nvo3-overlay-oam-01



Diff: =A0 =A0 =A0 =A0 =A0=A0 =A0=A0http://www=
.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01




Abstract:



=A0 =A0This proposal describes a mechanism that can be used to detect D=
ata



=A0 =A0Path Failures of various overlay technologies as VXLAN, NVGRE,



=A0 =A0MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and =
Data



=A0 =A0Plane for given Overlay Segment. =A0This document defines the fo=
llowing



=A0 =A0for each of the above Overlay Technologies:


=A0 =A0o =A0Encapsulation of OAM Packet, such that it has same Outer =
and



=A0 =A0 =A0 Overlay Header as any End-System's data going over the =
same



=A0 =A0 =A0 Overlay Segment.


=A0 =A0o =A0The mechanism to trace the Underlay that is exercised by =
any



=A0 =A0 =A0 Overlay Segment.


=A0 =A0o =A0Procedure to verify presence of any given Tenant VM or En=
d-System



=A0 =A0 =A0 within a given Overlay Segment at Overlay End-Point.=



=A0 =A0Even though the present proposal addresses Overlay OAM for VXL=
AN,



=A0 =A0NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are



=A0 =A0generic enough to accommodate OAM for any other Overlay Technolo=
gy.

--089e012951269a1b8f04f365ca0f-- From nobody Thu Feb 27 08:57:33 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231B51A0382 for ; Thu, 27 Feb 2014 08:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkMDm_2sm0c0 for ; Thu, 27 Feb 2014 08:57:24 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 17ECE1A036E for ; Thu, 27 Feb 2014 08:57:24 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1RGvJZl009694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 10:57:21 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1RGvIux021970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:57:19 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.116]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:57:18 +0100 From: "Rabadan, Jorge (Jorge)" To: Greg Mirsky , Kanwar Singh Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9i/8gEtCy0e4EuWLz1WxAmt5prIu14A Date: Thu, 27 Feb 2014 16:57:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_CF34AC3136220jorgerabadanalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/EvjVFCWpK2q1PKLqlo0B14IHZZg Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:57:30 -0000 --_000_CF34AC3136220jorgerabadanalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, I understand that it might be too early for NVO3, however there are already= overlay tunnel implementations deployed and running out there, and the nee= d for OAM extensions for it is undeniable. So personally I would like to see this being discussed sooner than later so= that we don=92t end up with dozens of non-interoperable OAM tools. I think that is why the authors want to discuss this in the L2VPN WG as wel= l: it might be too early for NVO3 but there is a real need to discuss this = now. Thank you. Jorge From: Greg Mirsky > Date: Thursday, February 27, 2014 at 8:27 AM To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Kanwar, et. al, the document is certainly interesting and very detailed. But I believe that= it is rather too early to discuss applicability of particular OAM tools wi= thout agreed upon set of requirements for NVO3 OAM and comprehensive gap an= alysis. Regards, Greg On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF34AC3136220jorgerabadanalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <99DB5218E05B1848A41296962513B220@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

I understand that it might be too early for NVO3, however there are al= ready overlay tunnel implementations deployed and running out there, and th= e need for OAM extensions for it is undeniable.
So personally I would like to see this being discussed sooner than lat= er so that we don=92t end up with dozens of non-interoperable OAM tools.

I think that is why the authors want to discuss this in the L2VPN WG a= s well: it might be too early for NVO3 but there is a real need to discuss = this now. 

Thank you.
Jorge


From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thursday, February 27, 2014 a= t 8:27 AM
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Hi Kanwar, et. al,
the document is certainly interesting and very detailed. But I believe that= it is rather too early to discuss applicability of particular OAM tools wi= thout agreed upon set of requirements for NVO3 OAM and comprehensive gap an= alysis.

Regards,
Greg


On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh <kanwar@nu= agenetworks.net> wrote:
Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar


A new version of I-D, draft-=
jain-nvo3-overlay-oam-01.txt has b=
een successfully submitted by Kanwar Singh and posted to the
IETF repository.
<=
span style=3D"font-family: arial, sans-serif; font-size: 13px; white-space:=
 normal;">Name:           draft-jain-nvo3-overlay-=
oam
Revision:       01
Title:          Generic Overlay OAM and Datapath =
Failure Detection
Document date:  2014-02-12=

Group:          Individual Submission=

Pages:          44
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam=
-01.txt
Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/
Htmlized:      http://tools=
.ietf.org/html/draft-jain-nvo3-overlay-oam-01
Diff:   =
           htt=
p://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   Pa=
th Failures of various overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of their Contr=
ol and Data
   Plane for given Overlay Segment=
.  This document defines the following
   =
;for each of the above Overlay Technologies:

  &n=
bsp;o  Encapsulation of OAM Packet, such that it has same Outer and
      Overlay Header as any End-System's da=
ta going over the same
      Overlay Segm=
ent.

   o  The mechanism to trace the U=
nderlay that is exercised by any
      Ov=
erlay Segment.

   o  Procedure to verif=
y presence of any given Tenant VM or End-System
  &=
nbsp;   within a given Overlay Segment at Overlay End-Point.<=
br style=3D"font-family:arial,sans-serif;font-size:13px;white-space:normal"=
>   Even though the present proposal addresses Overlay=
 OAM for VXLAN,
   NVGRE, MPLSoGRE and MPLSoUD=
P, but the procedures described are
   generic=
 enough to accommodate OAM for any other Overlay Technology.

 --_000_CF34AC3136220jorgerabadanalcatellucentcom_-- From nobody Thu Feb 27 09:05:56 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4381A0414; Thu, 27 Feb 2014 09:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkvIpO0HmAis; Thu, 27 Feb 2014 09:05:48 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 986241A0342; Thu, 27 Feb 2014 09:05:47 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-82-530f70697362 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 91.03.11484.9607F035; Thu, 27 Feb 2014 18:05:46 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 12:05:44 -0500 From: Gregory Mirsky To: "Rabadan, Jorge (Jorge)" , Greg Mirsky , Kanwar Singh Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mjjo6gwy99EEq/BNrlB6uyMprJnamAgAAIdAD//6yjsA== Date: Thu, 27 Feb 2014 17:05:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7734E8@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7734E8eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyuXSPn25WAX+wQcsFfotv056yWny7tITF Yt7/NhaLx98OsVs8nS9p8e3aCRaLRy8rLA5c2MLowOHR+mwvq8fOWXfZPZYs+cnkcb3pKrvH 3kmvGT3OzZnKFsAWxWWTkpqTWZZapG+XwJVxcdYj1oKGJYwVq1fqNzD+mcjYxcjJISFgIrHl cy87hC0mceHeerYuRi4OIYEjjBJN796xQDjLGSVmdLewglSxCRhJvNjYww6SEBHoZ5RY+rID rIpZYA+jRPf0d0wgVcICrhKv3q9nAbFFBNwkdq3Yww5hO0m09y4Hq2ERUJVYPAHC5hXwlbj/ 8Q4zxLoWRokD546AHcgpYCdx/t0EsGZGoAO/n1oD1sAsIC5x68l8JojDBSSW7DnPDGGLSrx8 /I8VwlaSmLT0HCtEfb7Eh+09zBDLBCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsTG4StLbFs 4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGW5iBMbvMQk2xx2MCz5ZHmKU5mBREuf98tY5SEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVANjvtYdxoOLp7fKGHB3qadYOH5IqN2X8iGkKX3f8USx bR7WzH/u/tgsfzj9RC//z4b6n/E/ozdGepotvCSfsiOpi0n45h4mnq9CM1Vv/ij6cfZ/sNak s14bf3B++36xe7me7pWP33K0nxR07Xq3Xf6TmdyZXRdso8Jn6gvrzHK+tYcnlm9+nsZ8JZbi jERDLeai4kQAhJX3a60CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/jW_uB8P73Nhh2nsM_1H25lvk99E Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar , "nvo3@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:05:55 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7734E8eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jorge, I understand the motivation. Please check E-VPN Operations, Administration = and Maintenance Requirements and Framework and NVO3 Operation= s, Administration, and Maintenance Requirements respectively fr= om l2vpn and nvo3 WGs. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Rabadan, Jorge (Jo= rge) Sent: Thursday, February 27, 2014 8:57 AM To: Greg Mirsky; Kanwar Singh Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Greg, I understand that it might be too early for NVO3, however there are already= overlay tunnel implementations deployed and running out there, and the nee= d for OAM extensions for it is undeniable. So personally I would like to see this being discussed sooner than later so= that we don't end up with dozens of non-interoperable OAM tools. I think that is why the authors want to discuss this in the L2VPN WG as wel= l: it might be too early for NVO3 but there is a real need to discuss this = now. Thank you. Jorge From: Greg Mirsky > Date: Thursday, February 27, 2014 at 8:27 AM To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Kanwar, et. al, the document is certainly interesting and very detailed. But I believe that= it is rather too early to discuss applicability of particular OAM tools wi= thout agreed upon set of requirements for NVO3 OAM and comprehensive gap an= alysis. Regards, Greg On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_7347100B5761DC41A166AC17F22DF1121B7734E8eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jorge,

I understand the motivati= on. Please check E-VPN Operations, Administration and Maintenance  Requirements and Fra= mework and NVO3 Operations, Administration, and Maintenance Requirements respectiv= ely from l2vpn and nvo3 WGs.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Rabadan, Jorge (Jorge)
Sent: Thursday, February 27, 2014 8:57 AM
To: Greg Mirsky; Kanwar Singh
Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi Greg,

 

I understand that it might be= too early for NVO3, however there are already overlay tunnel implementatio= ns deployed and running out there, and the need for OAM extensions for it is undeniable.

So personally I would like to= see this being discussed sooner than later so that we don’t end up w= ith dozens of non-interoperable OAM tools.

 

I think that is why the autho= rs want to discuss this in the L2VPN WG as well: it might be too early for = NVO3 but there is a real need to discuss this now. <= /p>

 

Thank you.<= /p>

Jorge

 

 

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thursday, February 27, 2014 at 8:27 AM
To: Kanwar Singh <kan= war@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi Kanwar, et. al,=

Regards,

Greg

On Thu, Feb 27, 2014 at 7:46 = AM, Kanwar Singh <kanwar@nuagenetworks.net> wrote:

Dear All,

 

We have submitted the below d= raft that proposes Generic OAM and Datapath Failure Detection Mechanism(s) = for Overlay Networks.

 

We would like to solicit inpu= ts from the members of L2VPN WG.

 

Please review the same and upd= ate us with your inputs/feedback.<= /span>

 

Warm Regard=
s
- Kanwar
 =

 =

A new version of I-D, draft-jain-=
nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Sing=
h and posted to the

IETF repository.

Name: &nb=
sp;         draft-jain-nvo3-overlay-oam
Revision: &n=
bsp;     01
Title:          Generic O=
verlay OAM and Datapath Failure Detection
Document date:  2014-02-1=
2
Group:          Individual Submission
Page=
s:          44
URL:        =
    =
http:/=
/www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt=

Status:         https://datatracker.ietf.org/doc/draft-jain-nv=
o3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/draft-ja=
in-nvo3-overlay-oam-01
Diff:      =
;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01<=
/span>

Abstract:
   This proposal desc=
ribes a mechanism that can be used to detect Data
   Path Fail=
ures of various overlay technologies as VXLAN, NVGRE,
   MPLSo=
GRE and MPLSoUDP and verifying/sanity of their Control and Data
  &=
nbsp;Plane for given Overlay Segment.  This document defines the follo=
wing
   for each of the above Overlay Technologies:

&nb=
sp;  o  Encapsulation of OAM Packet, such that it has same Outer =
and
      Overlay Header as any End-System's data going o=
ver the same
      Overlay Segment.

   o=
  The mechanism to trace the Underlay that is exercised by any
&nbs=
p;     Overlay Segment.

   o  Procedure to =
verify presence of any given Tenant VM or End-System
     =
; within a given Overlay Segment at Overlay End-Point.

   =
Even though the present proposal addresses Overlay OAM for VXLAN,
 =
  NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
&n=
bsp;  generic enough to accommodate OAM for any other Overlay Technolo=
gy.

 

--_000_7347100B5761DC41A166AC17F22DF1121B7734E8eusaamb103erics_-- From nobody Thu Feb 27 09:40:33 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AF91A02DC for ; Thu, 27 Feb 2014 09:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNXoEq5mrtm2 for ; Thu, 27 Feb 2014 09:40:30 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 290381A018A for ; Thu, 27 Feb 2014 09:40:30 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id y13so2716020pdi.33 for ; Thu, 27 Feb 2014 09:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=exlaXR1tDHvaU10rRo/UDW3aZL2VZz3ZZQvGjDsBJx8=; b=FIstq8NI+KhrFEiQq4ie8bxvpRa3wRBCTCdE2tXacISJdljyDs1AHoStf6QZynDpP9 K3v4iF9OIELHKOcku+bh/f6+zpNgpMEUHiMQthK8HbZJoF11ebcW27R88EHgm/lXv5nn 5b7i2ohdmmDgEnmal8Aku2GDfqbzUGPdk6FaZQf8qK23nhQHThv5uxgvsokc8FtDcaBT hE+zuSTt8x4JFQxNoGxPEHh1Rs2GWEqaggj5icLapI3/jp/SlXcUkMG6HDIVDzUNXhFr eITu+KP5TDk1RARogW/V1v/c7A6skyZCgkxoj0+bfueIBcS3CJ+1VoV7jBBsui3mVKgY elPw== X-Received: by 10.68.237.228 with SMTP id vf4mr14513840pbc.131.1393522828615; Thu, 27 Feb 2014 09:40:28 -0800 (PST) Received: from [192.168.1.4] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id dk1sm15486789pbc.46.2014.02.27.09.40.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 09:40:27 -0800 (PST) References: <9F1DDAAE-BF29-48A8-BFDD-960F8F5A65F3@lucidvision.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9F1DDAAE-BF29-48A8-BFDD-960F8F5A65F3@lucidvision.com> Content-Type: multipart/alternative; boundary=Apple-Mail-85DA9317-0B19-4DAB-B6CB-AB6F3D57C38D Content-Transfer-Encoding: 7bit Message-Id: <1647130B-9123-4019-B6EA-A5F8DACB033F@gmail.com> X-Mailer: iPad Mail (11B554a) From: Sam Aldrin Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Date: Thu, 27 Feb 2014 09:40:26 -0800 To: Thomas Nadeau Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/sKR5U5jA_juTbewVGEMZ9kluaj0 Cc: "l2vpn@ietf.org" , Pradeep Jain , Nagendra Kumar Nainar , Vinay Bannai , Ravi Shekhar , Tissa Senevirathne X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:40:33 -0000 --Apple-Mail-85DA9317-0B19-4DAB-B6CB-AB6F3D57C38D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable We have published a draft a while ago, , which is on the lines of MPLS lsp ping. Primari= ly it is IP/udp ping targeted for overlay networks. For NVo3 FM, there is a= draft , which wi= ll be presented in the NVo3 WG session. Cheers Sam Sent from my iPad > On Feb 27, 2014, at 8:03 AM, Thomas Nadeau wrote= : >=20 >=20 > I had precisely the same question. Most DCs simply use IP/Enet whi= ch allow for the use of the "regular suspects" in the tools department.=20 >=20 > The other concern I have with specifying new tools on top of the un= derlay is that the underlay probably is running some diag tools for failure d= etection/trouble-shooting too (like Ethernet OAM/BFD/etc...), so once again w= e have the issue to consider of OAM traffic consuming significant amounts of= actual BW. Given how modern applications are built and run, its unlikely w= e need anything heavy weight in the overlay and can instead allow for applic= ation resiliency to handle failure detection, and instead have the "normal" t= ools available for trouble-shooting on an as-needed basis. >=20 > --Tom >=20 >=20 >=20 >> Hi >>=20 >> Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAM= P, etc. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" wr= ote: >>=20 >>> Dear All, >>>=20 >>> We have submitted the below draft that proposes Generic OAM and Datapath= Failure Detection Mechanism(s) for Overlay Networks. >>>=20 >>> We would like to solicit inputs from the members of L2VPN WG. >>>=20 >>> Please review the same and update us with your inputs/feedback. >>>=20 >>> Warm Regards >>> - Kanwar >>>=20 >>>=20 >>> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been succes= sfully submitted by Kanwar Singh and posted to the >>> IETF repository. >>>=20 >>>=20 >>>=20 >>> Name: draft-jain-nvo3-overlay-oam >>>=20 >>> Revision: 01 >>> Title: Generic Overlay OAM and Datapath Failure Detection >>>=20 >>>=20 >>> Document date: 2014-02-12 >>>=20 >>> Group: Individual Submission >>>=20 >>> Pages: 44 >>> URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-over= lay-oam-01.txt >>>=20 >>>=20 >>> Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay= -oam/ >>>=20 >>>=20 >>> Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01= >>>=20 >>>=20 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-ov= erlay-oam-01 >>>=20 >>>=20 >>>=20 >>> Abstract: >>>=20 >>>=20 >>> This proposal describes a mechanism that can be used to detect Data >>>=20 >>>=20 >>> Path Failures of various overlay technologies as VXLAN, NVGRE, >>>=20 >>>=20 >>> MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data >>>=20 >>>=20 >>> Plane for given Overlay Segment. This document defines the following= >>>=20 >>>=20 >>> for each of the above Overlay Technologies: >>>=20 >>>=20 >>> o Encapsulation of OAM Packet, such that it has same Outer and >>>=20 >>>=20 >>> Overlay Header as any End-System's data going over the same >>>=20 >>>=20 >>> Overlay Segment. >>>=20 >>>=20 >>> o The mechanism to trace the Underlay that is exercised by any >>>=20 >>>=20 >>> Overlay Segment. >>>=20 >>>=20 >>> o Procedure to verify presence of any given Tenant VM or End-System >>>=20 >>>=20 >>> within a given Overlay Segment at Overlay End-Point. >>>=20 >>>=20 >>> Even though the present proposal addresses Overlay OAM for VXLAN, >>>=20 >>>=20 >>> NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are >>>=20 >>>=20 >>> generic enough to accommodate OAM for any other Overlay Technology. >=20 --Apple-Mail-85DA9317-0B19-4DAB-B6CB-AB6F3D57C38D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We have published a draft a while ago,= <http://datatracker.ietf.org/doc/draft-kumar-nvo3-overlay-ping/>, w= hich is on the lines of MPLS lsp ping. Primarily it is IP/udp ping  tar= geted for overlay networks. For NVo3 FM, there is a draft  <http://datatracke= r.ietf.org/doc/draft-tissa-nvo3-oam-fm/>, which will be presented in t= he NVo3 WG session.

Cheers
Sam
Sent from my iPad

On Feb 27, 2014, at 8:03 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:


I had precisely the same question.  Mos= t DCs simply use IP/Enet which allow for the use of the "regular suspects" i= n the tools department. 

The other concern I have with specif= ying new tools on top of the underlay is that the underlay probably is runni= ng some diag tools for failure detection/trouble-shooting too (like Ethernet= OAM/BFD/etc...), so once again we have the issue to consider of OAM traffic= consuming significant amounts of actual BW.  Given how modern applicat= ions are built and run, its unlikely we need anything heavy weight in the ov= erlay and can instead allow for application resiliency to handle failure det= ection, and instead have the "normal" tools available for trouble-shooting o= n an as-needed basis.

--Tom


<= div>

=
Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, TW= AMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapat= h Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar


A new version of I-D, draft-jain-nvo3=
-overlay-oam-01.txt has been successfully submitted=
 by Kanwar Singh and posted to the
IETF repository.



Name:           draft-jain-nvo3-overlay-oam

Revision:       01
Title:       &=
nbsp;  Generic Overlay OAM and Datapath Failure Detection


Document date:  2014-02-12

Group:          Individual Submission

Pages:          44
URL:     &=
nbsp;      http://www.ietf.org/i=
nternet-drafts/draft-jain-nvo3-overlay-oam-01.txt


Status:         https://data=
tracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/


Htmlized:      http://tools.ietf.org/html/=
draft-jain-nvo3-overlay-oam-01


Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01<=
/a>



Abstract:


   This proposal describes a mechanism that can be used to dete=
ct Data


   Path Failures of various overlay technologies as VXLAN, NVGR=
E,


   MPLSoGRE and MPLSoUDP and verifying/sanity of their Control a=
nd Data


   Plane for given Overlay Segment.  This document defines=
 the following


   for each of the above Overlay Technologies:


   o  Encapsulation of OAM Packet, such that it has same O=
uter and


      Overlay Header as any End-System's data going over t=
he same


      Overlay Segment.


   o  The mechanism to trace the Underlay that is exercis=
ed by any


      Overlay Segment.


   o  Procedure to verify presence of any given Tenant VM=
 or End-System


      within a given Overlay Segment at Overlay End-Point.=



   Even though the present proposal addresses Overlay OAM for V=
XLAN,


   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described a=
re


   generic enough to accommodate OAM for any other Overlay Tech=
nology.

= --Apple-Mail-85DA9317-0B19-4DAB-B6CB-AB6F3D57C38D-- From nobody Thu Feb 27 10:19:02 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375E11A01AC for ; Thu, 27 Feb 2014 10:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT0x-ioBe_-M for ; Thu, 27 Feb 2014 10:18:56 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 020DA1A0163 for ; Thu, 27 Feb 2014 10:18:55 -0800 (PST) Received: from mail232-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Thu, 27 Feb 2014 18:18:54 +0000 Received: from mail232-va3 (localhost [127.0.0.1]) by mail232-va3-R.bigfish.com (Postfix) with ESMTP id E974B5C0575; Thu, 27 Feb 2014 18:18:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371I936eIc85dhe0eahdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch24c1m1155h) Received-SPF: pass (mail232-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=alohiya@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(199002)(24454002)(377424004)(189002)(377454003)(95416001)(74662001)(15975445006)(81816001)(83506001)(74502001)(66066001)(79102001)(95666003)(59766001)(81686001)(74706001)(93136001)(76482001)(51856001)(77096001)(46102001)(16236675002)(54316002)(65816001)(15202345003)(47446002)(53806001)(63696002)(31966008)(74366001)(56776001)(85306002)(54356001)(92726001)(83322001)(19580405001)(81542001)(19580395003)(77982001)(94316002)(80022001)(36756003)(74876001)(92566001)(81342001)(50986001)(93516002)(69226001)(83072002)(561944002)(76786001)(47976001)(94946001)(87936001)(86362001)(90146001)(47736001)(49866001)(80976001)(85852003)(56816005)(4396001)(76796001)(87266001)(2656002)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB673; H:BLUPR05MB198.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:FEFCF91D.9EF45301.F7D341B8.59E4D0E1.2053A; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail232-va3 (localhost.localdomain [127.0.0.1]) by mail232-va3 (MessageSwitch) id 1393525131207926_14825; Thu, 27 Feb 2014 18:18:51 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.244]) by mail232-va3.bigfish.com (Postfix) with ESMTP id 2E484B00064; Thu, 27 Feb 2014 18:18:51 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 27 Feb 2014 18:18:39 +0000 Received: from BLUPR05MB673.namprd05.prod.outlook.com (10.141.206.16) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 27 Feb 2014 18:18:39 +0000 Received: from BLUPR05MB198.namprd05.prod.outlook.com (10.255.191.12) by BLUPR05MB673.namprd05.prod.outlook.com (10.141.206.16) with Microsoft SMTP Server (TLS) id 15.0.883.10; Thu, 27 Feb 2014 18:18:37 +0000 Received: from BLUPR05MB198.namprd05.prod.outlook.com ([169.254.11.154]) by BLUPR05MB198.namprd05.prod.outlook.com ([169.254.11.154]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 18:18:36 +0000 From: Anil Lohiya To: Thomas Nadeau , "Henderickx, Wim (Wim)" Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Ml3HZ2hXU6YEyQ1GTTphL/nZrJQcKAgAABS4CAAADRAP//nwYA Date: Thu, 27 Feb 2014 18:18:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.14] x-forefront-prvs: 013568035E Content-Type: multipart/alternative; boundary="_000_CF34C0FC7D7Balohiyajunipernet_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$paypal.com%41552%4%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%PAYPAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/F0LUWiYduxCOKkWcwJ3JW4KbKRo Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:19:01 -0000 --_000_CF34C0FC7D7Balohiyajunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Existing ping/traceroute mechanisms don't work in the virtualized environme= nt e.g. ping may report that IP reachability between the ingress and egress= tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping on= ly verifies basic connectivity between two endpoints in the underlay but NO= T in the context of overlay segments. Hence, we need debugging tools that w= ork in the overlay environment. Think why there was a need to have lsp ping= ... requirement with IP overlays is not much different. Question is not whether applications are resilient or not... One can not ig= nore the fact that operators have to think about having the right tools whe= n that "inevitable" call comes from their customer about deteriorating app= lication performance or traffic blackhole and there are no tools today spec= ific to overlay network debugging. - Anil From: Thomas Nadeau > Date: Thursday, February 27, 2014 8:05 AM To: "Henderickx, Wim (Wim)" > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt The question is, and perhaps the draft could explain this, is why existing = tools a) are insufficient and b) cannot be modified. Operationally speaking, b is preferred if you ask me as learning a new tool= /model for diagnosis and trouble-shooting is expensive and painful. For example, if we took the tact of reinventing say IP ping for every under= lying transport, then we'd have 50 tools by now. --Tom On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) > wrote: Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF34C0FC7D7Balohiyajunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <15865EE0B1F103438A7E2B59B91A1664@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Existing ping/traceroute mechanisms don't work in the virtualized envi= ronment e.g. ping may report that IP reachability between the ingress and e= gress tunnel endpoints is fine but the end systems (i.e. VM, physical serve= r etc.) connectivity for a tenant could still be broken. This is because ping only verifies basic connectivi= ty between two endpoints in the underlay but NOT in the context of overlay = segments. Hence, we need debugging tools that work in the overlay environme= nt. Think why there was a need to have lsp ping … requirement with IP overlays is not much different.<= /div>

Question is not whether applications are resilient or not… One c= an not ignore the fact that operators have to think about having the right = tools when that "inevitable" call  comes from their customer= about deteriorating application performance or traffic blackhole and there are no tools today specific to overlay network debuggi= ng.

- Anil

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8= :05 AM
To: "Henderickx, Wim (Wim)&quo= t; <wim.henderickx@= alcatel-lucent.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt


The questio= n is, and perhaps the draft could explain this, is why existing tools a) ar= e insufficient and b) cannot be modified.
Operationally speaking, b is preferred if you ask me as learning a new= tool/model for diagnosis and trouble-shooting is expensive and painful.
For example, if we took the tact of reinventing say IP ping for every = underlying transport, then we'd have 50 tools by now.

--Tom<= /div>



On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-luce= nt.com> wrote:

Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:= 58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar


A new version of I-D, draft=
-jain-nvo3-overlay-oam-01.txt ha=
s been successfully submitted by Kanwar Singh and posted to the

IETF repository.
=
Name:           draft-jain-nvo3-overla=
y-oam
Revision:       01
Title:          Generic Overlay OAM and Datap=
ath Failure Detection
Document date:  2014-02-12
Group:          Individual Subm=
ission
Pages:          44
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overl=
ay-oam-01.txt
Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay=
-oam/
Htmlized:      http=
://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
Diff=
:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01=


Abstract:
   This proposal de=
scribes a mechanism that can be used to detect Data
&nb=
sp;  Path Failures of various overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity o=
f their Control and Data
   Plane for given O=
verlay Segment.  This document defines the following
   for each of the above Overlay Technologies:

   o  Encapsulation of OAM Packet, such that it has=
 same Outer and
      Overlay Header as =
any End-System's data going over the same
   =
   Overlay Segment.

   o  The mec=
hanism to trace the Underlay that is exercised by any
      Overlay Segment.

   o=
  Procedure to verify presence of any given Tenant VM or End-System
      within a given Overlay Segment at Ov=
erlay End-Point.

   Even though the present=
 proposal addresses Overlay OAM for VXLAN,
   =
;NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any other Overl=
ay Technology.

--_000_CF34C0FC7D7Balohiyajunipernet_-- From nobody Thu Feb 27 11:20:04 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34481A02DC for ; Thu, 27 Feb 2014 11:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuCtbUvxzM7U for ; Thu, 27 Feb 2014 11:19:58 -0800 (PST) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 953051A005B for ; Thu, 27 Feb 2014 11:19:58 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,556,1389772800"; d="scan'208,217"; a="17149941" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 27 Feb 2014 11:57:56 -0800 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 11:19:45 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 11:19:45 -0800 From: Shahram Davari To: Anil Lohiya , Thomas Nadeau , "Henderickx, Wim (Wim)" Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mh8gEtCy0e4EuWLz1WxAmt5prJQcOtgACHZ4CAAADQAIAAJSOA//+JKpA= Date: Thu, 27 Feb 2014 19:19:44 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_4A6CE49E6084B141B15C0713B8993F281BFCD485SJEXCHMB12corpa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/QuDbi4xPRKZx-kr5JcjEquY7Y2M Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 19:20:03 -0000 --_000_4A6CE49E6084B141B15C0713B8993F281BFCD485SJEXCHMB12corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anil, I don't agree. If you use for example BFD for inner IP, and if BFD says con= nectivity is OK, this implies that the Overlay connectivity is also OK, sin= ce BFD is inside the overlay. Also I am not sure why you are adding the VNI, VSID, etc in the message as = TLV, since these value are already in the packet header. Thx Shahram From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya Sent: Thursday, February 27, 2014 10:19 AM To: Thomas Nadeau; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Existing ping/traceroute mechanisms don't work in the virtualized environme= nt e.g. ping may report that IP reachability between the ingress and egress= tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping on= ly verifies basic connectivity between two endpoints in the underlay but NO= T in the context of overlay segments. Hence, we need debugging tools that w= ork in the overlay environment. Think why there was a need to have lsp ping= ... requirement with IP overlays is not much different. Question is not whether applications are resilient or not... One can not ig= nore the fact that operators have to think about having the right tools whe= n that "inevitable" call comes from their customer about deteriorating app= lication performance or traffic blackhole and there are no tools today spec= ific to overlay network debugging. - Anil From: Thomas Nadeau > Date: Thursday, February 27, 2014 8:05 AM To: "Henderickx, Wim (Wim)" > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt The question is, and perhaps the draft could explain this, is why existing = tools a) are insufficient and b) cannot be modified. Operationally speaking, b is preferred if you ask me as learning a new tool= /model for diagnosis and trouble-shooting is expensive and painful. For example, if we took the tact of reinventing say IP ping for every under= lying transport, then we'd have 50 tools by now. --Tom On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) > wrote: Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_4A6CE49E6084B141B15C0713B8993F281BFCD485SJEXCHMB12corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anil,

 <= /p>

I don’t agree. If y= ou use for example BFD for inner IP, and if BFD says connectivity is OK, th= is implies that the Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why yo= u are adding the VNI, VSID, etc in the message as TLV, since these value ar= e already in the packet header.

 <= /p>

Thx
Shahram

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

Existing ping/traceroute me= chanisms don't work in the virtualized environment e.g. ping may report tha= t IP reachability between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conn= ectivity for a tenant could still be broken. This is because ping only veri= fies basic connectivity between two endpoints in the underlay but NOT in th= e context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why th= ere was a need to have lsp ping … requirement with IP overlays is not= much different.

 

Question is not whether app= lications are resilient or not… One can not ignore the fact that oper= ators have to think about having the right tools when that "inevitable= " call  comes from their customer about deteriorating application perfo= rmance or traffic blackhole and there are no tools today specific to overla= y network debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

The question is, and perhap= s the draft could explain this, is why existing tools a) are insufficient a= nd b) cannot be modified.

Operationally speaking, b i= s preferred if you ask me as learning a new tool/model for diagnosis and tr= ouble-shooting is expensive and painful.

For example, if we took the= tact of reinventing say IP ping for every underlying transport, then we'd = have 50 tools by now.

 

--Tom

 

 

 

On Feb 27, 2014:11:02 AM, a= t 11:02 AM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:=



Because we also need to tra= ce L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kan= war@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing = IP based OAM messages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

 

We have submitted the below= draft that proposes Generic OAM and Datapath Failure Detection Mechanism(s= ) for Overlay Networks.

 

We would like to solicit in= puts from the members of L2VPN WG.

 

Please review the same and up= date us with your inputs/feedback.

  

Warm Regard=
s
- Kanwar
 =

 =

A new version of I-D, draft-jain-=
nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Sing=
h and posted to the

IETF repository.

Name: &nb=
sp;         draft-jain-nvo3-overlay-oam
Revision: &n=
bsp;     01
Title:          Generic O=
verlay OAM and Datapath Failure Detection
Document date:  2014-02-1=
2
Group:          Individual Submission
Page=
s:          44
URL:        =
    =
http:/=
/www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt=

Status:         https://datatracker.ietf.org/doc/draft-jain-nv=
o3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/draft-ja=
in-nvo3-overlay-oam-01
Diff:      =
;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01<=
/span>

Abstract:
   This proposal desc=
ribes a mechanism that can be used to detect Data
   Path Fail=
ures of various overlay technologies as VXLAN, NVGRE,
   MPLSo=
GRE and MPLSoUDP and verifying/sanity of their Control and Data
  &=
nbsp;Plane for given Overlay Segment.  This document defines the follo=
wing
   for each of the above Overlay Technologies:

&nb=
sp;  o  Encapsulation of OAM Packet, such that it has same Outer =
and
      Overlay Header as any End-System's data going o=
ver the same
      Overlay Segment.

   o=
  The mechanism to trace the Underlay that is exercised by any
&nbs=
p;     Overlay Segment.

   o  Procedure to =
verify presence of any given Tenant VM or End-System
     =
; within a given Overlay Segment at Overlay End-Point.

   =
Even though the present proposal addresses Overlay OAM for VXLAN,
 =
  NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
&n=
bsp;  generic enough to accommodate OAM for any other Overlay Technolo=
gy.

 

--_000_4A6CE49E6084B141B15C0713B8993F281BFCD485SJEXCHMB12corpa_-- From nobody Thu Feb 27 14:04:11 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934691A02B0 for ; Thu, 27 Feb 2014 14:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG96Tce-5VFC for ; Thu, 27 Feb 2014 14:04:06 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 206121A0131 for ; Thu, 27 Feb 2014 14:04:06 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-9a-530fb64f8d51 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B8.02.12743.F46BF035; Thu, 27 Feb 2014 23:03:59 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 17:04:03 -0500 From: David Allan I To: Anil Lohiya , Thomas Nadeau , "Henderickx, Wim (Wim)" Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mjl3VAYRq6jkmz44B33P5aJZrJlZSAgAABS4CAAADRAIAAJSOA///pCJA= Date: Thu, 27 Feb 2014 22:04:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C3922BD91eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyuXRPiK7/Nv5gg54vxhbb1t9mtnj87RC7 xbdrJ1gsHr2ssHg4+RK7xYELWxgtZj/+webA7tH6bC+rx5IlP5k8rjddZffY+mQJu8feSa8Z Pc7NmcoWwBbFZZOSmpNZllqkb5fAldF+4gdrweWzjBWNe5tZGxi/bGPsYuTkkBAwkfj+Zx4r hC0mceHeerYuRi4OIYEjjBInJ2yBcpYzSuzv2gxWxSZgILHn/xdGkISIQD+jxJzbF8CqmAVm M0qcmnuEDaRKWMBV4tX79SwgtoiAm8SuFXvYIWw/iZlnHoJNYhFQldj2cjtYDa+Ar8ThWfeY INbNYpJY+fkdM0iCE2jd7vUPwIYyAh34/dQaJhCbWUBc4taT+UwQhwtILNlznhnCFpV4+fgf 1EOKEvv6p7ND1OdLrPt7kxFimaDEyZlPWCYwis5CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzN DGOfOfCYCVl8ASP7KkaO0uLUstx0I4NNjMDIPSbBpruDcc9Ly0OM0hwsSuK8X946BwkJpCeW pGanphakFsUXleakFh9iZOLglGpg3Mj1Wd/+0JYny+9lMz99xxpZ1L+i3Lak/Z3WXHW7sNXs C8Wcvt77mRmRcj326g33jzplPxxUUpJS75lOT+Xxjyyb9u98vUvdDnae43xzMu5MeHmoKumF fML15LdLTj69NdW7a6ptm51kUumG4mORoqsyVma8czji3HgmRNTdcMoXze2x0TzblViKMxIN tZiLihMBSqeUpaoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/82OboQbZnlSbxd8kRN3h4SSohPs Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:04:09 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C3922BD91eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Other than allowing an OAM packet to be distinguished, I'm having trouble u= nderstanding the purpose of the nested header. The MEP is still the receiv= ing NVE, so it is not testing (for example) NVE to guest OS stack.... And IMO SFC will introduce new requirements as the guest OS will be a MIP. So at this point I'm not sold! Cheers Dave From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya Sent: Thursday, February 27, 2014 10:19 AM To: Thomas Nadeau; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Existing ping/traceroute mechanisms don't work in the virtualized environme= nt e.g. ping may report that IP reachability between the ingress and egress= tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping on= ly verifies basic connectivity between two endpoints in the underlay but NO= T in the context of overlay segments. Hence, we need debugging tools that w= ork in the overlay environment. Think why there was a need to have lsp ping= ... requirement with IP overlays is not much different. Question is not whether applications are resilient or not... One can not ig= nore the fact that operators have to think about having the right tools whe= n that "inevitable" call comes from their customer about deteriorating app= lication performance or traffic blackhole and there are no tools today spec= ific to overlay network debugging. - Anil From: Thomas Nadeau > Date: Thursday, February 27, 2014 8:05 AM To: "Henderickx, Wim (Wim)" > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt The question is, and perhaps the draft could explain this, is why existing = tools a) are insufficient and b) cannot be modified. Operationally speaking, b is preferred if you ask me as learning a new tool= /model for diagnosis and trouble-shooting is expensive and painful. For example, if we took the tact of reinventing say IP ping for every under= lying transport, then we'd have 50 tools by now. --Tom On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) > wrote: Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_E6C17D2345AC7A45B7D054D407AA205C3922BD91eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Other than allowing an OA= M packet to be distinguished, I’m having trouble understanding the pu= rpose of the nested header.  The MEP is still the receiving NVE, so it is not testing (for example) NVE to guest OS stack….

 <= /p>

And IMO SFC will introduc= e new requirements as the guest OS will be a MIP.

 <= /p>

So at this point I’= m not sold!

 <= /p>

Cheers<= /p>

Dave

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

Existing ping/traceroute me= chanisms don't work in the virtualized environment e.g. ping may report tha= t IP reachability between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conn= ectivity for a tenant could still be broken. This is because ping only veri= fies basic connectivity between two endpoints in the underlay but NOT in th= e context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why th= ere was a need to have lsp ping … requirement with IP overlays is not= much different.

 

Question is not whether app= lications are resilient or not… One can not ignore the fact that oper= ators have to think about having the right tools when that "inevitable= " call  comes from their customer about deteriorating application perfo= rmance or traffic blackhole and there are no tools today specific to overla= y network debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

The question is, and perhap= s the draft could explain this, is why existing tools a) are insufficient a= nd b) cannot be modified.

Operationally speaking, b i= s preferred if you ask me as learning a new tool/model for diagnosis and tr= ouble-shooting is expensive and painful.

For example, if we took the= tact of reinventing say IP ping for every underlying transport, then we'd = have 50 tools by now.

 

--Tom

 

 

 

On Feb 27, 2014:11:02 AM, a= t 11:02 AM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:=



Because we also need to tra= ce L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kan= war@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing = IP based OAM messages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

 

We have submitted the below= draft that proposes Generic OAM and Datapath Failure Detection Mechanism(s= ) for Overlay Networks.

 

We would like to solicit in= puts from the members of L2VPN WG.

 

Please review the same and up= date us with your inputs/feedback.

  

Warm Regard=
s
- Kanwar
 =

 =

A new version of I-D, draft-jain-=
nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Sing=
h and posted to the

IETF repository.

Name: &nb=
sp;         draft-jain-nvo3-overlay-oam
Revision: &n=
bsp;     01
Title:          Generic O=
verlay OAM and Datapath Failure Detection
Document date:  2014-02-1=
2
Group:          Individual Submission
Page=
s:          44
URL:        =
    =
http:/=
/www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt=

Status:         https://datatracker.ietf.org/doc/draft-jain-nv=
o3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/draft-ja=
in-nvo3-overlay-oam-01
Diff:      =
;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01<=
/span>

Abstract:
   This proposal desc=
ribes a mechanism that can be used to detect Data
   Path Fail=
ures of various overlay technologies as VXLAN, NVGRE,
   MPLSo=
GRE and MPLSoUDP and verifying/sanity of their Control and Data
  &=
nbsp;Plane for given Overlay Segment.  This document defines the follo=
wing
   for each of the above Overlay Technologies:

&nb=
sp;  o  Encapsulation of OAM Packet, such that it has same Outer =
and
      Overlay Header as any End-System's data going o=
ver the same
      Overlay Segment.

   o=
  The mechanism to trace the Underlay that is exercised by any
&nbs=
p;     Overlay Segment.

   o  Procedure to =
verify presence of any given Tenant VM or End-System
     =
; within a given Overlay Segment at Overlay End-Point.

   =
Even though the present proposal addresses Overlay OAM for VXLAN,
 =
  NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
&n=
bsp;  generic enough to accommodate OAM for any other Overlay Technolo=
gy.

 

--_000_E6C17D2345AC7A45B7D054D407AA205C3922BD91eusaamb105erics_-- From nobody Thu Feb 27 15:53:56 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D681A0453 for ; Thu, 27 Feb 2014 15:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.547, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKHd8P1mDN2u for ; Thu, 27 Feb 2014 15:53:53 -0800 (PST) Received: from nm47.bullet.mail.ne1.yahoo.com (nm47.bullet.mail.ne1.yahoo.com [98.138.120.54]) by ietfa.amsl.com (Postfix) with ESMTP id C5D531A02B3 for ; Thu, 27 Feb 2014 15:53:52 -0800 (PST) Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2014 23:53:50 -0000 Received: from [98.138.100.118] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2014 23:50:55 -0000 Received: from [98.139.215.142] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2014 23:50:54 -0000 Received: from [98.139.212.213] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 27 Feb 2014 23:50:54 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 27 Feb 2014 23:50:54 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 612862.56024.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 96101 invoked by uid 60001); 27 Feb 2014 23:50:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1393545054; bh=fM8gEW8yMr+FBn5XJcaDrQZvySjxo+4yQd3oCfyxKR4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Z5ttVSQBSJTCFViGew1XyEJGmCa/SM8xdvdrsBe+TyrtP1sT8HVfBu59/lEPgcBtvSq02Z4R6iJM9IaBVnTK0bu6ugy3LDdmOOkW7fhpheZ8fYVr4beWiJdC8MCdGG8mUbjQXNwIyVKx+b2yBAxVcp6oEFoHBKKfw4RaLmfPN84= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fWigrPxNhfMSwBUIYg+ll+xRfpWw6GWO1ImWqXqaXbylq4fB2tqQ2SnkF9IGepXQuNQJss4wXWx1sEdkxUuujurIN3B9g20Uq8NzH6MEH++X3FWCUQFydXUMLEguM8OdjQjhzjibwCN2u3VC8GSI2HIBqLvLLWiEJaJeDVN73/k=; X-YMail-OSG: cvH2sJsVM1nLkDPqBMeMf6WLUk3K3n4OisujMdl3WPYC7AM qAwA2LzslkMN22w6wJwilIvpcVm8tpTXLwO.AegZoK_NaL2dpcMxq62.kISS nTWCpkFSGj51QGjQPQ9fVKqf5cosCPjMQ_LOYFN5jKXKru2jh4pDqLRSxP.X nhE3wHNXnziIGnOqmiF8J1ESxbDkBm7aMcu8UNOn11JLBwFKyQpCJMu7vF0K 7xck.t8vZG0FpWcNXcBEKWoHcvqEZpp6s9T8fBJaC7cqIAs3iMW3k_3MFTds 0h9c3nOy1mRolB66qW3KnGih189NwGzxubPdboWm.ymCJ62ipsSFCDcXSh2P nsjCoHsBX_MC6HUg_eSjpeOLH4lNRsKAq.HQKGMGKonvyM.Pzmb1WR8x2s6v vhPUP2pgI9Qf9I77S4EO7xoS2r6BP.v2.LXCb6ZAWjkqjQ5lb6SYrJ8TxR0v .twlRifVoMVcCZQaPdOGXe3TQQ5UXlnEE0Ts4uvIPoJcHJFtN0cEYo2Ul5PT Anxs7mN2e_v4pe9NGmGdir69AkQ2i.Psa8S2Oq0XU0ruP4YM66hFyYJgXSbF MZ_bVsrUnizp_dNJtGu.ygNnrsu.iHPCuYEMGkA-- Received: from [216.31.219.19] by web162501.mail.bf1.yahoo.com via HTTP; Thu, 27 Feb 2014 15:50:54 PST X-Rocket-MIMEInfo: 002.001, SSBtZWFudCB1c2luZyBCRkQgaW5zaWRlIHRoZSBwYXlsb2FkLiBub3QgZm9yIHRoZSBvdXRlciB0dW5uZWwuIFlvdSBjb3VsZCBhbHNvIHVzZSBFdGhlcm5ldCBPQU0gZm9yIEwyIGVuZHBvaW50cy4KClRoeApTRAoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206ICJIZW5kZXJpY2t4LCBXaW0gKFdpbSkiIDx3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20.ClRvOiBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbT47IEthbndhciBTaW5naCA8a2Fud2FyQG4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> Date: Thu, 27 Feb 2014 15:50:54 -0800 (PST) From: "S. Davari" Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt To: "Henderickx, Wim \(Wim\)" , Shahram Davari , Kanwar Singh In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1748018769-1772028487-1393545054=:56142" Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/KL-NNkct-lIIHTnNepY4MYiaMW0 Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "S. Davari" List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 23:53:55 -0000 --1748018769-1772028487-1393545054=:56142 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints.=0A=0AThx=0ASD=0A=0A=0A=0A=0A________= ________________________=0A From: "Henderickx, Wim (Wim)" =0ATo: Shahram Davari ; Kanwar Singh= =0ACc: "l2vpn@ietf.org" ; Prade= ep Jain ; Vinay Bannai ; Rav= i Shekhar =0ASent: Thursday, February 27, 2014 8:02:= 45 AM=0ASubject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.t= xt=0A =0A=0A=0ABecause we also need to trace L2 endpoints besides IP endpoi= nt.=0A=0AFrom: Shahram Davari =0ADate: Thursday 27 Feb= ruary 2014 16:58=0ATo: Kanwar Singh =0ACc: "l2vpn= @ietf.org" , Pradeep Jain , Vina= y Bannai , Ravi Shekhar =0ASubjec= t: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt=0A=0A=0AHi= =0A=0AWhy don't you use existing IP based OAM messages such as BFD, OWAMP, = TWAMP, etc.=0A=0ARegards, =0AShahram=0A=0A=0AOn Feb 27, 2014, at 7:46 AM, "= Kanwar Singh" wrote:=0A=0A=0ADear All, =0A>=0A>= =0A>We have submitted the below draft that proposes Generic OAM and Datapat= h Failure Detection Mechanism(s) for Overlay Networks.=0A>=0A>=0A>We would = like to solicit inputs from the members of L2VPN WG.=0A>=0A>=0A>Please revi= ew the same and update us with your inputs/feedback.=0A>=0A>=0A>Warm Regard= s=0A>- Kanwar=0A>=0A>=0A>=0A>=0A>A new version of I-D, draft-jain-nvo3-over= lay-oam-01.txt=A0has been successfully submitted by Kanwar Singh and posted= to the=0A>IETF repository.=0A>=0A>Name: =A0 =A0 =A0 =A0 =A0 draft-jain-nvo= 3-overlay-oam=0A>Revision: =A0 =A0 =A0 01=0A>Title: =A0 =A0 =A0 =A0 =A0Gene= ric Overlay OAM and Datapath Failure Detection=0A>Document date: =A02014-02= -12=0A>Group: =A0 =A0 =A0 =A0 =A0Individual Submission=0A>Pages: =A0 =A0 = =A0 =A0 =A044=0A>URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-d= rafts/draft-jain-nvo3-overlay-oam-01.txt=0A>Status: =A0 =A0 =A0 =A0=A0https= ://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/=0A>Htmlized: =A0 = =A0 =A0http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01=0A>Diff: = =A0 =A0 =A0 =A0 =A0=A0 =A0=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-= nvo3-overlay-oam-01=0A>=0A>Abstract:=0A>=A0 =A0This proposal describes a me= chanism that can be used to detect Data=0A>=A0 =A0Path Failures of various = overlay technologies as VXLAN, NVGRE,=0A>=A0 =A0MPLSoGRE and MPLSoUDP and v= erifying/sanity of their Control and Data=0A>=A0 =A0Plane for given Overlay= Segment. =A0This document defines the following=0A>=A0 =A0for each of the = above Overlay Technologies:=0A>=0A>=A0 =A0o =A0Encapsulation of OAM Packet,= such that it has same Outer and=0A>=A0 =A0 =A0 Overlay Header as any End-S= ystem's data going over the same=0A>=A0 =A0 =A0 Overlay Segment.=0A>=0A>=A0= =A0o =A0The mechanism to trace the Underlay that is exercised by any=0A>= =A0 =A0 =A0 Overlay Segment.=0A>=0A>=A0 =A0o =A0Procedure to verify presenc= e of any given Tenant VM or End-System=0A>=A0 =A0 =A0 within a given Overla= y Segment at Overlay End-Point.=0A>=0A>=A0 =A0Even though the present propo= sal addresses Overlay OAM for VXLAN,=0A>=A0 =A0NVGRE, MPLSoGRE and MPLSoUDP= , but the procedures described are=0A>=A0 =A0generic enough to accommodate = OAM for any other Overlay Technology.=0A> --1748018769-1772028487-1393545054=:56142 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I meant using BFD ins= ide the payload. not for the outer tunnel. You could also use Ethernet OAM = for L2 endpoints.

Thx
SD


=
From:<= /b> "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
<= b>To: Shahram Davari <dava= ri@broadcom.com>; Kanwar Singh <kanwar@nuagenetworks.net>
<= span style=3D"font-weight: bold;">Cc: "l2vpn@ietf.org" <l2vpn= @ietf.org>; Pradeep Jain <pradeep@nuagenetworks.net>; Vinay Bannai <vbannai@paypal.com>; Ravi Shekhar <rshekhar@juniper.net>
= Sent: Thursday, February = 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

=0A
Because we also need to trace L2 endpoints besides IP endpoint.<= /div>=0A

=0A
=0A=0A
=0AFrom: Shahram Davari <davari@broadcom.com>
=0ADate: Thursday 27 February 2014 16:58<= br clear=3D"none">=0ATo: Kanwar Si= ngh <kanw= ar@nuagenetworks.net>
=0ACc: "l2vpn@ietf.= org" <l2vpn@ietf.org&= gt;, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>,=0A Ravi= Shekhar <rshekha= r@juniper.net>
=0ASubject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.= txt
=0A
=0A

=0A
=0A
= =0A
=0A
Hi
=0A

=0A
=0A
Why don= 't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP, etc.=0A
=0ARegards,=0A
Shahram
=0A<= div>
=0A
=0A
=0A

=0AOn F= eb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:
=0A
=0A
=0A
= =0A
=0A
Dear All,=0A

=0A
= =0A
We have submitted the below draft that proposes Generic OAM and Dat= apath Failure Detection Mechanism(s) for Overlay Networks.
=0A
=0A
=0A
We would like to solicit inputs from the m= embers of L2VPN WG.
=0A

=0A
=0A
=0APlease review the same and update us with= your inputs/feedback.
=0A
=
=0A
=0A
=0A
Warm Regards
=0A
- Kanwar<=
/pre>=0A

=0A

=0A
A new version of I=
-D, draft-jain-nvo3-overlay-oam-01.txt has b=
een successfully submitted by Kanwar Singh and posted to the
=
=0A
IETF repository.

Name:         &nb=
sp; draft-jain-nvo3-overlay-oam
Revision: &n=
bsp;     01
Title:     &=
nbsp;    Generic Overlay OAM and Datapath Failure Detection
Document date:  2014-02-12
Group:          Individual Submission
Pages:          44
URL:            =
http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.tx=
t
Status:         https://datatracker.iet=
f.org/doc/draft-jain-nvo3-overlay-oam/
Htmlized=
:      http:=
//tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
=
Diff:              http://www.ietf.org/rfcdi=
ff?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
   This proposal describes a mechanism that can b=
e used to detect Data
   Path Fail=
ures of various overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of their =
Control and Data
   Plane for give=
n Overlay Segment.  This document defines the following
   for each of the above Overlay Technologies:

   o  Encap=
sulation of OAM Packet, such that it has same Outer and
      Overlay Header as any End-System's data go=
ing over the
 same
      Overlay Segment.<=
/span>

   o  The =
mechanism to trace the Underlay that is exercised by any
      Overlay Segment.

   o  Procedure to verify presence of =
any given Tenant VM or End-System
  &nb=
sp;   within a given Overlay Segment at Overlay End-Point.

   Even though the present=
 proposal addresses Overlay OAM for VXLAN,
&=
nbsp;  NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any other O=
verlay Technology.
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A=0A

--1748018769-1772028487-1393545054=:56142-- From nobody Thu Feb 27 18:26:06 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2F41A06A2 for ; Thu, 27 Feb 2014 18:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYZY5qGUJIxk for ; Thu, 27 Feb 2014 18:26:00 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 43EF31A02C2 for ; Thu, 27 Feb 2014 18:26:00 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id i11so3421029oag.23 for ; Thu, 27 Feb 2014 18:25:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WXjhIq6YSg1bSizd9YrXW4Id3ObFYSHoI1cKkplSb7k=; b=kTvI6g9ZueDS+OlQrVyxFHKPsRa8AN3EwWJb1kVH4SZgtZkedfIjhnhxVROCQNgHSw 0ptZcE+NT3zcA2OinzK8JhIOP5zfQ4dIH/8rpNmWlnFzWrfgSHGt4vYz0OMqGEWCrype +UzTpjNPjPwS2e2H8sVrFkY3S0550P6FwklBy8FhlJqLfM2qA6I1n3ptW9XOW3QjTRw/ g9jwR41IliEjdaDGUpKlkpn8YN9G27mbzfI/G9ImCMcljByv7SQ0RYlYif1ff9Jxk89P nyZ8acpfRIeX9q/uoQjr188cxG32xSGXeLzBEsvEA0FPIKgV8mO9HRzP5UAHw907y9oH tz2A== X-Gm-Message-State: ALoCoQmfsHF727yoOsRgImY9s4WtCSRSl5FuCRE15myPGbXKb0Vg8dcvhFPPqE327T4lhREDmSWF MIME-Version: 1.0 X-Received: by 10.60.51.230 with SMTP id n6mr205589oeo.35.1393554358293; Thu, 27 Feb 2014 18:25:58 -0800 (PST) Received: by 10.76.169.7 with HTTP; Thu, 27 Feb 2014 18:25:58 -0800 (PST) In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> Date: Thu, 27 Feb 2014 18:25:58 -0800 Message-ID: Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Kanwar Singh To: Shahram Davari Content-Type: multipart/alternative; boundary=001a11c30c7c806d8d04f36e2839 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/b_INIWupdvzs5rLOGXonNY4hq34 Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 02:26:05 -0000 --001a11c30c7c806d8d04f36e2839 Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, Regarding BFD for Inner IP, it seems you are suggesting that BFD needs to be running in between two End-System(s) (i.e. Guest VM/Tenant) using the Overlay. But, Cloud providers would not necessarily want to rely on applications running in Guest OS/Tenant to verify connectivity of their Networks. In-fact, in most cases Cloud Providers won't even have access to Guest / Tenant VMs to launch such applications. Thanks, Kanwar On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari wrote: > Anil, > > > > I don't agree. If you use for example BFD for inner IP, and if BFD says > connectivity is OK, this implies that the Overlay connectivity is also OK, > since BFD is inside the overlay. > > Also I am not sure why you are adding the VNI, VSID, etc in the message as > TLV, since these value are already in the packet header. > > > > Thx > Shahram > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Anil Lohiya > *Sent:* Thursday, February 27, 2014 10:19 AM > *To:* Thomas Nadeau; Henderickx, Wim (Wim) > *Cc:* l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar > *Subject:* Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > > > Existing ping/traceroute mechanisms don't work in the virtualized > environment e.g. ping may report that IP reachability between the ingress > and egress tunnel endpoints is fine but the end systems (i.e. VM, physical > server etc.) connectivity for a tenant could still be broken. This is > because ping only verifies basic connectivity between two endpoints in the > underlay but NOT in the context of overlay segments. Hence, we need > debugging tools that work in the overlay environment. Think why there was a > need to have lsp ping ... requirement with IP overlays is not much different. > > > > Question is not whether applications are resilient or not... One can not > ignore the fact that operators have to think about having the right tools > when that "inevitable" call comes from their customer about deteriorating > application performance or traffic blackhole and there are no tools today > specific to overlay network debugging. > > > > - Anil > > > > *From: *Thomas Nadeau > *Date: *Thursday, February 27, 2014 8:05 AM > *To: *"Henderickx, Wim (Wim)" > *Cc: *"l2vpn@ietf.org" , Pradeep Jain < > pradeep@nuagenetworks.net>, Vinay Bannai , Ravi > Shekhar > *Subject: *Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > > > The question is, and perhaps the draft could explain this, is why existing > tools a) are insufficient and b) cannot be modified. > > Operationally speaking, b is preferred if you ask me as learning a new > tool/model for diagnosis and trouble-shooting is expensive and painful. > > For example, if we took the tact of reinventing say IP ping for every > underlying transport, then we'd have 50 tools by now. > > > > --Tom > > > > > > > > On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) < > wim.henderickx@alcatel-lucent.com> wrote: > > > > Because we also need to trace L2 endpoints besides IP endpoint. > > > > *From: *Shahram Davari > *Date: *Thursday 27 February 2014 16:58 > *To: *Kanwar Singh > *Cc: *"l2vpn@ietf.org" , Pradeep Jain < > pradeep@nuagenetworks.net>, Vinay Bannai , Ravi > Shekhar > *Subject: *Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > Hi > > > > Why don't you use existing IP based OAM messages such as BFD, OWAMP, > TWAMP, etc. > > Regards, > > Shahram > > > > > On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: > > Dear All, > > > > We have submitted the below draft that proposes Generic OAM and Datapath > Failure Detection Mechanism(s) for Overlay Networks. > > > > We would like to solicit inputs from the members of L2VPN WG. > > > > Please review the same and update us with your inputs/feedback. > > > > Warm Regards > > - Kanwar > > > > > > A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh and posted to the > > IETF repository. > > Name: draft-jain-nvo3-overlay-oam > Revision: 01 > Title: Generic Overlay OAM and Datapath Failure Detection > Document date: 2014-02-12 > Group: Individual Submission > Pages: 44 > URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt > Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ > Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01 > > Abstract: > This proposal describes a mechanism that can be used to detect Data > Path Failures of various overlay technologies as VXLAN, NVGRE, > MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data > Plane for given Overlay Segment. This document defines the following > for each of the above Overlay Technologies: > > o Encapsulation of OAM Packet, such that it has same Outer and > Overlay Header as any End-System's data going over the same > Overlay Segment. > > o The mechanism to trace the Underlay that is exercised by any > Overlay Segment. > > o Procedure to verify presence of any given Tenant VM or End-System > within a given Overlay Segment at Overlay End-Point. > > Even though the present proposal addresses Overlay OAM for VXLAN, > NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are > generic enough to accommodate OAM for any other Overlay Technology. > > > --001a11c30c7c806d8d04f36e2839 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Shahram,

 

Regarding BFD for Inner IP, it seems you are= suggesting that BFD needs to be running in between two End-System(s) (i.e. Guest VM/Tenant) using the Ov= erlay. But, Cloud providers would  not necessarily want to rely on applications running in Guest OS/Tenant  to verify connectivit= y of their Networks. In-fact, in most cases Cloud Providers won’t even have access to Gues= t / Tenant VMs to launch such applications. 

 

Thanks,<= /p>

Kanwar



On Thu, Feb 27, 2014 at 11:19 AM, = Shahram Davari <davari@broadcom.com> wrote:

Anil,

 

I don’t agree. If y= ou use for example BFD for inner IP, and if BFD says connectivity is OK, th= is implies that the Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why yo= u are adding the VNI, VSID, etc in the message as TLV, since these value ar= e already in the packet header.

 

Thx
Shahram

 

From: L2vpn [m= ailto:l2vpn-bou= nces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)
Cc: l2vpn@ietf.o= rg; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

Existing ping/traceroute mechanisms don= 't work in the virtualized environment e.g. ping may report that IP rea= chability between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conn= ectivity for a tenant could still be broken. This is because ping only veri= fies basic connectivity between two endpoints in the underlay but NOT in th= e context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why th= ere was a need to have lsp ping … requirement with IP overlays is no= t much different.

 

Question is not whether applications ar= e resilient or not… One can not ignore the fact that operators have = to think about having the right tools when that "inevitable" call  comes from their customer about deteriorating application perfo= rmance or traffic blackhole and there are no tools today specific to overla= y network debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.= com>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Banna= i <vbannai@paypa= l.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

The question is, and perhaps the draft = could explain this, is why existing tools a) are insufficient and b) cannot= be modified.

Operationally speaking, b is preferred = if you ask me as learning a new tool/model for diagnosis and trouble-shooti= ng is expensive and painful.

For example, if we took the tact of rei= nventing say IP ping for every underlying transport, then we'd have 50 = tools by now.

 

--Tom

 

 

 

On Feb 27, 2014:11:02 AM, at 11:02 AM, = Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:



Because we also need to trace L2 endpoi= nts besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Banna= i <vbannai@paypa= l.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based= OAM messages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the below draft that = proposes Generic OAM and Datapath Failure Detection Mechanism(s) for Overla= y Networks.

 

We would like to solicit inputs from th= e members of L2VPN WG.

 

Please review the same and update us with= your inputs/feedback.

 

Warm Regards<=
/span>
- Kanwar
 =

 =

A new version of I-D, draft-jain-nvo3-overlay=
-oam-01.txt has been successfully submitted by Kanwar Singh and posted=
 to the
IETF repository.

Name:     &=
nbsp;     draft-jain-nvo3-overlay-oam
Revision:     =
  01
Title:          Generic Overlay OAM a=
nd Datapath Failure Detection

Document date:  2014-02-12
Group:          =
;Individual Submission
Pages:          44
UR=
L:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.=
txt

Status:         http=
s://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/=


Htmlized:      http://tools.ietf=
.org/html/draft-jain-nvo3-overlay-oam-01

Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overla=
y-oam-01


Abstract:
   This proposal describes a mechanism that can =
be used to detect Data
   Path Failures of various overlay tec=
hnologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verify=
ing/sanity of their Control and Data

   Plane for given Overlay Segment.  This document defines t=
he following
   for each of the above Overlay Technologies:
   o  Encapsulation of OAM Packet, such that it has sam=
e Outer and
      Overlay Header as any End-System's =
data going over the same

      Overlay Segment.

   o  The mecha=
nism to trace the Underlay that is exercised by any
     =
 Overlay Segment.

   o  Procedure to verify presence =
of any given Tenant VM or End-System
      within a given=
 Overlay Segment at Overlay End-Point.


   Even though the present proposal addresses Overlay OAM for=
 VXLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures de=
scribed are
   generic enough to accommodate OAM for any other=
 Overlay Technology.

 


--001a11c30c7c806d8d04f36e2839-- From nobody Thu Feb 27 19:38:19 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB67E1A02D9 for ; Thu, 27 Feb 2014 19:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5JAiwrY1qXW for ; Thu, 27 Feb 2014 19:38:15 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id C83891A02C5 for ; Thu, 27 Feb 2014 19:38:15 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uy5so123664obc.6 for ; Thu, 27 Feb 2014 19:38:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pf1DeWUgUMnTPLhxTGc1ixE07EROUDB0GPjQcIU6vlY=; b=Tudiz4WMLe/c8mt2LV7vaJoZ/yC+UYg5LF+vuV1jL+IQ0ipu1R6mw0hdHWdOfZVNQf gvR/QnsrzfXJXgZmfow1MasUs/RP8j3y98BjbZ69d+yKfiy2iGiBC6w6GANuL8DN3ITz Bj9PrjMRO9WGvEGBXeYPR6oL9MrciWPVXHUTXP5eMosGsMMGQHb74a4dZXQH8nD/dwWe 5yaugG4vBokrkxvHZJza4EfnpnuPEHYTmVouk+RwEk2DO0ijxZcBmTfgx+7eJxXKptWP thK3bgAcH04sSs5Z2xei+W423BOD/nnmCOtqYI044vthh5wlpqvovFr8kwvSxYDqggdE hsMg== X-Gm-Message-State: ALoCoQmjGuJMkpEw/GOVrBmbr9nP5Ub7V3Am9KQT/0pkg+KiA3AKXBGkfr3UCXsvV3KwSsS3hZtI MIME-Version: 1.0 X-Received: by 10.60.134.200 with SMTP id pm8mr498959oeb.40.1393558694001; Thu, 27 Feb 2014 19:38:14 -0800 (PST) Received: by 10.76.82.230 with HTTP; Thu, 27 Feb 2014 19:38:13 -0800 (PST) In-Reply-To: References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> Date: Thu, 27 Feb 2014 19:38:13 -0800 Message-ID: Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Pradeep Jain To: Shahram Davari Content-Type: multipart/alternative; boundary=047d7b417831ee144d04f36f2a90 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/pUo3r5W39y7IwPFUWOzIKfDOzJ4 Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:38:18 -0000 --047d7b417831ee144d04f36f2a90 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, February 27, 2014, Pradeep Jain wrote: > Hi Shahram, > > Using BFD mandates that the probes need to be sent continuously. We don't > want to impose this restriction and leave it to the user to decide if they > want an on-demand probe or a continuous probe, which is what has been > defined in the draft.. > > Regarding the second point about including VNI/VSID in TLV, for the > hardware/forwarding plane which is not capable of giving the overlay > context of the packet (based on VNI/VSID) to the control plane, we need to > rely on the VNI/VSID in the TLV to derive the overlay context in the > control plane... > > Regards > Pradeep > > > On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari > > wrote: > > Anil, > > > > I don't agree. If you use for example BFD for inner IP, and if BFD says > connectivity is OK, this implies that the Overlay connectivity is also OK, > since BFD is inside the overlay. > > Also I am not sure why you are adding the VNI, VSID, etc in the message as > TLV, since these value are already in the packet header. > > > > Thx > Shahram > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Anil Lohiya > *Sent:* Thursday, February 27, 2014 10:19 AM > *To:* Thomas Nadeau; Henderickx, Wim (Wim) > > *Cc:* l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar > *Subject:* Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > > > Existing ping/traceroute mechanisms don't work in the virtualized > environment e.g. ping may report that IP reachability between the ingress > and egress tunnel endpoints is fine but the end systems (i.e. VM, physical > server etc.) connectivity for a tenant could still be broken. This is > because ping only verifies basic connectivity between two endpoints in the > underlay but NOT in the context of overlay segments. Hence, we need > debugging tools that work in the overlay environment. Think why there was a > need to have lsp ping ... requirement with IP overlays is not much different. > > > > Question is not whether applications are resilient or not... One can not > ignore the fact that operators have to think about having the right tools > when that "inevitable" call comes from their customer about deteriorating > application performance or traffic blackhole and there are no tools today > specific to overlay network debugging. > > > > - Anil > > > > *From: *Thomas Nadeau > *Date: *Thursday, February 27, 2014 8:05 AM > *To: *"Henderickx, Wim (Wim)" < > > > --047d7b417831ee144d04f36f2a90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thursday, February 27, 2014, Pradeep Jain <pradeep@nuagenetworks.net> wrote:
Hi Shahram,

Using BFD mandates that the= probes need to be sent continuously. We don't want to impose this rest= riction and leave it to the user to decide if they want an on-demand probe = or a continuous probe, which is what has been defined in the draft..

Regarding the second point about including VNI/VS= ID in TLV, for the hardware/forwarding plane which is not capable of giving= the overlay context of the packet (based on VNI/VSID) to the control plane= , we need to rely on the VNI/VSID in the TLV to derive the overlay context = in the control plane...

Regards
Pradeep


On Thu, Feb 27, 2014 at 11:19 AM, Shah= ram Davari <davari@broadcom.com= > wrote:

Anil,

 

I don’t agree. If you use for example B= FD for inner IP, and if BFD says connectivity is OK, this implies that the = Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why you are adding the VNI= , VSID, etc in the message as TLV, since these value are already in the pac= ket header.

 

Thx
Shahram

 

From: L2vpn [mailto:l2vpn-bounc= es@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)


Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar<= br>
Subject: Re: Request for comments: draft-jain-nvo3-o= verlay-oam-01.txt

 

 

Existing ping/traceroute mechanisms don't work in the v= irtualized environment e.g. ping may report that IP reachability between th= e ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conn= ectivity for a tenant could still be broken. This is because ping only veri= fies basic connectivity between two endpoints in the underlay but NOT in th= e context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why th= ere was a need to have lsp ping … requirement with IP overlays is no= t much different.

 

Question is not whether applications are resilient or not&h= ellip; One can not ignore the fact that operators have to think about havin= g the right tools when that "inevitable" call  comes from their customer about deteriorating application perfo= rmance or traffic blackhole and there are no tools today specific to overla= y network debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>= ;
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <


--047d7b417831ee144d04f36f2a90-- From nobody Thu Feb 27 19:48:15 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFFE1A02D9 for ; Thu, 27 Feb 2014 19:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biOkD0guIpda for ; Thu, 27 Feb 2014 19:48:11 -0800 (PST) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) by ietfa.amsl.com (Postfix) with ESMTP id 022961A02DF for ; Thu, 27 Feb 2014 19:48:10 -0800 (PST) Received: from [98.139.212.149] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 28 Feb 2014 03:48:09 -0000 Received: from [68.142.230.78] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 28 Feb 2014 03:48:09 -0000 Received: from [127.0.0.1] by smtp235.mail.bf1.yahoo.com with NNFMP; 28 Feb 2014 03:48:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1393559289; bh=MvBz+0JEPFGd+dZ8UUks1GBKRhCh1KSiYsp/7FqIXMQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=y0QNqI8RPsuEEYU12ZtUAP22UFGLMNGx7IxU9jzvV4unPYOPzL2MSxLXqZc3Gt6ejuGNdBI41XwVGSmZuq5N7mqjQzzqrenoEakR31FYY6TW8QiihW9NtMU+H7mQ6t6+bJ9B+75TC0KRZ80HSUsyTX6a0hyDeTmTIPCfGwC9Drg= X-Yahoo-Newman-Id: 117606.92077.bm@smtp235.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: CS87ehIVM1lcm.l4UB8H4p5g9w1BTAmEqycZTEN2G_8gwA3 p.eS3FfetxgCMK3lPxJIk1VPNlZkreMb7L524yLzQtffOkJ0eVgPlYsodtXR ekL7HnjXLR9WI7bf9E5JiTg4pAyjw4G_9BrR1hUuBOJ.MT8IRydx6VWjAY_5 D0BdG_hAsJCxLkgL8rrGnlTbQMwUfNtSjrLVFxdXUIAURekKj.Z8HjmCu.Sd KlVh9PDCrXkNgDT8ujRZQiurYzhfYsEChoTOzARHs3cHFdvdp_cIdCt628qR 6CRpCOmoa9jPozUi4cZqJjWE5Q36oRWKI8XIc_7ptQaKJA.n9FZOLBHjFAxl HJtcPdQmN4W7YuqKv4ti13HCFX3XnqfkgXiQmwSehX16c5RkxXd3rs6ur3XO yJDisazZbqJNZyBU2NIzsdYN9busWZ87voyF_n5aaiMg0Ur6SBe2NY78_N8l WvfV9vhWhZir5E16pgGsDFuujf3v4yIaKryspQ.XyY0GAN5GT5rMpbdmQw2F gL6ATMhj2r7jn8_z7wQGG1BnwO6Kn226cq5p9bRvRJk2fW7lJWPwhKDU- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [10.0.0.3] (davarish@69.181.137.230 with xymcookie [66.196.81.168]) by smtp235.mail.bf1.yahoo.com with SMTP; 28 Feb 2014 03:48:09 +0000 UTC References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-80D599F2-2F49-4974-A51F-53FDE3C335E6 Content-Transfer-Encoding: 7bit Message-Id: <2BC895F1-6364-447A-9C3C-3630CF05E60A@yahoo.com> X-Mailer: iPhone Mail (11B651) From: "S. Davari" Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Date: Thu, 27 Feb 2014 19:48:05 -0800 To: Kanwar Singh Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/b10kOnXV14PVUCQEug2omWPsAWo Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:48:14 -0000 --Apple-Mail-80D599F2-2F49-4974-A51F-53FDE3C335E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cloud provider could easily inject and remove BFD packets encapsulated as ov= erlay. This can easily be done with some reserved MAC or IP address.=20 Regards, Shahram > On Feb 27, 2014, at 6:25 PM, Kanwar Singh wrote= : >=20 > Hi Shahram, >=20 > =20 >=20 > Regarding BFD for Inner IP, it seems you are suggesting that BFD needs to b= e running in between two End-System(s) (i.e. Guest VM/Tenant) using the Over= lay. But, Cloud providers would not necessarily want to rely on application= s running in Guest OS/Tenant to verify connectivity of their Networks. In-f= act, in most cases Cloud Providers won=E2=80=99t even have access to Guest /= Tenant VMs to launch such applications.=20 >=20 > =20 >=20 > Thanks, >=20 > Kanwar >=20 >=20 >=20 >> On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari wr= ote: >> Anil, >>=20 >> =20 >>=20 >> I don=E2=80=99t agree. If you use for example BFD for inner IP, and if BFD= says connectivity is OK, this implies that the Overlay connectivity is also= OK, since BFD is inside the overlay. >>=20 >> Also I am not sure why you are adding the VNI, VSID, etc in the message a= s TLV, since these value are already in the packet header. >>=20 >> =20 >>=20 >> Thx >> Shahram >>=20 >> =20 >>=20 >> From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya >> Sent: Thursday, February 27, 2014 10:19 AM >> To: Thomas Nadeau; Henderickx, Wim (Wim) >> Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar >> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >>=20 >> =20 >>=20 >> =20 >>=20 >> Existing ping/traceroute mechanisms don't work in the virtualized environ= ment e.g. ping may report that IP reachability between the ingress and egres= s tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping onl= y verifies basic connectivity between two endpoints in the underlay but NOT i= n the context of overlay segments. Hence, we need debugging tools that work i= n the overlay environment. Think why there was a need to have lsp ping =E2=80= =A6 requirement with IP overlays is not much different. >>=20 >> =20 >>=20 >> Question is not whether applications are resilient or not=E2=80=A6 One ca= n not ignore the fact that operators have to think about having the right to= ols when that "inevitable" call comes from their customer about deteriorati= ng application performance or traffic blackhole and there are no tools today= specific to overlay network debugging. >>=20 >> =20 >>=20 >> - Anil >>=20 >> =20 >>=20 >> From: Thomas Nadeau >> Date: Thursday, February 27, 2014 8:05 AM >> To: "Henderickx, Wim (Wim)" >> Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar >> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >>=20 >> =20 >>=20 >> =20 >>=20 >> The question is, and perhaps the draft could explain this, is why existin= g tools a) are insufficient and b) cannot be modified.=20 >>=20 >> Operationally speaking, b is preferred if you ask me as learning a new to= ol/model for diagnosis and trouble-shooting is expensive and painful. >>=20 >> For example, if we took the tact of reinventing say IP ping for every und= erlying transport, then we'd have 50 tools by now. >>=20 >> =20 >>=20 >> --Tom >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) wrote: >>=20 >>=20 >>=20 >>=20 >> Because we also need to trace L2 endpoints besides IP endpoint. >>=20 >> =20 >>=20 >> From: Shahram Davari >> Date: Thursday 27 February 2014 16:58 >> To: Kanwar Singh >> Cc: "l2vpn@ietf.org" , Pradeep Jain , Vinay Bannai , Ravi Shekhar >> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >>=20 >> =20 >>=20 >> Hi >>=20 >> =20 >>=20 >> Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAM= P, etc. >>=20 >> Regards, >>=20 >> Shahram >>=20 >> =20 >>=20 >>=20 >> On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" wr= ote: >>=20 >> Dear All, >>=20 >> =20 >>=20 >> We have submitted the below draft that proposes Generic OAM and Datapath = Failure Detection Mechanism(s) for Overlay Networks. >>=20 >> =20 >>=20 >> We would like to solicit inputs from the members of L2VPN WG. >>=20 >> =20 >>=20 >> Please review the same and update us with your inputs/feedback. >>=20 >> =20 >>=20 >> Warm Regards >> - Kanwar >> =20 >> =20 >> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been success= fully submitted by Kanwar Singh and posted to the >> IETF repository. >>=20 >> Name: draft-jain-nvo3-overlay-oam >> Revision: 01 >> Title: Generic Overlay OAM and Datapath Failure Detection >>=20 >> Document date: 2014-02-12 >> Group: Individual Submission >> Pages: 44 >> URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overl= ay-oam-01.txt >>=20 >> Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-= oam/ >>=20 >> Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 >>=20 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-ove= rlay-oam-01 >>=20 >>=20 >> Abstract: >> This proposal describes a mechanism that can be used to detect Data >> Path Failures of various overlay technologies as VXLAN, NVGRE, >> MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data >>=20 >> Plane for given Overlay Segment. This document defines the following >> for each of the above Overlay Technologies: >>=20 >> o Encapsulation of OAM Packet, such that it has same Outer and >> Overlay Header as any End-System's data going over the same >>=20 >> Overlay Segment. >>=20 >> o The mechanism to trace the Underlay that is exercised by any >> Overlay Segment. >>=20 >> o Procedure to verify presence of any given Tenant VM or End-System >> within a given Overlay Segment at Overlay End-Point. >>=20 >>=20 >> Even though the present proposal addresses Overlay OAM for VXLAN, >> NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are >> generic enough to accommodate OAM for any other Overlay Technology. >=20 --Apple-Mail-80D599F2-2F49-4974-A51F-53FDE3C335E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Cloud provider could easily inject and= remove BFD packets encapsulated as overlay. This can easily be done with so= me reserved MAC or IP address. 

Regards,
Shahram
<= br>

On Feb 27, 2014, at 6:25 PM, Kanwar Singh <kanwar@nuagenetworks.net> wrote= :

Hi Shahram,

 

Regarding BFD for Inner IP, it seems you are s= uggesting that BFD needs to be running in between two End-System(s) (i.e. Guest VM/Tenant) using the Ove= rlay. But, Cloud providers would  not necessarily want to rely on applications running in Guest OS/Tenant  to verify connectivity= of their Networks. In-fact, in most cases Cloud Providers won=E2=80=99t even have access to Gue= st / Tenant VMs to launch such applications. 

 

Thanks,

Kanwar



On Thu, Feb 27, 2014 at 11:19 AM, Sha= hram Davari <davari@broadcom.com> wrote:

Anil,<= /p>

 =

I don=E2=80=99t agree. If y= ou use for example BFD for inner IP, and if BFD says connectivity is OK, thi= s implies that the Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why you a= re adding the VNI, VSID, etc in the message as TLV, since these value are al= ready in the packet header.

 =

Thx
Shahram

 =

From: L2vpn [mail= to:l2vpn-bounces= @ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)
Cc: l2vpn@ietf.or= g; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt=

 

 

Existing ping/traceroute mechanisms don't= work in the virtualized environment e.g. ping may report that IP reachabili= ty between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conne= ctivity for a tenant could still be broken. This is because ping only verifi= es basic connectivity between two endpoints in the underlay but NOT in the c= ontext of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why the= re was a need to have lsp ping =E2=80=A6 requirement with IP overlays is not= much different.

 

Question is not whether applications are r= esilient or not=E2=80=A6 One can not ignore the fact that operators have to t= hink about having the right tools when that "inevitable" call  comes from their customer about deteriorating application perfor= mance or traffic blackhole and there are no tools today specific to overlay n= etwork debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com><= br> Cc: "l2vpn@ietf.o= rg" <l2vpn@ietf.o= rg>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <= rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt=

 

 

The question is, and perhaps the draft co= uld explain this, is why existing tools a) are insufficient and b) cannot be= modified.

Operationally speaking, b is preferred if= you ask me as learning a new tool/model for diagnosis and trouble-shooting i= s expensive and painful.

For example, if we took the tact of reinv= enting say IP ping for every underlying transport, then we'd have 50 tools b= y now.

 

--Tom

 

 

 

On Feb 27, 2014:11:02 AM, at 11:02 AM, He= nderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:



Because we also need to trace L2 endpoint= s besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.o= rg" <l2vpn@ietf.o= rg>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <= rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt=

 

Hi

 

Why don't you use existing IP based OAM m= essages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:=

Dear All,

 

We have submitted the below draft that pr= oposes Generic OAM and Datapath Failure Detection Mechanism(s) for Overlay N= etworks.

 

We would like to solicit inputs from the m= embers of L2VPN WG.

 

Please review the same and update us with y= our inputs/feedback.

 

Warm Regards<=
/u>
- Kanwar<=
/span>
 
 
A new version of I-D, draft-jain-nvo3-overlay-o=
am-01.txt has been successfully submitted by Kanwar Singh and posted to=
 the
IETF repository.

Name:     &nb=
sp;     draft-jain-nvo3-overlay-oam
Revision:     &nb=
sp; 01
Title:          Generic Overlay OAM and D=
atapath Failure Detection

Document date:  2014-02-12
Group:          =
Individual Submission
Pages:          44
URL:=
            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.t=
xt

Status:         ht=
tps://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/

Htmlized:      http://tools.ietf=
.org/html/draft-jain-nvo3-overlay-oam-01

Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl=
ay-oam-01


Abstract:
   This proposal describes a mechanism that can b=
e used to detect Data
   Path Failures of various overlay techn=
ologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying=
/sanity of their Control and Data

   Plane for given Overlay Segment.  This document defines th=
e following
   for each of the above Overlay Technologies:
<=
br>   o  Encapsulation of OAM Packet, such that it has same O=
uter and
      Overlay Header as any End-System's data goi=
ng over the same

      Overlay Segment.

   o  The mechan=
ism to trace the Underlay that is exercised by any
      O=
verlay Segment.

   o  Procedure to verify presence of a=
ny given Tenant VM or End-System
      within a given Over=
lay Segment at Overlay End-Point.


   Even though the present proposal addresses Overlay OAM for V=
XLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures descr=
ibed are
   generic enough to accommodate OAM for any other Ove=
rlay Technology.

 


= --Apple-Mail-80D599F2-2F49-4974-A51F-53FDE3C335E6-- From nobody Thu Feb 27 20:04:12 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06091A06BE for ; Thu, 27 Feb 2014 20:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0e6fPZ4LBOg for ; Thu, 27 Feb 2014 20:04:10 -0800 (PST) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2813D1A06B6 for ; Thu, 27 Feb 2014 20:04:10 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,559,1389772800"; d="scan'208,217"; a="17221822" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw1-out.broadcom.com with ESMTP; 27 Feb 2014 20:42:29 -0800 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 20:04:07 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 20:04:07 -0800 From: Shahram Davari To: Pradeep Jain Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mh8gEtCy0e4EuWLz1WxAmt5prJQcOtgACHZ4CAAADQAIAAJSOA//+JKpCAAQmqAIAACYiA//+BIGY= Date: Fri, 28 Feb 2014 04:04:06 +0000 Message-ID: <7CE24018-E869-4968-B73B-08796261E551@broadcom.com> References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7CE24018E8694968B73B08796261E551broadcomcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3iiTdmv4PrOI3nzAJdj3xzt0xiw Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 04:04:11 -0000 --_000_7CE24018E8694968B73B08796261E551broadcomcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Regarding on demand, you could define new state machine for BFD or you coul= d use IP ping or LSP ping. You could even use Ethernet Loopback. Regards, Shahram On Feb 27, 2014, at 7:38 PM, "Pradeep Jain" > wrote: On Thursday, February 27, 2014, Pradeep Jain > wrote: Hi Shahram, Using BFD mandates that the probes need to be sent continuously. We don't w= ant to impose this restriction and leave it to the user to decide if they w= ant an on-demand probe or a continuous probe, which is what has been define= d in the draft.. Regarding the second point about including VNI/VSID in TLV, for the hardwar= e/forwarding plane which is not capable of giving the overlay context of th= e packet (based on VNI/VSID) to the control plane, we need to rely on the V= NI/VSID in the TLV to derive the overlay context in the control plane... Regards Pradeep On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari > wrote: Anil, I don=92t agree. If you use for example BFD for inner IP, and if BFD says c= onnectivity is OK, this implies that the Overlay connectivity is also OK, s= ince BFD is inside the overlay. Also I am not sure why you are adding the VNI, VSID, etc in the message as = TLV, since these value are already in the packet header. Thx Shahram From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya Sent: Thursday, February 27, 2014 10:19 AM To: Thomas Nadeau; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Existing ping/traceroute mechanisms don't work in the virtualized environme= nt e.g. ping may report that IP reachability between the ingress and egress= tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping on= ly verifies basic connectivity between two endpoints in the underlay but NO= T in the context of overlay segments. Hence, we need debugging tools that w= ork in the overlay environment. Think why there was a need to have lsp ping= =85 requirement with IP overlays is not much different. Question is not whether applications are resilient or not=85 One can not ig= nore the fact that operators have to think about having the right tools whe= n that "inevitable" call comes from their customer about deteriorating app= lication performance or traffic blackhole and there are no tools today spec= ific to overlay network debugging. - Anil From: Thomas Nadeau Date: Thursday, February 27, 2014 8:05 AM To: "Henderickx, Wim (Wim)" < --_000_7CE24018E8694968B73B08796261E551broadcomcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Regarding on demand, you could define new state machine for BFD or you= could use IP ping or LSP ping. You could even use Ethernet Loopback.

Regards,
Shahram


On Feb 27, 2014, at 7:38 PM, "Pradeep Jain" <pradeep@nuagenetworks.net> wrote:



On Thursday, February 27, 2014, Pradeep Jain <pradeep@nuagenetworks.net> wrote:
Hi Shahram,

Using BFD mandates that the probes need to be sent continuously. We do= n't want to impose this restriction and leave it to the user to decide if t= hey want an on-demand probe or a continuous probe, which is what has been d= efined in the draft..

Regarding the second point about including VNI/VSID in TLV, for the ha= rdware/forwarding plane which is not capable of giving the overlay context = of the packet (based on VNI/VSID) to the control plane, we need to rely on = the VNI/VSID in the TLV to derive the overlay context in the control plane...

Regards
Pradeep


On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari= <davari@broadcom.com> wrote:

Anil,

 

I don=92t agree. If you use for example BFD f= or inner IP, and if BFD says connectivity is OK, this implies that the Over= lay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why you are adding the VNI= , VSID, etc in the message as TLV, since these value are already in the pac= ket header.

 

Thx
Shahram

 

From: L2vpn [mailto:l2vpn-bounc= es@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)


Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar<= br>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-= 01.txt

 

 

Existing ping/traceroute mechanisms don't work in the virtu= alized environment e.g. ping may report that IP reachability between the in= gress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) connectivity for a tenant could st= ill be broken. This is because ping only verifies basic connectivity betwee= n two endpoints in the underlay but NOT in the context of overlay segments.= Hence, we need debugging tools that work in the overlay environment. Think why there was a need to have l= sp ping =85 requirement with IP overlays is not much different.

 

Question is not whether applications are resilient or not= =85 One can not ignore the fact that operators have to think about having t= he right tools when that "inevitable" call  comes from their customer about deteriorating application performance or traffic blackhole = and there are no tools today specific to overlay network debugging.<= u>

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <


--_000_7CE24018E8694968B73B08796261E551broadcomcom_-- From nobody Thu Feb 27 20:22:51 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699A71A06F8 for ; Thu, 27 Feb 2014 20:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRrET6ye0WmO for ; Thu, 27 Feb 2014 20:22:46 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 448A41A06F4 for ; Thu, 27 Feb 2014 20:22:44 -0800 (PST) Received: from mail6-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE011.bigfish.com (10.3.207.133) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Feb 2014 04:22:42 +0000 Received: from mail6-am1 (localhost [127.0.0.1]) by mail6-am1-R.bigfish.com (Postfix) with ESMTP id 846B04600AF; Fri, 28 Feb 2014 04:22:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371I936eIc85ehdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch24c1m1155h) Received-SPF: pass (mail6-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=alohiya@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(24454002)(377424004)(377454003)(15975445006)(56776001)(81816001)(95666003)(83506001)(19580405001)(63696002)(65816001)(66066001)(90146001)(86362001)(19300405004)(85852003)(51856001)(46102001)(94946001)(95416001)(56816005)(19580395003)(94316002)(83072002)(15202345003)(80976001)(74706001)(2656002)(74876001)(87266001)(93516002)(81686001)(93136001)(53806001)(79102001)(92726001)(85306002)(92566001)(80022001)(87936001)(36756003)(59766001)(83322001)(74366001)(74502001)(81342001)(16236675002)(81542001)(54316002)(77096001)(76796001)(49866001)(76786001)(47736001)(47976001)(50986001)(31966008)(561944002)(77982001)(69226001)(76482001)(4396001)(47446002)(54356001)(74662001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB675; H:BLUPR05MB198.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:FE3CF91D.9EF25381.F7D371B7.99E4D1F1.205FD; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail6-am1 (localhost.localdomain [127.0.0.1]) by mail6-am1 (MessageSwitch) id 1393561359420139_18987; Fri, 28 Feb 2014 04:22:39 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.238]) by mail6-am1.bigfish.com (Postfix) with ESMTP id 6184C320069; Fri, 28 Feb 2014 04:22:39 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 04:22:39 +0000 Received: from BLUPR05MB675.namprd05.prod.outlook.com (10.141.206.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 04:22:37 +0000 Received: from BLUPR05MB198.namprd05.prod.outlook.com (10.255.191.12) by BLUPR05MB675.namprd05.prod.outlook.com (10.141.206.24) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 28 Feb 2014 04:22:36 +0000 Received: from BLUPR05MB198.namprd05.prod.outlook.com ([169.254.11.154]) by BLUPR05MB198.namprd05.prod.outlook.com ([169.254.11.154]) with mapi id 15.00.0883.010; Fri, 28 Feb 2014 04:22:36 +0000 From: Anil Lohiya To: Shahram Davari , Thomas Nadeau , "Henderickx, Wim (Wim)" Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Ml3HZ2hXU6YEyQ1GTTphL/nZrJQcKAgAABS4CAAADRAP//nwYAgACXMwCAABGNgA== Date: Fri, 28 Feb 2014 04:22:35 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.14] x-forefront-prvs: 0136C1DDA4 Content-Type: multipart/alternative; boundary="_000_CF34D8437DF8alohiyajunipernet_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.240.101$paypal.com%41552%4%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%PAYPAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/1wDISaqnNy5zH44fnZ1pnZXBFkM Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 04:22:49 -0000 --_000_CF34D8437DF8alohiyajunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Shahram, BFD can not replace the functionality provided by the overlay oam mechanism= e.g. bfd can't provide the functions such as control and data plane valida= tion, ECMP path discovery, traceroute etc. regarding including vni, vsid etc. in TLV =96 control and data plane maybe = out of sync due to different reasons and we can not assume that the VNI in = the outer header is what user intended to validate against in its echo requ= est. So, adding VNI explicitly in the TLV makes sure that egress is really = validating what the user intended it to. thanks - Anil From: Shahram Davari > Date: Thursday, February 27, 2014 11:19 AM To: Anil Lohiya >, Thomas N= adeau >, "Henderick= x, Wim (Wim)" > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Anil, I don=92t agree. If you use for example BFD for inner IP, and if BFD says c= onnectivity is OK, this implies that the Overlay connectivity is also OK, s= ince BFD is inside the overlay. Also I am not sure why you are adding the VNI, VSID, etc in the message as = TLV, since these value are already in the packet header. Thx Shahram From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya Sent: Thursday, February 27, 2014 10:19 AM To: Thomas Nadeau; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi= Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Existing ping/traceroute mechanisms don't work in the virtualized environme= nt e.g. ping may report that IP reachability between the ingress and egress= tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping on= ly verifies basic connectivity between two endpoints in the underlay but NO= T in the context of overlay segments. Hence, we need debugging tools that w= ork in the overlay environment. Think why there was a need to have lsp ping= =85 requirement with IP overlays is not much different. Question is not whether applications are resilient or not=85 One can not ig= nore the fact that operators have to think about having the right tools whe= n that "inevitable" call comes from their customer about deteriorating app= lication performance or traffic blackhole and there are no tools today spec= ific to overlay network debugging. - Anil From: Thomas Nadeau > Date: Thursday, February 27, 2014 8:05 AM To: "Henderickx, Wim (Wim)" > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt The question is, and perhaps the draft could explain this, is why existing = tools a) are insufficient and b) cannot be modified. Operationally speaking, b is preferred if you ask me as learning a new tool= /model for diagnosis and trouble-shooting is expensive and painful. For example, if we took the tact of reinventing say IP ping for every under= lying transport, then we'd have 50 tools by now. --Tom On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) > wrote: Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF34D8437DF8alohiyajunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Shahram,

BFD can not replace the functionality provided by the overlay oam mech= anism e.g. bfd can't provide the functions such as control and data plane v= alidation, ECMP path discovery, traceroute etc.

regarding including vni, vsid etc. in TLV =96 control and data plane m= aybe out of sync due to different reasons and we can not assume that the VN= I in the outer header is what user intended to validate against in its echo= request. So, adding VNI explicitly in the TLV makes sure that egress is really validating what the user inten= ded it to.

thanks
- Anil

From: Shahram Davari <davari@broadcom.com>
Date: Thursday, February 27, 2014 1= 1:19 AM
To: Anil Lohiya <alohiya@juniper.net>, Thomas Nadeau <tnadeau@lucidvision.com>, &qu= ot;Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: RE: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Anil,

 

I don=92t agree. If you use for ex= ample BFD for inner IP, and if BFD says connectivity is OK, this implies th= at the Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why you are add= ing the VNI, VSID, etc in the message as TLV, since these value are already= in the packet header.

 

Thx
Shahram

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Pradeep Ja= in; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

Existing ping/traceroute mechanisms don't w= ork in the virtualized environment e.g. ping may report that IP reachabilit= y between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conn= ectivity for a tenant could still be broken. This is because ping only veri= fies basic connectivity between two endpoints in the underlay but NOT in th= e context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why th= ere was a need to have lsp ping =85 requirement with IP overlays is not muc= h different.

 

Question is not whether applications are re= silient or not=85 One can not ignore the fact that operators have to think = about having the right tools when that "inevitable" call  comes from their customer about deterior= ating application performance or traffic blackhole and there are no tools t= oday specific to overlay network debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

The question is, and perhaps the draft coul= d explain this, is why existing tools a) are insufficient and b) cannot be = modified.

Operationally speaking, b is preferred if y= ou ask me as learning a new tool/model for diagnosis and trouble-shooting i= s expensive and painful.

For example, if we took the tact of reinven= ting say IP ping for every underlying transport, then we'd have 50 tools by= now.

 

--Tom

 

 

 

On Feb 27, 2014:11:02 AM, at 11:02 AM, Hend= erickx, Wim (Wim) <= wim.henderickx@alcatel-lucent.com> wrote:



Because we also need to trace L2 endpoints = besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kan= war@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based OAM mes= sages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> wrote:

Dear All,

 

We have submitted the below draft that prop= oses Generic OAM and Datapath Failure Detection Mechanism(s) for Overlay Ne= tworks.

 

We would like to solicit inputs from the me= mbers of L2VPN WG.

 

Please review the same and update us with you= r inputs/feedback.

 

Warm Regard=
s
- Kanwar
 =

 =

A new version of I-D, draft-jain-nvo3-overlay-oam-0=
1.txt has been successfully submitted by Kanwar Singh and posted to th=
e
IETF repository.

Name:       =
    draft-jain-nvo3-overlay-oam
Revision:      =
 01
Title:          Generic Overlay OAM and Dat=
apath Failure Detection
Document date:  2014-02-12
Group:  =
        Individual Submission
Pages:     &=
nbsp;    44
URL:            http://www.ietf.org/internet-drafts/draft-ja=
in-nvo3-overlay-oam-01.txt
Status:        &nbs=
p;https://datatracker.ietf.org/doc/draft-jain-nvo=
3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
Diff: &=
nbsp;            http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01

 

 --_000_CF34D8437DF8alohiyajunipernet_-- From nobody Thu Feb 27 20:51:06 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4971A0380 for ; Thu, 27 Feb 2014 20:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9suH44b_wh5B for ; Thu, 27 Feb 2014 20:51:01 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id BA8FD1A0258 for ; Thu, 27 Feb 2014 20:51:01 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1S4ovYC002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 22:50:58 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1S4orwE029525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 05:50:53 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 05:50:53 +0100 From: "Henderickx, Wim (Wim)" To: "S. Davari" , Shahram Davari , Kanwar Singh Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9MqTlu9S0SqbE+B4eOK279kpJrJMP6AgAASA4CAAHIWAIAAZIYA Date: Fri, 28 Feb 2014 04:50:52 +0000 Message-ID: References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> In-Reply-To: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF35D405B2563wimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/YxJJxJXhUgWYkAs6MCoNx_v0lx4 Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 04:51:05 -0000 --_000_CF35D405B2563wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF35D405B2563wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9C0A94D7A48E9A4C8E8243DB67840FF9@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Having different OAM for IP and ETH is not very friendly to the operat= ions people.

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <= ;davarish@yahoo.com>
Date: Friday 28 February 2014 00:50=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Shahram Davari <davari@b= roadcom.com>, Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints.

Thx
SD



Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16= :58
To: Kanwar Singh <kanwar@nuagenetworks.net<= /a>>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rs= hekhar@juniper.net>
Subject: Re: Request for comments:= draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&= gt; wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar

<=
/pre>


<=
/pre>

A new version of I-D, draft=
-jain-nvo3-overlay-oam-01.txt has =
been successfully submitted by Kanwar Singh and posted to the


IETF repository.

Name:       &nb=
sp;   draft-jain-nvo3-overlay-oam
=
Revision:       01
Title=
:          Generic Overlay OAM and Datapath Failur=
e Detection
Document date:  2014-0=
2-12
Group:        =
  Individual Submission
Pages: &nb=
sp;        44
URL: =
           http://www.ietf.org/internet-drafts/draft-=
jain-nvo3-overlay-oam-01.txt
Status:  =
;       https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/<=
br style=3D"font-family:arial, sans-serif;font-size:13px;white-space:normal=
;" clear=3D"none">Htmlized:      http://tools.ietf.org/html/draft-jain-n=
vo3-overlay-oam-01
Diff:     &nb=
sp;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-ove=
rlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   MPLSoGRE and MPLSoUDP a=
nd verifying/sanity of their Control and Data
   Plane for given Overlay Segment.  This document de=
fines the following
   for ea=
ch of the above Overlay Technologies:

   o  Encapsulation of OAM Packet, such th=
at it has same Outer and
    =
  Overlay Header as any End-System's data going over the
 same
      Overlay Segm=
ent.

   o =
 The mechanism to trace the Underlay that is exercised by any      Overlay Segment.
   o  Procedur=
e to verify presence of any given Tenant VM or End-System
      within a given Overlay Segment at=
 Overlay End-Point.

=
   Even though the present proposal addresses Overlay OAM for VXL=
AN,
   NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any ot=
her Overlay Technology.


--_000_CF35D405B2563wimhenderickxalcatellucentcom_-- From nobody Thu Feb 27 21:25:19 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999851A0705 for ; Thu, 27 Feb 2014 21:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYKy9UEKdIJl for ; Thu, 27 Feb 2014 21:25:11 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F51A06E7 for ; Thu, 27 Feb 2014 21:25:11 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id bj1so189692pad.16 for ; Thu, 27 Feb 2014 21:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vx6zvYJYrlhebAJ9OmuKlrsQ8xGWl0xQExEQ4j9sprA=; b=ogP41d13QSjIk3IIbt9zsCXYLgehVtzJMBS8hCfC8O3/wCLUPD4r91sv/0Drddovw1 XUG9rMlbnSwh2R04iTI3VZotsgK/GXGgep4VBHDnoRS2UvTIs3M3kyewSTghf5bTyT98 cWPVVN2XdBhkndb/zrZg/CvkSpDuPmphPczDvLoIYpKz8Lq09UsmEqjWI5xWEpTOU8xF 9c3BvIfUOP5lBBate2d3KK3BZphyfSAGCLfZ8DvCd6OJLP0MPtsbQ3Iz/88yTejnXl4H ru9kQ4MWxTREkMR6tUhlBMmrzKgWMzFlsQxA8s2mpLUyyt9qeZYcRC96ZGuF/AS5LIAw O/ng== X-Received: by 10.68.133.138 with SMTP id pc10mr1272704pbb.98.1393565109582; Thu, 27 Feb 2014 21:25:09 -0800 (PST) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id yg4sm4631932pab.19.2014.02.27.21.25.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 21:25:08 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_096AB678-CF07-4955-8A96-E1000B71E201" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Sam Aldrin In-Reply-To: Date: Thu, 27 Feb 2014 21:25:06 -0800 Message-Id: <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ed_MNWHjql4sGb0Gw-zN74nynF4 Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:25:14 -0000 --Apple-Mail=_096AB678-CF07-4955-8A96-E1000B71E201 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Performing OAM at overlay layer is very important. Extrapolating faults = from underlying layers may provide certain degree of measurement but = cannot completely fulfill the need. This applies to NVo3 as well, IMO. If there are existing mechanisms, one should be able to make use of it, = without having to redo the same. Having said that, we initially published a solution draft around Berlin = IETF. We now have three drafts targeting solution (excluding BFD :D). = The goal is to have 'the' solution meeting the requirements. If BFD or = any other existing solutions meet those, it would be good to outline = that (informational doc?) Looking forward to a good discussion about OAM solution in the NVo3 WG = session. -sam On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) = wrote: > Having different OAM for IP and ETH is not very friendly to the = operations people. >=20 > From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 > To: Wim Henderickx , Shahram Davari = , Kanwar Singh > Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >=20 > I meant using BFD inside the payload. not for the outer tunnel. You = could also use Ethernet OAM for L2 endpoints. >=20 > Thx > SD >=20 >=20 > From: "Henderickx, Wim (Wim)" > To: Shahram Davari ; Kanwar Singh = =20 > Cc: "l2vpn@ietf.org" ; Pradeep Jain = ; Vinay Bannai ; Ravi = Shekhar =20 > Sent: Thursday, February 27, 2014 8:02:45 AM > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >=20 > Because we also need to trace L2 endpoints besides IP endpoint. >=20 > From: Shahram Davari > Date: Thursday 27 February 2014 16:58 > To: Kanwar Singh > Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt >=20 > Hi >=20 > Why don't you use existing IP based OAM messages such as BFD, OWAMP, = TWAMP, etc. >=20 > Regards, > Shahram >=20 >=20 > On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" = wrote: >=20 >> Dear All, >>=20 >> We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks. >>=20 >> We would like to solicit inputs from the members of L2VPN WG. >>=20 >> Please review the same and update us with your inputs/feedback. >>=20 >> Warm Regards >> - Kanwar >>=20 >>=20 >> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been = successfully submitted by Kanwar Singh and posted to the >> IETF repository. >>=20 >> Name: draft-jain-nvo3-overlay-oam >> Revision: 01 >> Title: Generic Overlay OAM and Datapath Failure Detection >> Document date: 2014-02-12 >> Group: Individual Submission >> Pages: 44 >> URL: = http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt >> Status: = https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ >> Htmlized: = http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01 >>=20 >> Abstract: >> This proposal describes a mechanism that can be used to detect = Data >> Path Failures of various overlay technologies as VXLAN, NVGRE, >> MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and = Data >> Plane for given Overlay Segment. This document defines the = following >> for each of the above Overlay Technologies: >>=20 >> o Encapsulation of OAM Packet, such that it has same Outer and >> Overlay Header as any End-System's data going over the same >> Overlay Segment. >>=20 >> o The mechanism to trace the Underlay that is exercised by any >> Overlay Segment. >>=20 >> o Procedure to verify presence of any given Tenant VM or = End-System >> within a given Overlay Segment at Overlay End-Point. >>=20 >> Even though the present proposal addresses Overlay OAM for VXLAN, >> NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are >> generic enough to accommodate OAM for any other Overlay = Technology. >=20 >=20 --Apple-Mail=_096AB678-CF07-4955-8A96-E1000B71E201 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Performing OAM at overlay layer is very important. = Extrapolating faults from underlying layers may provide certain degree = of measurement but cannot completely fulfill the need. This applies to = NVo3 as well, IMO.
If there are existing mechanisms, one should be = able to make use of it, without having to redo the = same.

Having said that, we initially published = a solution draft around Berlin IETF. We now have three drafts targeting = solution (excluding BFD :D). The goal is to have 'the' solution meeting = the requirements. If BFD or any other existing solutions meet those, it = would be good to outline that (informational = doc?)

Looking forward to a good discussion = about OAM solution in the NVo3 WG = session.

-sam
On Feb 27, = 2014, at 8:50 PM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-l= ucent.com> wrote:

Having different OAM for IP and ETH is not very friendly to the = operations people.

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 = 00:50
To: Wim Henderickx <wim.henderickx@alcatel-l= ucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar = Singh <kanwar@nuagenetworks.net><= br> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain = <pradeep@nuagenetworks.net>= ;, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for = comments: draft-jain-nvo3-overlay-oam-01.txt

I meant using BFD inside the payload. not for the outer tunnel. You = could also use Ethernet OAM for L2 endpoints.

Thx
SD


From: "Henderickx, Wim (Wim)" = <wim.henderickx@alcatel-l= ucent.com>
To: Shahram Davari = <davari@broadcom.com>; = Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>; Pradeep Jain = <pradeep@nuagenetworks.net>= ;; Vinay Bannai <vbannai@paypal.com>; = Ravi Shekhar <rshekhar@juniper.net>
Sent: Thursday, = February 27, 2014 8:02:45 AM
Subject: Re: Request = for comments: draft-jain-nvo3-overlay-oam-01.txt

Because we also need to trace L2 endpoints besides IP = endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 = 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net><= br clear=3D"none"> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>= ;, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for = comments: draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, = OWAMP, TWAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> = wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update = us with your inputs/feedback.

Warm Regards
- Kanwar


A new version of =
I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully =
submitted by Kanwar Singh and posted to the
IETF =
repository.

Name:           =
draft-jain-nvo3-overlay-oam
Revision:       01
Title:          Generic Overlay OAM =
and Datapath Failure Detection
Document date:  2014-02-12
Group:          Individual =
Submission
Pages:          44
URL:            http://www.ietf.org/interne=
t-drafts/draft-jain-nvo3-overlay-oam-01.txt
Status:         https://datatracker.ietf.or=
g/doc/draft-jain-nvo3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/=
draft-jain-nvo3-overlay-oam-01
Diff:            =
  http://www.ietf.org/rfcdiff=
?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
   This proposal describes a mechanism that can be =
used to detect Data
   Path Failures of various overlay technologies as =
VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of =
their Control and Data
   Plane for given Overlay Segment.  This =
document defines the following
   for each of the above Overlay =
Technologies:

   o  Encapsulation of OAM Packet, such that it =
has same Outer and
      Overlay Header as any End-System's data =
going over the
 same
      Overlay Segment.

   o  The mechanism to trace the Underlay that =
is exercised by any
      Overlay Segment.

   o  Procedure to verify presence of any given =
Tenant VM or End-System
      within a given Overlay Segment at Overlay =
End-Point.

   Even though the present proposal addresses Overlay =
OAM for VXLAN,
   NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any other =
Overlay Technology.

= --Apple-Mail=_096AB678-CF07-4955-8A96-E1000B71E201-- From nobody Thu Feb 27 21:26:05 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC341A070C for ; Thu, 27 Feb 2014 21:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4N1ZD2Jqyy2 for ; Thu, 27 Feb 2014 21:25:57 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 080221A06E7 for ; Thu, 27 Feb 2014 21:25:56 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-1c-53101ddebc37 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 07.2B.12743.EDD10135; Fri, 28 Feb 2014 06:25:50 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Fri, 28 Feb 2014 00:25:53 -0500 From: Gregory Mirsky To: "Henderickx, Wim (Wim)" , "S. Davari" , Shahram Davari , Kanwar Singh Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mjjo6gwy99EEq/BNrlB6uyMprJlZSAgAABS4CAAILNAIAAU88A//+1IHA= Date: Fri, 28 Feb 2014 05:25:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B77396C@eusaamb103.ericsson.se> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B77396Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXRPgu49WYFggwkP5SzW93paHHzexGgx 738bi8Xjb4fYLR69rLA4cGELo8Xsxz/YHNg9Wp/tZfWYdf8sm8eSJT+ZPK43XWX32DvpNaPH uTlT2TxmzTrMFMAexWWTkpqTWZZapG+XwJXRNUW44PQ2xoq9S1uYGhjfLmLsYuTkkBAwkTjY C2OLSVy4t56ti5GLQ0jgCKPE7pmToJzljBKbd79jBaliEzCSeLGxhx0kISKwhVHixMnl7CAJ ZoFCiUvTJzOB2MICrhKv3q9nAbFFBNwkdq3Yww5h+0k0vP0CNohFQFXiye7VYPW8Ar4SszrX sIHYQgLrmSSmTikBsTkF7CUuf2liBrEZgc77fmoNE8QucYlbT+YzQZwtILFkz3lmCFtU4uXj f6wQtpLEnNfXmCHq8yUOz3gItUtQ4uTMJywTGEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+ Zoaxzxx4zIQsvoCRfRUjR2lxalluupHBJkZg7B6TYNPdwbjnpeUhRmkOFiVx3i9vnYOEBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MM5fv+lUL+N268Cu0vUdZR6+igFbwquKg48vKji+XYd1 z5EAVvOYBdPUigtNTY4afVormbHl/Lvc9vKvnxcZBSxrnGb9rHr7X93CIt21Z85+K/g6rbp/ f7BTyFGLzjn1Wkrt8zapvlm9sTHWo79Na7fDo8PTFOc9qjfqVa2z17hy/fTH+WV37yuxFGck GmoxFxUnAgCL1ovmqwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/R-xnin4SNtmcAluuJDQomTS5hXs Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:26:02 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B77396Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wim, I haven't heard any complains from NOCs operating any multi-layer transport= network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of).= I think this is pretty common though DC operators might see it differently= . Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (W= im) Sent: Thursday, February 27, 2014 8:51 PM To: S. Davari; Shahram Davari; Kanwar Singh Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_7347100B5761DC41A166AC17F22DF1121B77396Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wim,=

I haven’t heard any= complains from NOCs operating any multi-layer transport network. You have = TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differently.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, February 27, 2014 8:51 PM
To: S. Davari; Shahram Davari; Kanwar Singh
Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Having different OAM for IP= and ETH is not very friendly to the operations people.

 

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh= <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I meant using BFD inside the payload. not for the outer tunnel. You coul= d also use Ethernet OAM for L2 endpoints.

Thx
SD

 

 

From: "Henderickx, Wim (Wim)" = <wim.henderickx@alc= atel-lucent.com>
To: Shahram Davari <davari= @broadcom.com>; Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>; Pradeep Jain= <pradeep@nuagenetworks.net= >; Vinay Bannai <vbannai@pa= ypal.com>; Ravi Shekhar <rshekhar@juniper.= net>
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Because we also need to trace L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai= @paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWA= MP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the below draft that proposes Generic OAM and Datapath= Failure Detection Mechanism(s) for Overlay Networks.

 

We would like to solicit inputs from the members of L2VPN WG.=

 

Please review the s= ame and update us with your inputs/feedback.

 

Warm Regards
- Kanwar
 
 
A new version of=
 I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitt=
ed by Kanwar Singh and posted to the
IETF repository.=


Name:           draft-jain-nvo3-overlay-oa=
m
Revision:       01
Title:        =
;  Generic Overlay OAM and Datapath Failure Detection
Document date=
:  2014-02-12
Group:          Individual S=
ubmission
Pages:          44
URL:   &nb=
sp;        http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oa=
m-01.txt
Status:        &nbs=
p;https://datatracker.ietf.or=
g/doc/draft-jain-nvo3-overlay-oam/
Htmlized: &nb=
sp;    http://tools.iet=
f.org/html/draft-jain-nvo3-overlay-oam-01
Diff: =
             http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-n=
vo3-overlay-oam-01

Abstract:
   =
;This proposal describes a mechanism that can be used to detect Data
&nb=
sp;  Path Failures of various overlay technologies as VXLAN, NVGRE,   MPLSoGRE and MPLSoUDP and verifying/sanity of their Control a=
nd Data
   Plane for given Overlay Segment.  This documen=
t defines the following
   for each of the above Overlay Techn=
ologies:

   o  Encapsulation of OAM Packet, such that=
 it has same Outer and
      Overlay Header as any End-Sy=
stem's data going over the same
      Overlay Segment.
   o  The mechanism to trace the Underlay that is exerc=
ised by any
      Overlay Segment.

   o =
 Procedure to verify presence of any given Tenant VM or End-System
=
      within a given Overlay Segment at Overlay End-Point.
   Even though the present proposal addresses Overlay OAM f=
or VXLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures =
described are
   generic enough to accommodate OAM for any oth=
er Overlay Technology.=

 

--_000_7347100B5761DC41A166AC17F22DF1121B77396Ceusaamb103erics_-- From nobody Thu Feb 27 21:32:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899B1A03CB for ; Thu, 27 Feb 2014 21:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWwdrxIrcHFt for ; Thu, 27 Feb 2014 21:32:43 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEC9F1A03FB for ; Thu, 27 Feb 2014 21:32:42 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-50-53101f745571 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 03.3B.12743.47F10135; Fri, 28 Feb 2014 06:32:37 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Fri, 28 Feb 2014 00:32:40 -0500 From: Gregory Mirsky To: Sam Aldrin , "Henderickx, Wim (Wim)" Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mjjo6gwy99EEq/BNrlB6uyMprJlZSAgAABS4CAAILNAIAAU88AgAAJkQD//6yi8A== Date: Fri, 28 Feb 2014 05:32:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B77398C@eusaamb103.ericsson.se> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> In-Reply-To: <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B77398Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLonRLdUXiDY4Ph8LosJrV8YLR5/O8Ru 8ehlhcWBC1sYLWY//sHmwOrR+mwvq8fOWXfZPZYs+cnkcb3pKrvHuTlT2QJYo7hsUlJzMstS i/TtErgynrY/ZS84sYex4tO1uawNjA+XMXYxcnJICJhIHN9xA8oWk7hwbz1bFyMXh5DAEUaJ 6euPMkM4yxkleo5cZgepYhMwknixsQfMFhFIlXj/s4UFxGYWKJS4NH0yE4gtLOAq8er9ehaI GjeJXSv2ANVzANlhEs9aNEBMFgFViRerk0AqeAV8JX62PIBa9YhJYmHzdrBWTgFbifNLPoOt YgQ67vupNUwQq8Qlbj2ZzwRxtIDEkj3nmSFsUYmXj/+xQthKEnNeX2OGqM+X6Nh8iR1imaDE yZlPWCYwis5CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0 I4NNjMCYPCbBpruDcc9Ly0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg 3HxbWk3Se/Flc9/iNDGFl8euHzv7zTdm7/3iT5ppW5/WrSkQuptstSoh5MSDejfnntWpW9Ks D+ztX/P7eZfI7seR35OMpzJbbNdmKvWdNlnlwMnI/ikvpAWW352/KK9R6s9e3SjGbiPNxvhr n941vV15IGF2hnv1UxbtDZPKVk12LuYQOHGTQYmlOCPRUIu5qDgRAESZyBaXAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/YO9VJa24w9W5je6MxNrGm3M3Sok Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:32:47 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B77398Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, wholeheartedly agree with "The goal is to have 'the' solution meeting the r= equirements." Yes! Let's work on requirements, draft-ashwood-nvo3-oam-requi= rements seems as good start already, and then feed into draft-ietf-nvo3-gap= -analysis. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, February 27, 2014 9:25 PM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Performing OAM at overlay layer is very important. Extrapolating faults fro= m underlying layers may provide certain degree of measurement but cannot co= mpletely fulfill the need. This applies to NVo3 as well, IMO. If there are existing mechanisms, one should be able to make use of it, wit= hout having to redo the same. Having said that, we initially published a solution draft around Berlin IET= F. We now have three drafts targeting solution (excluding BFD :D). The goal= is to have 'the' solution meeting the requirements. If BFD or any other ex= isting solutions meet those, it would be good to outline that (informationa= l doc?) Looking forward to a good discussion about OAM solution in the NVo3 WG sess= ion. -sam On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) > wrote: Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_7347100B5761DC41A166AC17F22DF1121B77398Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,=

wholeheartedly agree with= “The goal is to have 'the' solution meeting the requirements.”= Yes! Let’s work on requirements, draft-ashwood-nvo3-oam-requirements seems as good start already, and then feed into draft-ietf-nvo3-gap-analys= is.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Thursday, February 27, 2014 9:25 PM
To: Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Performing OAM at overlay layer is very important. E= xtrapolating faults from underlying layers may provide certain degree of me= asurement but cannot completely fulfill the need. This applies to NVo3 as w= ell, IMO.

If there are existing mechanisms, one should be able= to make use of it, without having to redo the same.

 

Having said that, we initially published a solution = draft around Berlin IETF. We now have three drafts targeting solution (excl= uding BFD :D). The goal is to have 'the' solution meeting the requirements.= If BFD or any other existing solutions meet those, it would be good to outline that (informational doc?)

 

Looking forward to a good discussion about OAM solut= ion in the NVo3 WG session.

 

-sam

On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) &= lt;wim.henderickx@alca= tel-lucent.com> wrote:



Having different OAM for IP and ETH is = not very friendly to the operations people.

 

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh= <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I meant using BFD inside = the payload. not for the outer tunnel. You could also use Ethernet OAM for = L2 endpoints.

Thx
SD

 

 

From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com><= br> To: Shahram Davari <davari= @broadcom.com>; Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>; Pradeep Jain= <pradeep@nuagenetworks.net= >; Vinay Bannai <vbannai@pa= ypal.com>; Ravi Shekhar <rshekhar@juniper.= net>
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Because we also need to t= race L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai= @paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existin= g IP based OAM messages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the bel= ow draft that proposes Generic OAM and Datapath Failure Detection Mechanism= (s) for Overlay Networks.

 

We would like to solicit = inputs from the members of L2VPN WG.

 

Please review the same and upda= te us with your inputs/feedback.

 

Warm Regards
- Kanwar

 

 

A new version of I-D, draft-=
jain-nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar=
 Singh and posted to the


IETF repository.

Name=
:           draft-jain-nvo3-overlay-oam
Revisio=
n:       01
Title:          Gene=
ric Overlay OAM and Datapath Failure Detection
Document date:  2014=
-02-12
Group:          Individual SubmissionPages:          44
URL:       &=
nbsp;    http://www.ietf.org/internet-=
drafts/draft-jain-nvo3-overlay-oam-01.txt
Status:     &nb=
sp;   https://datatracker.ietf.org/doc/draft-ja=
in-nvo3-overlay-oam/
Htmlized:      =
http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
Diff: &nb=
sp;            htt=
p://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01

=
Abstract:
   This proposal describes a mechanism that can be u=
sed to detect Data
   Path Failures of various overlay technol=
ogies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/=
sanity of their Control and Data
   Plane for given Overlay Se=
gment.  This document defines the following
   for each o=
f the above Overlay Technologies:

   o  Encapsulation=
 of OAM Packet, such that it has same Outer and
      Ove=
rlay Header as any End-System's data going over the same
    &=
nbsp; Overlay Segment.

   o  The mechanism to trace t=
he Underlay that is exercised by any
      Overlay Segmen=
t.

   o  Procedure to verify presence of any given Te=
nant VM or End-System
      within a given Overlay Segmen=
t at Overlay End-Point.

   Even though the present proposa=
l addresses Overlay OAM for VXLAN,
   NVGRE, MPLSoGRE and MPLS=
oUDP, but the procedures described are
   generic enough to ac=
commodate OAM for any other Overlay Technology.

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B77398Ceusaamb103erics_-- From nobody Thu Feb 27 21:36:06 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30161A03FB for ; Thu, 27 Feb 2014 21:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyzM9A1goPD9 for ; Thu, 27 Feb 2014 21:36:00 -0800 (PST) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A01A03CB for ; Thu, 27 Feb 2014 21:36:00 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,560,1389772800"; d="scan'208,217"; a="16994399" Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw2-out.broadcom.com with ESMTP; 27 Feb 2014 21:52:23 -0800 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 21:35:58 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 21:35:58 -0800 From: Shahram Davari To: "Henderickx, Wim (Wim)" Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mh8gEtCy0e4EuWLz1WxAmt5prJQcOtgACHZ4CAAILMAIAAU9AA//+GfMY= Date: Fri, 28 Feb 2014 05:35:57 +0000 Message-ID: <66B9B000-060B-4A03-8F3B-94B3EBF132F2@broadcom.com> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_66B9B000060B4A038F3B94B3EBF132F2broadcomcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/i2YgQs0JuO9y1aMHFzhkkunc0kM Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:36:04 -0000 --_000_66B9B000060B4A038F3B94B3EBF132F2broadcomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But having a brand newly invented OAM is friendly ? Regards, Shahram On Feb 27, 2014, at 8:51 PM, "Henderickx, Wim (Wim)" > wrote: Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_66B9B000060B4A038F3B94B3EBF132F2broadcomcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
But having a brand newly invented OAM is friendly ?

Regards,
Shahram


On Feb 27, 2014, at 8:51 PM, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent= .com> wrote:

Having different OAM for IP and ETH is not very friendly to the operat= ions people.

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <= ;davarish@yahoo.com>
Date: Friday 28 February 2014 00:50=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Shahram Davari <davari@b= roadcom.com>, Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints.

Thx
SD



Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16= :58
To: Kanwar Singh <kanwar@nuagenetworks.net<= /a>>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rs= hekhar@juniper.net>
Subject: Re: Request for comments:= draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&= gt; wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar

<=
/pre>


<=
/pre>

A new version of I-D, draft=
-jain-nvo3-overlay-oam-01.txt has =
been successfully submitted by Kanwar Singh and posted to the


IETF repository.

Name:       &nb=
sp;   draft-jain-nvo3-overlay-oam
=
Revision:       01
Title=
:          Generic Overlay OAM and Datapath Failur=
e Detection
Document date:  2014-0=
2-12
Group:        =
  Individual Submission
Pages: &nb=
sp;        44
URL: =
           http://www.ietf.org/internet-drafts/draft-=
jain-nvo3-overlay-oam-01.txt
Status:  =
;       https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/<=
br style=3D"font-family:arial, sans-serif;font-size:13px;white-space:normal=
;" clear=3D"none">Htmlized:      http://tools.ietf.org/html/draft-jain-n=
vo3-overlay-oam-01
Diff:     &nb=
sp;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-ove=
rlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   MPLSoGRE and MPLSoUDP a=
nd verifying/sanity of their Control and Data
   Plane for given Overlay Segment.  This document de=
fines the following
   for ea=
ch of the above Overlay Technologies:

   o  Encapsulation of OAM Packet, such th=
at it has same Outer and
    =
  Overlay Header as any End-System's data going over the
 same
      Overlay Segm=
ent.

   o =
 The mechanism to trace the Underlay that is exercised by any      Overlay Segment.
   o  Procedur=
e to verify presence of any given Tenant VM or End-System
      within a given Overlay Segment at=
 Overlay End-Point.

=
   Even though the present proposal addresses Overlay OAM for VXL=
AN,
   NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any ot=
her Overlay Technology.


--_000_66B9B000060B4A038F3B94B3EBF132F2broadcomcom_-- From nobody Thu Feb 27 21:37:10 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828FB1A070D for ; Thu, 27 Feb 2014 21:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_-W_zdkO6J1 for ; Thu, 27 Feb 2014 21:37:03 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3D1A0345 for ; Thu, 27 Feb 2014 21:37:03 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id jt11so286757pbb.28 for ; Thu, 27 Feb 2014 21:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AHtC04yJN+DIE9uP/gxV9vf9EbnPTpVlmwvGrt4gADw=; b=WKDpJ+rhRD4Q/JmxTcviHF4kDM3OoA6l1YEDGQFE3N642i2kiBAXgDGSvtrG+MACZh HT39zRe9HDEiBRVxcvGdpuv8+4QNUfLSe1JTVAwVc7PSieZjzwUGt+azrOA9xAE7xmzH g+vdRopZG9/svFX9oGQew4GdVhWg/D7pymAz3co3MijWHGFfF5f36qeCpZ8v6xu4ZHmw V2H1clfHvCdfgOJ8XfUnmi54LMlNctpaLAoqiTaiLf9Gp3xt5b71oSuZ63tbRILLTuh7 8Hh34xSGj7lXIs6shwu99FNqFrfwmea0lQUKsTnMvlbsqYZwKG2X2OMPIh617DFVRzP6 8fuQ== X-Received: by 10.66.136.71 with SMTP id py7mr1423084pab.2.1393565821866; Thu, 27 Feb 2014 21:37:01 -0800 (PST) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id ce15sm4979351pac.0.2014.02.27.21.37.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 21:37:00 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6F956D6-7B11-407C-8842-71D15EF98F8C" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Sam Aldrin In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B77398C@eusaamb103.ericsson.se> Date: Thu, 27 Feb 2014 21:36:58 -0800 Message-Id: <3077BF5C-C052-4F10-A145-9AF0DD4EAB6F@gmail.com> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> <7347100B5761DC41A166AC17F22DF1121B77398C@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/NTdy8RYU34W2oSEniw6tmOQwEKI Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:37:07 -0000 --Apple-Mail=_F6F956D6-7B11-407C-8842-71D15EF98F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Greg, I do not think solution will get ahead of requirements :D But it is good to think through solutions as long it feeds into better = requirements and explore reusability of existing solutions/architecture. -sam On Feb 27, 2014, at 9:32 PM, Gregory Mirsky = wrote: > Hi Sam, > wholeheartedly agree with =93The goal is to have 'the' solution = meeting the requirements.=94 Yes! Let=92s work on requirements, = draft-ashwood-nvo3-oam-requirements seems as good start already, and = then feed into draft-ietf-nvo3-gap-analysis. > =20 > Regards, > Greg > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, February 27, 2014 9:25 PM > To: Henderickx, Wim (Wim) > Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > =20 > Performing OAM at overlay layer is very important. Extrapolating = faults from underlying layers may provide certain degree of measurement = but cannot completely fulfill the need. This applies to NVo3 as well, = IMO. > If there are existing mechanisms, one should be able to make use of = it, without having to redo the same. > =20 > Having said that, we initially published a solution draft around = Berlin IETF. We now have three drafts targeting solution (excluding BFD = :D). The goal is to have 'the' solution meeting the requirements. If BFD = or any other existing solutions meet those, it would be good to outline = that (informational doc?) > =20 > Looking forward to a good discussion about OAM solution in the NVo3 WG = session. > =20 > -sam > On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) = wrote: >=20 >=20 > Having different OAM for IP and ETH is not very friendly to the = operations people. > =20 > From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 > To: Wim Henderickx , Shahram Davari = , Kanwar Singh > Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > =20 > I meant using BFD inside the payload. not for the outer tunnel. You = could also use Ethernet OAM for L2 endpoints. >=20 > Thx > SD > =20 > =20 > From: "Henderickx, Wim (Wim)" > To: Shahram Davari ; Kanwar Singh = =20 > Cc: "l2vpn@ietf.org" ; Pradeep Jain = ; Vinay Bannai ; Ravi = Shekhar =20 > Sent: Thursday, February 27, 2014 8:02:45 AM > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > =20 > Because we also need to trace L2 endpoints besides IP endpoint. > =20 > From: Shahram Davari > Date: Thursday 27 February 2014 16:58 > To: Kanwar Singh > Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > =20 > Hi > =20 > Why don't you use existing IP based OAM messages such as BFD, OWAMP, = TWAMP, etc. >=20 > Regards, > Shahram > =20 >=20 > On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" = wrote: >=20 > Dear All, > =20 > We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks. > =20 > We would like to solicit inputs from the members of L2VPN WG. > =20 > Please review the same and update us with your inputs/feedback. > =20 > Warm Regards > - Kanwar > =20 > =20 > A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been = successfully submitted by Kanwar Singh and posted to the > IETF repository. >=20 > Name: draft-jain-nvo3-overlay-oam > Revision: 01 > Title: Generic Overlay OAM and Datapath Failure Detection > Document date: 2014-02-12 > Group: Individual Submission > Pages: 44 > URL: = http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt > Status: = https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ > Htmlized: = http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01 >=20 > Abstract: > This proposal describes a mechanism that can be used to detect Data > Path Failures of various overlay technologies as VXLAN, NVGRE, > MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and = Data > Plane for given Overlay Segment. This document defines the = following > for each of the above Overlay Technologies: >=20 > o Encapsulation of OAM Packet, such that it has same Outer and > Overlay Header as any End-System's data going over the same > Overlay Segment. >=20 > o The mechanism to trace the Underlay that is exercised by any > Overlay Segment. >=20 > o Procedure to verify presence of any given Tenant VM or = End-System > within a given Overlay Segment at Overlay End-Point. >=20 > Even though the present proposal addresses Overlay OAM for VXLAN, > NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are > generic enough to accommodate OAM for any other Overlay Technology. --Apple-Mail=_F6F956D6-7B11-407C-8842-71D15EF98F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Greg,

I do not think solution will get ahead of = requirements :D
But it is good to think through solutions as = long it feeds into better requirements and explore reusability of = existing = solutions/architecture.

-sam
On = Feb 27, 2014, at 9:32 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Sam,
wholeheartedly agree with =93The = goal is to have 'the' solution meeting the requirements.=94 Yes! Let=92s = work on requirements, draft-ashwood-nvo3-oam-requirements seems as good = start already, and then feed into = draft-ietf-nvo3-gap-analysis.
 
           &= nbsp;    Regards,
           &= nbsp;           &nb= sp;        = Greg
From: L2vpn [mailto:l2vpn-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Sam = Aldrin
Sent: Thursday, February 27, 2014 = 9:25 PM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Vinay Bannai; Ravi = Shekhar
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt
 
Performing OAM at overlay layer is very important. Extrapolating = faults from underlying layers may provide certain degree of measurement = but cannot completely fulfill the need. This applies to NVo3 as well, = IMO.
If there are = existing mechanisms, one should be able to make use of it, without = having to redo the same.
 
Having said that, we initially published a solution draft around = Berlin IETF. We now have three drafts targeting solution (excluding BFD = :D). The goal is to have 'the' solution meeting the requirements. If BFD = or any other existing solutions meet those, it would be good to outline = that (informational doc?)
 
Looking forward to a good discussion about OAM solution in the = NVo3 WG session.
 
-sam
On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> = wrote:


Having = different OAM for IP and ETH is not very friendly to the operations = people.
 
From: "S. Davari" = <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 = 00:50
To: Wim = Henderickx <wim.henderickx@alcatel-lucent.com>, Shahram Davari = <davari@broadcom.com>, Kanwar Singh = <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay = Bannai <vbannai@paypal.com>, Ravi Shekhar = <rshekhar@juniper.net>
Subject: Re: Request for = comments: = draft-jain-nvo3-overlay-oam-01.txt
 
I meant using BFD inside the payload. = not for the outer tunnel. You could also use Ethernet OAM for L2 = endpoints.

Thx
SD
 
 
From: "Henderickx, Wim (Wim)" = <wim.henderickx@alcatel-lucent.com>
To: Shahram Davari <davari@broadcom.com>; Kanwar Singh = <kanwar@nuagenetworks.net> 
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>; Pradeep Jain <pradeep@nuagenetworks.net>; Vinay = Bannai <vbannai@paypal.com>; Ravi Shekhar = <rshekhar@juniper.net> 
Sent: Thursday, February 27, 2014 = 8:02:45 AM
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt
 
Because we also need to trace L2 endpoints = besides IP endpoint.
 
From: Shahram = Davari <davari@broadcom.com>
Date: Thursday 27 February = 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi = Shekhar <rshekhar@juniper.net>
Subject: Re: Request for = comments: = draft-jain-nvo3-overlay-oam-01.txt
 
Hi
 
Why don't you use existing IP based OAM = messages such as BFD, OWAMP, TWAMP, = etc.

Regards,
Shahram
 


On Feb 27, 2014, at = 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> = wrote:

Dear All,
 
We have submitted the below = draft that proposes Generic OAM and Datapath Failure Detection = Mechanism(s) for Overlay Networks.
 
We would like to solicit inputs from the = members of L2VPN WG.
 
Please review the same and update us with your = inputs/feedback.
 
Warm =
Regards
- Kanwar
 
 
A new version of I-D, =
draft-jain-nvo3-overlay-oam-01.txt has been successfully submitted =
by Kanwar Singh and posted to the
IETF repository.

Name: =
          =
draft-jain-nvo3-overlay-oam
Revision:       =
01
Title:          Generic Overlay OAM and =
Datapath Failure Detection
Document date:  2014-02-12
Group: =
         Individual Submission
Pages:   =
       44
URL:           =
 http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-o=
am-01.txt
Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/=

Htmlized: =
     http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
Diff:   =
           http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oa=
m-01

Abstract:
   This proposal describes a =
mechanism that can be used to detect Data
   Path Failures =
of various overlay technologies as VXLAN, NVGRE,
  =
 MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and =
Data
   Plane for given Overlay Segment.  This =
document defines the following
   for each of the above =
Overlay Technologies:

   o  Encapsulation of OAM =
Packet, such that it has same Outer and
      Overlay =
Header as any End-System's data going over the same
    =
  Overlay Segment.

   o  The mechanism to =
trace the Underlay that is exercised by any
      =
Overlay Segment.

   o  Procedure to verify =
presence of any given Tenant VM or End-System
      =
within a given Overlay Segment at Overlay End-Point.

  =
 Even though the present proposal addresses Overlay OAM for =
VXLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures =
described are
   generic enough to accommodate OAM for any =
other Overlay =
Technology.
<= /div>

= --Apple-Mail=_F6F956D6-7B11-407C-8842-71D15EF98F8C-- From nobody Thu Feb 27 21:37:47 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55931A0715 for ; Thu, 27 Feb 2014 21:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4pqtadgMlaZ for ; Thu, 27 Feb 2014 21:37:44 -0800 (PST) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id D89111A0295 for ; Thu, 27 Feb 2014 21:37:43 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,560,1389772800"; d="scan'208,217"; a="16994954" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 27 Feb 2014 21:54:07 -0800 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.8) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 21:37:41 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 21:37:41 -0800 From: Shahram Davari To: Sam Aldrin Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mh8gEtCy0e4EuWLz1WxAmt5prJQcOtgACHZ4CAAILMAIAAU9AAgAAJkAD//31oRw== Date: Fri, 28 Feb 2014 05:37:40 +0000 Message-ID: References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> , <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> In-Reply-To: <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F11FF1D767F74A249F1E25E5BED6B515broadcomcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/0y_ak2A5qQfes9aANWc1ijDbNFk Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:37:47 -0000 --_000_F11FF1D767F74A249F1E25E5BED6B515broadcomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I didn't suggest extrapolation. I think you even don't know your OAM is run= ning at which later. Regards, Shahram On Feb 27, 2014, at 9:25 PM, "Sam Aldrin" > wrote: Performing OAM at overlay layer is very important. Extrapolating faults fro= m underlying layers may provide certain degree of measurement but cannot co= mpletely fulfill the need. This applies to NVo3 as well, IMO. If there are existing mechanisms, one should be able to make use of it, wit= hout having to redo the same. Having said that, we initially published a solution draft around Berlin IET= F. We now have three drafts targeting solution (excluding BFD :D). The goal= is to have 'the' solution meeting the requirements. If BFD or any other ex= isting solutions meet those, it would be good to outline that (informationa= l doc?) Looking forward to a good discussion about OAM solution in the NVo3 WG sess= ion. -sam On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) > wrote: Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_F11FF1D767F74A249F1E25E5BED6B515broadcomcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I didn't suggest extrapolation. I think you even don't know your OAM i= s running at which later.

Regards,
Shahram


On Feb 27, 2014, at 9:25 PM, "Sam Aldrin" <aldrin.ietf@gmail.com> wrote:

Performing OAM at overlay layer is very important. Extrapolating fault= s from underlying layers may provide certain degree of measurement but cann= ot completely fulfill the need. This applies to NVo3 as well, IMO.
If there are existing mechanisms, one should be able to make use of it= , without having to redo the same.

Having said that, we initially published a solution draft around Berli= n IETF. We now have three drafts targeting solution (excluding BFD :D). The= goal is to have 'the' solution meeting the requirements. If BFD or any oth= er existing solutions meet those, it would be good to outline that (informational doc?)

Looking forward to a good discussion about OAM solution in the NVo3 WG= session.

-sam
On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com= > wrote:

Having different OAM for IP and ETH is not very friendly to the operat= ions people.

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <= ;davarish@yahoo.com>
Date: Friday 28 February 2014 00:50=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Shahram Davari <davari@b= roadcom.com>, Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints.

Thx
SD



Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16= :58
To: Kanwar Singh <kanwar@nuagenetworks.net<= /a>>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rs= hekhar@juniper.net>
Subject: Re: Request for comments:= draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&= gt; wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar

<=
/pre>


<=
/pre>

A new version of I-D, draft=
-jain-nvo3-overlay-oam-01.txt has =
been successfully submitted by Kanwar Singh and posted to the


IETF repository.

Name:       &nb=
sp;   draft-jain-nvo3-overlay-oam
=
Revision:       01
Title=
:          Generic Overlay OAM and Datapath Failur=
e Detection
Document date:  2014-0=
2-12
Group:        =
  Individual Submission
Pages: &nb=
sp;        44
URL: =
           http://www.ietf.org/internet-drafts/draft-=
jain-nvo3-overlay-oam-01.txt
Status:  =
;       https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/<=
br style=3D"font-family:arial, sans-serif;font-size:13px;white-space:normal=
;" clear=3D"none">Htmlized:      http://tools.ietf.org/html/draft-jain-n=
vo3-overlay-oam-01
Diff:     &nb=
sp;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-ove=
rlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   MPLSoGRE and MPLSoUDP a=
nd verifying/sanity of their Control and Data
   Plane for given Overlay Segment.  This document de=
fines the following
   for ea=
ch of the above Overlay Technologies:

   o  Encapsulation of OAM Packet, such th=
at it has same Outer and
    =
  Overlay Header as any End-System's data going over the
 same
      Overlay Segm=
ent.

   o =
 The mechanism to trace the Underlay that is exercised by any      Overlay Segment.
   o  Procedur=
e to verify presence of any given Tenant VM or End-System
      within a given Overlay Segment at=
 Overlay End-Point.

=
   Even though the present proposal addresses Overlay OAM for VXL=
AN,
   NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any ot=
her Overlay Technology.



--_000_F11FF1D767F74A249F1E25E5BED6B515broadcomcom_-- From nobody Thu Feb 27 21:39:32 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AFE1A0295 for ; Thu, 27 Feb 2014 21:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up7xTcGFOuaV for ; Thu, 27 Feb 2014 21:39:27 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 85CDE1A03CB for ; Thu, 27 Feb 2014 21:39:27 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id rr13so288366pbb.29 for ; Thu, 27 Feb 2014 21:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ngvbKDU1k3fsGGomZhmpg/hJdA9B7ZqXeihV09MT1Z0=; b=k84FCsEaT9UVDnf0etrDNLCLTIXn6kHvYrZpNMsAmastR2pHUC0kPWDPk6/8UsdEHC jR2znUVub/ht3/jpjp14SClKJcUEpl1hpz2mSnyLLWF8xxR+z2KdyDqiHwPE5XB/Bu7h 0O4h03OwFmZbAUfu+CWK/3mQ6ate03q1TZs5t6Yx2gFpPeCgF2lYjUdCSIuxbTQv9nTz eL90PLKeczV4Hf0PU+pT3Rzqd4c6DUkiZMBEg10aMr03+KdWJFphuEOWVP5rGeA+jcKS 4Ry2WU7y6gj9jW6U0/uiAvyd/hWZbd5Kjneohhh9s4NKM11yZROqWj5SitAVwXHNVhmQ MvLw== X-Received: by 10.68.143.34 with SMTP id sb2mr1170972pbb.135.1393565965890; Thu, 27 Feb 2014 21:39:25 -0800 (PST) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id my6sm1966468pbc.36.2014.02.27.21.39.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 21:39:24 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DDB8C5A4-F342-4C70-AA22-083F976BE07A" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Sam Aldrin In-Reply-To: Date: Thu, 27 Feb 2014 21:39:23 -0800 Message-Id: <9B204D02-00D6-4AFC-BC30-F2AAA14C9032@gmail.com> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> , <7A311A7D-7F51-4E41-9605-E349352007C3@gmail.com> To: Shahram Davari X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/WqnmcIaQiXsGnI7Hbl1HYCStujo Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:39:30 -0000 --Apple-Mail=_DDB8C5A4-F342-4C70-AA22-083F976BE07A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii and where does it say 'you said it'. On Feb 27, 2014, at 9:37 PM, Shahram Davari wrote: > I didn't suggest extrapolation. I think you even don't know your OAM = is running at which later. >=20 > Regards, > Shahram >=20 >=20 > On Feb 27, 2014, at 9:25 PM, "Sam Aldrin" = wrote: >=20 >> Performing OAM at overlay layer is very important. Extrapolating = faults from underlying layers may provide certain degree of measurement = but cannot completely fulfill the need. This applies to NVo3 as well, = IMO. >> If there are existing mechanisms, one should be able to make use of = it, without having to redo the same. >>=20 >> Having said that, we initially published a solution draft around = Berlin IETF. We now have three drafts targeting solution (excluding BFD = :D). The goal is to have 'the' solution meeting the requirements. If BFD = or any other existing solutions meet those, it would be good to outline = that (informational doc?) >>=20 >> Looking forward to a good discussion about OAM solution in the NVo3 = WG session. >>=20 >> -sam >> On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) = wrote: >>=20 >>> Having different OAM for IP and ETH is not very friendly to the = operations people. >>>=20 >>> From: "S. Davari" >>> Reply-To: "S. Davari" >>> Date: Friday 28 February 2014 00:50 >>> To: Wim Henderickx , Shahram = Davari , Kanwar Singh >>> Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar >>> Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt >>>=20 >>> I meant using BFD inside the payload. not for the outer tunnel. You = could also use Ethernet OAM for L2 endpoints. >>>=20 >>> Thx >>> SD >>>=20 >>>=20 >>> From: "Henderickx, Wim (Wim)" >>> To: Shahram Davari ; Kanwar Singh = =20 >>> Cc: "l2vpn@ietf.org" ; Pradeep Jain = ; Vinay Bannai ; Ravi = Shekhar =20 >>> Sent: Thursday, February 27, 2014 8:02:45 AM >>> Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt >>>=20 >>> Because we also need to trace L2 endpoints besides IP endpoint. >>>=20 >>> From: Shahram Davari >>> Date: Thursday 27 February 2014 16:58 >>> To: Kanwar Singh >>> Cc: "l2vpn@ietf.org" , Pradeep Jain = , Vinay Bannai , Ravi = Shekhar >>> Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt >>>=20 >>> Hi >>>=20 >>> Why don't you use existing IP based OAM messages such as BFD, OWAMP, = TWAMP, etc. >>>=20 >>> Regards, >>> Shahram >>>=20 >>>=20 >>> On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" = wrote: >>>=20 >>>> Dear All, >>>>=20 >>>> We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks. >>>>=20 >>>> We would like to solicit inputs from the members of L2VPN WG. >>>>=20 >>>> Please review the same and update us with your inputs/feedback. >>>>=20 >>>> Warm Regards >>>> - Kanwar >>>>=20 >>>>=20 >>>> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been = successfully submitted by Kanwar Singh and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-jain-nvo3-overlay-oam >>>> Revision: 01 >>>> Title: Generic Overlay OAM and Datapath Failure Detection >>>> Document date: 2014-02-12 >>>> Group: Individual Submission >>>> Pages: 44 >>>> URL: = http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt >>>> Status: = https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ >>>> Htmlized: = http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 >>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-oam-01 >>>>=20 >>>> Abstract: >>>> This proposal describes a mechanism that can be used to detect = Data >>>> Path Failures of various overlay technologies as VXLAN, NVGRE, >>>> MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and = Data >>>> Plane for given Overlay Segment. This document defines the = following >>>> for each of the above Overlay Technologies: >>>>=20 >>>> o Encapsulation of OAM Packet, such that it has same Outer and >>>> Overlay Header as any End-System's data going over the same >>>> Overlay Segment. >>>>=20 >>>> o The mechanism to trace the Underlay that is exercised by any >>>> Overlay Segment. >>>>=20 >>>> o Procedure to verify presence of any given Tenant VM or = End-System >>>> within a given Overlay Segment at Overlay End-Point. >>>>=20 >>>> Even though the present proposal addresses Overlay OAM for = VXLAN, >>>> NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are >>>> generic enough to accommodate OAM for any other Overlay = Technology. >>>=20 >>>=20 >>=20 --Apple-Mail=_DDB8C5A4-F342-4C70-AA22-083F976BE07A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii and = where does it say 'you said it'.

On Feb 27, 2014, at = 9:37 PM, Shahram Davari <davari@broadcom.com> = wrote:

I didn't suggest extrapolation. I think you even don't know your = OAM is running at which later.

Regards,
Shahram


On Feb 27, 2014, at 9:25 PM, "Sam Aldrin" <aldrin.ietf@gmail.com> = wrote:

Performing OAM at overlay layer is very important. Extrapolating = faults from underlying layers may provide certain degree of measurement = but cannot completely fulfill the need. This applies to NVo3 as well, = IMO.
If there are existing mechanisms, one should be able to make use of = it, without having to redo the same.

Having said that, we initially published a solution draft around = Berlin IETF. We now have three drafts targeting solution (excluding BFD = :D). The goal is to have 'the' solution meeting the requirements. If BFD = or any other existing solutions meet those, it would be good to outline that (informational doc?)

Looking forward to a good discussion about OAM solution in the NVo3 = WG session.

-sam
On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) <wim.henderickx@alcatel-l= ucent.com> wrote:

Having different OAM for IP and ETH is not very friendly to the = operations people.

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 = 00:50
To: Wim Henderickx <wim.henderickx@alcatel-l= ucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar = Singh <kanwar@nuagenetworks.net><= br> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain = <pradeep@nuagenetworks.net>= ;, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for = comments: draft-jain-nvo3-overlay-oam-01.txt

I meant using BFD inside the payload. not for the outer tunnel. You = could also use Ethernet OAM for L2 endpoints.

Thx
SD


From: "Henderickx, Wim (Wim)" = <wim.henderickx@alcatel-l= ucent.com>
To: Shahram Davari = <davari@broadcom.com>; = Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>; Pradeep Jain = <pradeep@nuagenetworks.net>= ;; Vinay Bannai <vbannai@paypal.com>; = Ravi Shekhar <rshekhar@juniper.net>
Sent: Thursday, = February 27, 2014 8:02:45 AM
Subject: Re: Request = for comments: draft-jain-nvo3-overlay-oam-01.txt

Because we also need to trace L2 endpoints besides IP = endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 = 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net><= br clear=3D"none"> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>= ;, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for = comments: draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, = OWAMP, TWAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net> = wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and = Datapath Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update = us with your inputs/feedback.

Warm Regards
- Kanwar


A new version of =
I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully =
submitted by Kanwar Singh and posted to the
IETF =
repository.

Name:           =
draft-jain-nvo3-overlay-oam
Revision:       01
Title:          Generic Overlay OAM =
and Datapath Failure Detection
Document date:  2014-02-12
Group:          Individual =
Submission
Pages:          44
URL:            http://www.ietf.org/interne=
t-drafts/draft-jain-nvo3-overlay-oam-01.txt
Status:         https://datatracker.ietf.or=
g/doc/draft-jain-nvo3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/=
draft-jain-nvo3-overlay-oam-01
Diff:            =
  http://www.ietf.org/rfcdiff=
?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
   This proposal describes a mechanism that can be =
used to detect Data
   Path Failures of various overlay technologies as =
VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of =
their Control and Data
   Plane for given Overlay Segment.  This =
document defines the following
   for each of the above Overlay =
Technologies:

   o  Encapsulation of OAM Packet, such that it =
has same Outer and
      Overlay Header as any End-System's data =
going over the
 same
      Overlay Segment.

   o  The mechanism to trace the Underlay that =
is exercised by any
      Overlay Segment.

   o  Procedure to verify presence of any given =
Tenant VM or End-System
      within a given Overlay Segment at Overlay =
End-Point.

   Even though the present proposal addresses Overlay =
OAM for VXLAN,
   NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any other =
Overlay Technology.




= --Apple-Mail=_DDB8C5A4-F342-4C70-AA22-083F976BE07A-- From nobody Thu Feb 27 21:45:51 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7A01A0345 for ; Thu, 27 Feb 2014 21:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9wE3QTkUt_A for ; Thu, 27 Feb 2014 21:45:47 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA31A01CD for ; Thu, 27 Feb 2014 21:45:47 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-bf-5310228539df Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.4B.12743.58220135; Fri, 28 Feb 2014 06:45:41 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Fri, 28 Feb 2014 00:45:44 -0500 From: Gregory Mirsky To: Pradeep Jain , Shahram Davari Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mjjo6gwy99EEq/BNrlB6uyMprJlZSAgAABS4CAAADRAIAAJSOAgAARFQCAADeD14AAIt/g Date: Fri, 28 Feb 2014 05:45:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7739D7@eusaamb103.ericsson.se> References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7739D7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPgm6rkkCwwden5hbrez0tHn87xG7x 7doJFotHLyssDlzYwujA6jHr/lk2jyVLfjJ5XG+6yu6xd9JrRo9zc6ayBbBGcdmkpOZklqUW 6dslcGXMX32WqeBJXsWR7ReZGhhvJHQxcnBICJhInOhy62LkBDLFJC7cW8/WxcjFISRwhFFi y5KlLCAJIYHljBL7/luD2GwCRhIvNvawg9giAiESX/7+ZQKxmQUKJS5NnwxmCwu4Srx6v54F osZNYteKPewgu0QEoiT2NtaAhFkEVCVmzZvHCGLzCvhKnJ14kx1i1VdmiXNz+EBsToFAieZP M9lAbEag276fWgO1Slzi1pP5TBA3C0gs2XOeGcIWlXj5+B8rhK0kMef1NWaQtcwC+RJtd5kg VglKnJz5hGUCo+gsJJNmIVTNQlIFUaIjsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1O LctNNzLYxAiMwmMSbLo7GPe8tDzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxsns0zs3vPydtOzz1/fRczg0mfO1N71+XaTmt09gk/iJW9kOGhUXRVq3hk1Ic3y/c+1P /sC/khXK3IccWV9xKj/m8BN87LD40LOJjVwv1/kpas1L/XLFkiEtYqVGiuLuC3NlOm0E9yZc UKnY4rHi9pXl4SvlL/355HV/4iT3rR+S1zN5PLdUU1ZiKc5INNRiLipOBAA6KBfUkAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/xE_W4wSVK043DkEiP1MkKoCPsa0 Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:45:50 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7739D7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pradeep, I'd refer you to documents on Seamless BFD that, in many aspects, requireme= nts you've listed. Even though BFD WG would not meet in London, we can have= a talk about S-BFD and NVO3 OAM requirements. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Pradeep Jain Sent: Thursday, February 27, 2014 7:38 PM To: Shahram Davari Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt On Thursday, February 27, 2014, Pradeep Jain > wrote: Hi Shahram, Using BFD mandates that the probes need to be sent continuously. We don't w= ant to impose this restriction and leave it to the user to decide if they w= ant an on-demand probe or a continuous probe, which is what has been define= d in the draft.. Regarding the second point about including VNI/VSID in TLV, for the hardwar= e/forwarding plane which is not capable of giving the overlay context of th= e packet (based on VNI/VSID) to the control plane, we need to rely on the V= NI/VSID in the TLV to derive the overlay context in the control plane... Regards Pradeep On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari > wrote: Anil, I don't agree. If you use for example BFD for inner IP, and if BFD says con= nectivity is OK, this implies that the Overlay connectivity is also OK, sin= ce BFD is inside the overlay. Also I am not sure why you are adding the VNI, VSID, etc in the message as = TLV, since these value are already in the packet header. Thx Shahram From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya Sent: Thursday, February 27, 2014 10:19 AM To: Thomas Nadeau; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi= Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Existing ping/traceroute mechanisms don't work in the virtualized environme= nt e.g. ping may report that IP reachability between the ingress and egress= tunnel endpoints is fine but the end systems (i.e. VM, physical server etc= .) connectivity for a tenant could still be broken. This is because ping on= ly verifies basic connectivity between two endpoints in the underlay but NO= T in the context of overlay segments. Hence, we need debugging tools that w= ork in the overlay environment. Think why there was a need to have lsp ping= ... requirement with IP overlays is not much different. Question is not whether applications are resilient or not... One can not ig= nore the fact that operators have to think about having the right tools whe= n that "inevitable" call comes from their customer about deteriorating app= lication performance or traffic blackhole and there are no tools today spec= ific to overlay network debugging. - Anil From: Thomas Nadeau > Date: Thursday, February 27, 2014 8:05 AM To: "Henderickx, Wim (Wim)" < --_000_7347100B5761DC41A166AC17F22DF1121B7739D7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pradeep,

I’d refer you to do= cuments on Seamless BFD that, in many aspects, requirements you’ve li= sted. Even though BFD WG would not meet in London, we can have a talk about S-BFD and NVO3 OAM requirements.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Pradeep Jain
Sent: Thursday, February 27, 2014 7:38 PM
To: Shahram Davari
Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 



On Thursday, February 27, 2014, Pradeep Jain <pradeep@nuagenetworks.net> wrote:

Hi Shahram,

 

Using BFD mandates that the probes need to be sent c= ontinuously. We don't want to impose this restriction and leave it to the u= ser to decide if they want an on-demand probe or a continuous probe, which = is what has been defined in the draft..

 

Regarding the second point about including VNI/VSID = in TLV, for the hardware/forwarding plane which is not capable of giving th= e overlay context of the packet (based on VNI/VSID) to the control plane, w= e need to rely on the VNI/VSID in the TLV to derive the overlay context in the control plane...

 

Regards
Pradeep

 

On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari <= ;davari@broadcom.com> wrote:

Anil,

 

I don’t agree. If you use for example B= FD for inner IP, and if BFD says connectivity is OK, this implies that the = Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why you are adding the VNI= , VSID, etc in the message as TLV, since these value are already in the pac= ket header.

 

Thx
Shahram

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)


Cc: l2vpn@ietf.org; Pradeep Ja= in; Vinay Bannai; Ravi Shekhar

Subject: Re: Request for comments: draft-jain= -nvo3-overlay-oam-01.txt

 

 

Existing ping/traceroute mechanisms don't work in the virtu= alized environment e.g. ping may report that IP reachability between the in= gress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) connectivity for a tenant could st= ill be broken. This is because ping only verifies basic connectivity betwee= n two endpoints in the underlay but NOT in the context of overlay segments.= Hence, we need debugging tools that work in the overlay environment. Think why there was a need to have l= sp ping … requirement with IP overlays is not much different.<= o:p>

 

Question is not whether applications are resilient or not&#= 8230; One can not ignore the fact that operators have to think about having= the right tools when that "inevitable" call  comes from the= ir customer about deteriorating application performance or traffic blackhole = and there are no tools today specific to overlay network debugging.<= o:p>

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <

 

--_000_7347100B5761DC41A166AC17F22DF1121B7739D7eusaamb103erics_-- From nobody Thu Feb 27 21:50:19 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934781A0345 for ; Thu, 27 Feb 2014 21:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIt5mEcFi05i for ; Thu, 27 Feb 2014 21:50:15 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDDF1A0295 for ; Thu, 27 Feb 2014 21:50:15 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fa1so303217pad.14 for ; Thu, 27 Feb 2014 21:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2xL2lxR6jsrOXN1aJ21Sl2Qez4ZycV42mqySis8g69k=; b=YWrfccSRjQsESrJFoH98te4tH5oXx5dfIBJ/sIe4A0wAq0nVYHQM4gti8R7cv56Nt3 zfBHJ8FVkDG7EUMigC86QAShzfC+9aBLQNG36vnRW/B6omn80dqKaG2h7qnwmH07e5L8 NffUSkz4YEBjHkW5JoGX6nI1X0Z+HrNqhmCzw+18Ds+GR1bn5biRpKZz7UkybFItO+Tn TnidJdnx06wrZjl4a1nh32PsU6aiU0xMzG/APSj3ehJwPRZ77Zl/JjD9ap+Preftuko0 5Q/KU7M87bjHnY/jQkrvB5HVPp3jU3vlSMpqld2KOMQk3Pk5zOPo7QKdWhJtknNtBxDA uNcw== X-Received: by 10.68.197.99 with SMTP id it3mr1283013pbc.37.1393566613462; Thu, 27 Feb 2014 21:50:13 -0800 (PST) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id iq10sm2098710pbc.14.2014.02.27.21.50.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 21:50:12 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F8EA7F88-90C6-4295-B955-29E106F19E40" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Sam Aldrin In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7739D7@eusaamb103.ericsson.se> Date: Thu, 27 Feb 2014 21:50:09 -0800 Message-Id: <5F89009C-3E63-4FE8-8259-CDE979EA953A@gmail.com> References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B7739D7@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/-R0NWCM4t0bOCEEhR8rBu-IrBRs Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 05:50:17 -0000 --Apple-Mail=_F8EA7F88-90C6-4295-B955-29E106F19E40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ to = start off with On Feb 27, 2014, at 9:45 PM, Gregory Mirsky = wrote: > Hi Pradeep, > I=92d refer you to documents on Seamless BFD that, in many aspects, = requirements you=92ve listed. Even though BFD WG would not meet in = London, we can have a talk about S-BFD and NVO3 OAM requirements. > =20 > Regards, > Greg > =20 > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Pradeep Jain > Sent: Thursday, February 27, 2014 7:38 PM > To: Shahram Davari > Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > =20 >=20 >=20 > On Thursday, February 27, 2014, Pradeep Jain = wrote: > Hi Shahram, > =20 > Using BFD mandates that the probes need to be sent continuously. We = don't want to impose this restriction and leave it to the user to decide = if they want an on-demand probe or a continuous probe, which is what has = been defined in the draft.. > =20 > Regarding the second point about including VNI/VSID in TLV, for the = hardware/forwarding plane which is not capable of giving the overlay = context of the packet (based on VNI/VSID) to the control plane, we need = to rely on the VNI/VSID in the TLV to derive the overlay context in the = control plane... > =20 > Regards > Pradeep > =20 >=20 > On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari = wrote: > Anil, >=20 > =20 >=20 > I don=92t agree. If you use for example BFD for inner IP, and if BFD = says connectivity is OK, this implies that the Overlay connectivity is = also OK, since BFD is inside the overlay. >=20 > Also I am not sure why you are adding the VNI, VSID, etc in the = message as TLV, since these value are already in the packet header. >=20 > =20 >=20 > Thx > Shahram >=20 > =20 >=20 > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya > Sent: Thursday, February 27, 2014 10:19 AM > To: Thomas Nadeau; Henderickx, Wim (Wim) >=20 >=20 > Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > =20 >=20 > =20 >=20 > Existing ping/traceroute mechanisms don't work in the virtualized = environment e.g. ping may report that IP reachability between the = ingress and egress tunnel endpoints is fine but the end systems (i.e. = VM, physical server etc.) connectivity for a tenant could still be = broken. This is because ping only verifies basic connectivity between = two endpoints in the underlay but NOT in the context of overlay = segments. Hence, we need debugging tools that work in the overlay = environment. Think why there was a need to have lsp ping =85 requirement = with IP overlays is not much different. >=20 > =20 >=20 > Question is not whether applications are resilient or not=85 One can = not ignore the fact that operators have to think about having the right = tools when that "inevitable" call comes from their customer about = deteriorating application performance or traffic blackhole and there are = no tools today specific to overlay network debugging. >=20 > =20 >=20 > - Anil >=20 > =20 >=20 > From: Thomas Nadeau > Date: Thursday, February 27, 2014 8:05 AM > To: "Henderickx, Wim (Wim)" < >=20 --Apple-Mail=_F8EA7F88-90C6-4295-B955-29E106F19E40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/=  to start off with
On Feb 27, 2014, at 9:45 PM, = Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Pradeep,
I=92d refer you to = documents on Seamless BFD that, in many aspects, requirements you=92ve = listed. Even though BFD WG would not meet in London, we can have a talk = about S-BFD and NVO3 OAM requirements.
 
           &= nbsp;    Regards,
           &= nbsp;           &nb= sp;        = Greg
 
From: L2vpn [mailto:l2vpn-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Pradeep = Jain
Sent: Thursday, February 27, 2014 = 7:38 PM
To: Shahram = Davari
Cc: l2vpn@ietf.org; Vinay Bannai; Ravi = Shekhar
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt
 


On Thursday, February 27, 2014, Pradeep Jain <pradeep@nuagenetworks.net> = wrote:
Hi = Shahram,
 
Using = BFD mandates that the probes need to be sent continuously. We don't want = to impose this restriction and leave it to the user to decide if they = want an on-demand probe or a continuous probe, which is what has been = defined in the draft..
 
Regarding the second point about including VNI/VSID in TLV, for = the hardware/forwarding plane which is not capable of giving the overlay = context of the packet (based on VNI/VSID) to the control plane, we need = to rely on the VNI/VSID in the TLV to derive the overlay context in the = control plane...
 
Regards
Pradeep

 

On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari = <davari@broadcom.com> = wrote:

Anil,

 

I don=92t = agree. If you use for example BFD for inner IP, and if BFD says = connectivity is OK, this implies that the Overlay connectivity is also = OK, since BFD is inside the overlay.

Also I am = not sure why you are adding the VNI, VSID, etc in the message as TLV, = since these value are already in the packet = header.

 

Thx
Shahram

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil = Lohiya
Sent: Thursday, February 27, 2014 = 10:19 AM
To: Thomas Nadeau; Henderickx, = Wim (Wim)


Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi = Shekhar
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt
=

 

 

Existing ping/traceroute = mechanisms don't work in the virtualized environment e.g. ping may = report that IP reachability between the ingress and egress tunnel = endpoints is fine but the end systems (i.e. VM, physical server etc.) = connectivity for a tenant could still be broken. This is because ping = only verifies basic connectivity between two endpoints in the underlay = but NOT in the context of overlay segments. Hence, we need debugging = tools that work in the overlay environment. Think why there was a need = to have lsp ping =85 requirement with IP overlays is not much = different.

 

Question is not whether = applications are resilient or not=85 One can not ignore the fact that = operators have to think about having the right tools when that = "inevitable" call  comes from their customer about deteriorating = application performance or traffic blackhole and there are no tools = today specific to overlay network = debugging.

 

- = Anil

 

From: Thomas = Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, = 2014 8:05 AM
To: "Henderickx, Wim (Wim)" = <


= --Apple-Mail=_F8EA7F88-90C6-4295-B955-29E106F19E40-- From nobody Thu Feb 27 22:02:33 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD271A03FC for ; Thu, 27 Feb 2014 22:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWmgamTnBITQ for ; Thu, 27 Feb 2014 22:02:28 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 69FD81A0713 for ; Thu, 27 Feb 2014 22:02:28 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1S62NE6009856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 00:02:24 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1S62Jwb023921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 07:02:20 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 07:02:19 +0100 From: "Henderickx, Wim (Wim)" To: Shahram Davari Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9MqTlu9S0SqbE+B4eOK279kpJrJMP6AgAASA4CAAHIWAIAAZIYA///74YCAABgaAA== Date: Fri, 28 Feb 2014 06:02:19 +0000 Message-ID: References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> <66B9B000-060B-4A03-8F3B-94B3EBF132F2@broadcom.com> In-Reply-To: <66B9B000-060B-4A03-8F3B-94B3EBF132F2@broadcom.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF35E4D0B25A5wimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vT4MUTPV6bf0NQnzahu7xcJaAMw Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 06:02:32 -0000 --_000_CF35E4D0B25A5wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is basically the same procedure as people OAM IP/MPLS networks. If it = is not friendly why do we keep on extending these mechanisms From: Shahram Davari > Date: Friday 28 February 2014 06:35 To: Wim Henderickx > Cc: "S. Davari" >, Kanwar Sin= gh >, "l2vpn@ietf= .org" >, Prade= ep Jain >, Vina= y Bannai >, Ravi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt But having a brand newly invented OAM is friendly ? Regards, Shahram On Feb 27, 2014, at 8:51 PM, "Henderickx, Wim (Wim)" > wrote: Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF35E4D0B25A5wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <49D1558F94884648ADCF11CE7BF8C85C@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
This is basically the same procedure as people OAM IP/MPLS networks. I= f it is not friendly why do we keep on extending these mechanisms

From: Shahram Davari <davari@broadcom.com>
Date: Friday 28 February 2014 06:35=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>
Cc: "S. Davari" <davarish@yahoo.com>, Kanwar Singh &= lt;kanwar@nuagenetworks.net= >, "l2vpn@ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuag= enetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

But having a brand newly invented OAM is friendly ?

Regards,
Shahram


On Feb 27, 2014, at 8:51 PM, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent= .com> wrote:

Having different OAM for IP and ETH is not very friendly to the operat= ions people.

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <= ;davarish@yahoo.com>
Date: Friday 28 February 2014 00:50=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Shahram Davari <davari@b= roadcom.com>, Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints.

Thx
SD



Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16= :58
To: Kanwar Singh <kanwar@nuagenetworks.net<= /a>>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rs= hekhar@juniper.net>
Subject: Re: Request for comments:= draft-jain-nvo3-overlay-oam-01.txt

Hi

Why don't you use existing IP based OAM messages such as BFD, OWAMP, T= WAMP, etc.

Regards,
Shahram


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&= gt; wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapa= th Failure Detection Mechanism(s) for Overlay Networks.

We would like to solicit inputs from the members of L2VPN WG.

Please review the same and update us w= ith your inputs/feedback.

Warm Regards
- Kanwar

<=
/pre>


<=
/pre>

A new version of I-D, draft=
-jain-nvo3-overlay-oam-01.txt has =
been successfully submitted by Kanwar Singh and posted to the


IETF repository.

Name:       &nb=
sp;   draft-jain-nvo3-overlay-oam
=
Revision:       01
Title=
:          Generic Overlay OAM and Datapath Failur=
e Detection
Document date:  2014-0=
2-12
Group:        =
  Individual Submission
Pages: &nb=
sp;        44
URL: =
           http://www.ietf.org/internet-drafts/draft-=
jain-nvo3-overlay-oam-01.txt
Status:  =
;       https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/<=
br style=3D"font-family:arial, sans-serif;font-size:13px;white-space:normal=
;" clear=3D"none">Htmlized:      http://tools.ietf.org/html/draft-jain-n=
vo3-overlay-oam-01
Diff:     &nb=
sp;        http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-ove=
rlay-oam-01

Abstract:
   This proposal describes a m=
echanism that can be used to detect Data
   MPLSoGRE and MPLSoUDP a=
nd verifying/sanity of their Control and Data
   Plane for given Overlay Segment.  This document de=
fines the following
   for ea=
ch of the above Overlay Technologies:

   o  Encapsulation of OAM Packet, such th=
at it has same Outer and
    =
  Overlay Header as any End-System's data going over the
 same
      Overlay Segm=
ent.

   o =
 The mechanism to trace the Underlay that is exercised by any      Overlay Segment.
   o  Procedur=
e to verify presence of any given Tenant VM or End-System
      within a given Overlay Segment at=
 Overlay End-Point.

=
   Even though the present proposal addresses Overlay OAM for VXL=
AN,
   NVGRE,
 MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any ot=
her Overlay Technology.


--_000_CF35E4D0B25A5wimhenderickxalcatellucentcom_-- From nobody Thu Feb 27 22:05:22 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72321A071D for ; Thu, 27 Feb 2014 22:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYfP6Cv8Na5q for ; Thu, 27 Feb 2014 22:05:18 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 826C81A0713 for ; Thu, 27 Feb 2014 22:05:18 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1S65BZK011834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 00:05:13 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1S658FA024859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 07:05:08 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 07:05:08 +0100 From: "Henderickx, Wim (Wim)" To: Gregory Mirsky , "S. Davari" , Shahram Davari , Kanwar Singh Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9MqTlu9S0SqbE+B4eOK279kpJrJMP6AgAASA4CAAHIWAIAAZIYA///5EACAABu1AA== Date: Fri, 28 Feb 2014 06:05:07 +0000 Message-ID: References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> <7347100B5761DC41A166AC17F22DF1121B77396C@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B77396C@eusaamb103.ericsson.se> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF35E546B25ABwimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/MmqmGzBaxDQLYEM2FCWL2VBgkRo Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 06:05:21 -0000 --_000_CF35E546B25ABwimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I let NOC people comment on there own, but this is feedback I received from= people operating these deployments. In this space you basically have IP an= d ETH, so lets optimise this rather than making life difficult for people. From: Gregory Mirsky > Date: Friday 28 February 2014 06:25 To: Wim Henderickx >, "S. Davari" >, Shahram Davari >, = Kanwar Singh > Cc: "l2vpn@ietf.org" >, Vinay Bannai >, Rav= i Shekhar > Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Wim, I haven=92t heard any complains from NOCs operating any multi-layer transpo= rt network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of= ). I think this is pretty common though DC operators might see it different= ly. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (W= im) Sent: Thursday, February 27, 2014 8:51 PM To: S. Davari; Shahram Davari; Kanwar Singh Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF35E546B25ABwimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <829ACB62B915A8439F2645CA54F5C0B1@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
I let NOC people comment on there own, but this is feedback I received= from people operating these deployments. In this space you basically have = IP and ETH, so lets optimise this rather than making life difficult for peo= ple.

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Friday 28 February 2014 06:25=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, "S. Davari" <da= varish@yahoo.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh <kanwar@nuagen= etworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: RE: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Hi Wim,

I haven=92t heard any complains fro= m NOCs operating any multi-layer transport network. You have TDM/OTN OAM, E= thernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differ= ently.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, February 27, 2014 8:51 PM
To: S. Davari; Shahram Davari; Kanwar Singh
Cc: l2vpn@ietf.org; Vinay Bann= ai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Having different OAM for IP and ETH is not v= ery friendly to the operations people.

 

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh= <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I meant using BFD inside the payload. not for the outer tunnel. You coul= d also use Ethernet OAM for L2 endpoints.

Thx
SD

 

 

From:wim.henderickx@alcatel-lucent.com>
To: Shahram Davari <davari= @broadcom.com>; Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>; Pradeep Jain= <pradeep@nuagenetworks.net= >; Vinay Bannai <vbannai@pa= ypal.com>; Ravi Shekhar <rshekhar@juniper.= net>
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Because we also need to trace L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai= @paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWA= MP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the below draft that proposes Generic OAM and Datapath= Failure Detection Mechanism(s) for Overlay Networks.

 

We would like to solicit inputs from the members of L2VPN WG.=

 

Please review the same and update us w= ith your inputs/feedback.

 

Warm Regards
- Kanwar
 
 
A new version of I-D, draft-jain-nv=
o3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh =
and posted to the

IETF repository.

Name:  =
;         draft-jain-nvo3-overlay-oam
Revision: &nbs=
p;     01
Title:          Generic Ove=
rlay OAM and Datapath Failure Detection
Document date:  2014-02-12<=
br>Group:          Individual Submission
Pages:=
          44
URL:         &=
nbsp;  http://www.ietf.org/internet-=
drafts/draft-jain-nvo3-overlay-oam-01.txt
Status:     &nb=
sp;   https://datatracker.ietf.org/doc/d=
raft-jain-nvo3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01<=
br>Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-=
oam-01

Abstract:
   This proposal describes a mech=
anism that can be used to detect Data
   Path Failures of vari=
ous overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLS=
oUDP and verifying/sanity of their Control and Data
   Plane f=
or given Overlay Segment.  This document defines the following
&nbs=
p;  for each of the above Overlay Technologies:

   o =
 Encapsulation of OAM Packet, such that it has same Outer and
 =
;     Overlay Header as any End-System's data going over the same=

      Overlay Segment.

   o  The m=
echanism to trace the Underlay that is exercised by any
    &n=
bsp; Overlay Segment.

   o  Procedure to verify prese=
nce of any given Tenant VM or End-System
      within a g=
iven Overlay Segment at Overlay End-Point.

   Even though =
the present proposal addresses Overlay OAM for VXLAN,
   NVGRE=
, MPLSoGRE and MPLSoUDP, but the procedures described are
   g=
eneric enough to accommodate OAM for any other Overlay Technology.

 

 --_000_CF35E546B25ABwimhenderickxalcatellucentcom_-- From nobody Thu Feb 27 22:09:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530761A0416 for ; Thu, 27 Feb 2014 22:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJCpBjrXj5_2 for ; Thu, 27 Feb 2014 22:09:02 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F34E01A03FC for ; Thu, 27 Feb 2014 22:09:01 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-ea-531027fcb95d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 03.6E.11484.CF720135; Fri, 28 Feb 2014 07:09:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Fri, 28 Feb 2014 01:08:59 -0500 From: Gregory Mirsky To: "Henderickx, Wim (Wim)" , "S. Davari" , Shahram Davari , Kanwar Singh Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9Mjjo6gwy99EEq/BNrlB6uyMprJlZSAgAABS4CAAILNAIAAU88A//+1IHCAAF+fgP//rGMQ Date: Fri, 28 Feb 2014 06:08:57 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B773A12@eusaamb103.ericsson.se> References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> <7347100B5761DC41A166AC17F22DF1121B77396C@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B773A12eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyuXRPlO5fdYFgg/V3mCzW93paHHzexGgx 738bi8Xjb4fYLR69rLA4cGELo8Xsxz/YHNg9Wp/tZfWYdf8sm8eSJT+ZPK43XWX32DvpNaPH uTlT2TxmzTrMFMAexWWTkpqTWZZapG+XwJUxcfY25oI/Lxgrjm4+zNjAePoCYxcjJ4eEgInE hGcvmSBsMYkL99azdTFycQgJHGGU2P37CjOEs5xR4vH83WBVbAJGEi829rCDJEQEtjBKnDi5 nB0kwSxQKHFp+mSwImEBV4lX79ezgNgiAm4Su1bsYYewoyRWXZ4CFmcRUJXY/eIGM4jNK+Ar cW/1UqhtK5gljkzeD1bEKWAvse/vGbBbGYHu+35qDRPEMnGJW0/mQ90tILFkz3lmCFtU4uXj f6wQtpLEx9/zoY7Ll+h42sMGsUxQ4uTMJywTGEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+ Zoaxzxx4zIQsvoCRfRUjR2lxalluupHhJkZg/B6TYHPcwbjgk+UhRmkOFiVx3i9vnYOEBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MOoe/hA5SUIwNmOvxL0jZgLCbr+U325esGvfopoLv899 dJ1kuu377Rj3Yz92xvsWGzZWJf360Fj6s1T/yNkDHmltW/2MjD4HLSs/W76rzXNy1xvX5lcN 526/Yp+15nvczIXbGyIVubsmBC1mVFPQlzXebsrz0cPFRCu0paHUze2ddWlMiP6fy0osxRmJ hlrMRcWJAHojwemtAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/SOSLOnO1avm2CfjBvP1oVfT9WoA Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 06:09:06 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B773A12eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wim, I think it is reasonable to start with requirements before diving into disc= ussion of a solution. Input from operators would be most valuable. Regards, Greg From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, February 27, 2014 10:05 PM To: Gregory Mirsky; S. Davari; Shahram Davari; Kanwar Singh Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I let NOC people comment on there own, but this is feedback I received from= people operating these deployments. In this space you basically have IP an= d ETH, so lets optimise this rather than making life difficult for people. From: Gregory Mirsky > Date: Friday 28 February 2014 06:25 To: Wim Henderickx >, "S. Davari" >, Shahram Davari >, = Kanwar Singh > Cc: "l2vpn@ietf.org" >, Vinay Bannai >, Rav= i Shekhar > Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Wim, I haven't heard any complains from NOCs operating any multi-layer transport= network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of).= I think this is pretty common though DC operators might see it differently= . Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (W= im) Sent: Thursday, February 27, 2014 8:51 PM To: S. Davari; Shahram Davari; Kanwar Singh Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_7347100B5761DC41A166AC17F22DF1121B773A12eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wim,=

I think it is reasonable = to start with requirements before diving into discussion of a solution. Inp= ut from operators would be most valuable.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Henderic= kx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Thursday, February 27, 2014 10:05 PM
To: Gregory Mirsky; S. Davari; Shahram Davari; Kanwar Singh
Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I let NOC people comment on= there own, but this is feedback I received from people operating these dep= loyments. In this space you basically have IP and ETH, so lets optimise this rather than making life difficult for people.

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Friday 28 February 2014 06:25
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, "S. Davari" &l= t;davarish@yahoo.com>, Shahram= Davari <davari@broadcom.com&= gt;, Kanwar Singh <kanwar@nuagen= etworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Vinay Bannai= <vbannai@paypal.com>, Ravi= Shekhar <rshekhar@juniper.net>
Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi Wim,

I haven’t heard any= complains from NOCs operating any multi-layer transport network. You have = TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differently.=

 

    &= nbsp;           Regards,<= /span>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 

From: L2vpn [mailto:l2v= pn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, February 27, 2014 8:51 PM
To: S. Davari; Shahram Davari; Kanwar Singh
Cc: l2vpn@ietf.org; Vinay Bann= ai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 =

Having different OAM for IP= and ETH is not very friendly to the operations people.

 

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh= <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I meant using BFD inside the payload. not for the outer tunnel. You coul= d also use Ethernet OAM for L2 endpoints.

Thx
SD

 

 

From: "Henderickx, Wim (Wim)" = <wim.henderickx@alc= atel-lucent.com>
To: Shahram Davari <davari= @broadcom.com>; Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>; Pradeep Jain= <pradeep@nuagenetworks.net= >; Vinay Bannai <vbannai@pa= ypal.com>; Ravi Shekhar <rshekhar@juniper.= net>
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Because we also need to trace L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai= @paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWA= MP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the below draft that proposes Generic OAM and Datapath= Failure Detection Mechanism(s) for Overlay Networks.

 

We would like to solicit inputs from the members of L2VPN WG.=

 

Please review the s= ame and update us with your inputs/feedback.

 

Warm Regards
- Kanwar
 
 
A new version of=
 I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitt=
ed by Kanwar Singh and posted to the
IETF repository.=


Name:           draft-jain-nvo3-overlay-oa=
m
Revision:       01
Title:        =
;  Generic Overlay OAM and Datapath Failure Detection
Document date=
:  2014-02-12
Group:          Individual S=
ubmission
Pages:          44
URL:   &nb=
sp;        http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oa=
m-01.txt
Status:        &nbs=
p;https://datatracker.ietf.or=
g/doc/draft-jain-nvo3-overlay-oam/
Htmlized: &nb=
sp;    http://tools.iet=
f.org/html/draft-jain-nvo3-overlay-oam-01
Diff: =
             http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-n=
vo3-overlay-oam-01

Abstract:
   =
;This proposal describes a mechanism that can be used to detect Data
&nb=
sp;  Path Failures of various overlay technologies as VXLAN, NVGRE,   MPLSoGRE and MPLSoUDP and verifying/sanity of their Control a=
nd Data
   Plane for given Overlay Segment.  This documen=
t defines the following
   for each of the above Overlay Techn=
ologies:

   o  Encapsulation of OAM Packet, such that=
 it has same Outer and
      Overlay Header as any End-Sy=
stem's data going over the same
      Overlay Segment.
   o  The mechanism to trace the Underlay that is exerc=
ised by any
      Overlay Segment.

   o =
 Procedure to verify presence of any given Tenant VM or End-System
=
      within a given Overlay Segment at Overlay End-Point.
   Even though the present proposal addresses Overlay OAM f=
or VXLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures =
described are
   generic enough to accommodate OAM for any oth=
er Overlay Technology.=

 

--_000_7347100B5761DC41A166AC17F22DF1121B773A12eusaamb103erics_-- From nobody Thu Feb 27 23:59:55 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E411A075C for ; Thu, 27 Feb 2014 23:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta-AadgFRncp for ; Thu, 27 Feb 2014 23:59:50 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48A1A075B for ; Thu, 27 Feb 2014 23:59:50 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1S7xiMm000751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 01:59:45 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1S7xelm014052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 08:59:40 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 08:59:40 +0100 From: "Henderickx, Wim (Wim)" To: Gregory Mirsky , "S. Davari" , Shahram Davari , Kanwar Singh Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Thread-Index: AQHPM9MqTlu9S0SqbE+B4eOK279kpJrJMP6AgAASA4CAAHIWAIAAZIYA///5EACAABu1AP//8FWAgAAvqwA= Date: Fri, 28 Feb 2014 07:59:39 +0000 Message-ID: References: <1393545054.56142.YahooMailNeo@web162501.mail.bf1.yahoo.com> <7347100B5761DC41A166AC17F22DF1121B77396C@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B773A12@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B773A12@eusaamb103.ericsson.se> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF360072B25FFwimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/GlczuT84qgiVIHOlfeVrGm_swNw Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 07:59:54 -0000 --_000_CF360072B25FFwimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable sure From: Gregory Mirsky > Date: Friday 28 February 2014 07:08 To: Wim Henderickx >, "S. Davari" >, Shahram Davari >, = Kanwar Singh > Cc: "l2vpn@ietf.org" >, Vinay Bannai >, Rav= i Shekhar > Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Wim, I think it is reasonable to start with requirements before diving into disc= ussion of a solution. Input from operators would be most valuable. Regards, Greg From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, February 27, 2014 10:05 PM To: Gregory Mirsky; S. Davari; Shahram Davari; Kanwar Singh Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I let NOC people comment on there own, but this is feedback I received from= people operating these deployments. In this space you basically have IP an= d ETH, so lets optimise this rather than making life difficult for people. From: Gregory Mirsky > Date: Friday 28 February 2014 06:25 To: Wim Henderickx >, "S. Davari" >, Shahram Davari >, = Kanwar Singh > Cc: "l2vpn@ietf.org" >, Vinay Bannai >, Rav= i Shekhar > Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Wim, I haven=92t heard any complains from NOCs operating any multi-layer transpo= rt network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of= ). I think this is pretty common though DC operators might see it different= ly. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (W= im) Sent: Thursday, February 27, 2014 8:51 PM To: S. Davari; Shahram Davari; Kanwar Singh Cc: l2vpn@ietf.org; Vinay Bannai; Ravi Shekhar Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Having different OAM for IP and ETH is not very friendly to the operations = people. From: "S. Davari" > Reply-To: "S. Davari" > Date: Friday 28 February 2014 00:50 To: Wim Henderickx >, Shahram Davari >, Kanwar Singh > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt I meant using BFD inside the payload. not for the outer tunnel. You could a= lso use Ethernet OAM for L2 endpoints. Thx SD ________________________________ From: "Henderickx, Wim (Wim)" > To: Shahram Davari >; Kanwa= r Singh > Cc: "l2vpn@ietf.org" >; Pradeep Jain >; Vinay Bannai >; Ra= vi Shekhar > Sent: Thursday, February 27, 2014 8:02:45 AM Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Because we also need to trace L2 endpoints besides IP endpoint. From: Shahram Davari > Date: Thursday 27 February 2014 16:58 To: Kanwar Singh = > Cc: "l2vpn@ietf.org" >, Pradeep Jain >, Vinay Bannai >, Ra= vi Shekhar > Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt Hi Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP,= etc. Regards, Shahram On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: Dear All, We have submitted the below draft that proposes Generic OAM and Datapath Fa= ilure Detection Mechanism(s) for Overlay Networks. We would like to solicit inputs from the members of L2VPN WG. Please review the same and update us with your inputs/feedback. Warm Regards - Kanwar A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfu= lly submitted by Kanwar Singh and posted to the IETF repository. Name: draft-jain-nvo3-overlay-oam Revision: 01 Title: Generic Overlay OAM and Datapath Failure Detection Document date: 2014-02-12 Group: Individual Submission Pages: 44 URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay= -oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oa= m/ Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overl= ay-oam-01 Abstract: This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. --_000_CF360072B25FFwimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
sure

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Friday 28 February 2014 07:08=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, "S. Davari" <da= varish@yahoo.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh <kanwar@nuagen= etworks.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: RE: Request for comments: = draft-jain-nvo3-overlay-oam-01.txt

Hi Wim,

I think it is reasonable to start w= ith requirements before diving into discussion of a solution. Input from op= erators would be most valuable.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Thursday, February 27, 2014 10:05 PM
To: Gregory Mirsky; S. Davari; Shahram Davari; Kanwar Singh
Cc: l2vpn@ietf.org; Vinay Bann= ai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I let NOC people comment on there own, but t= his is feedback I received from people operating these deployments. In this= space you basically have IP and ETH, so lets optimise this rather than making life difficult for people.

 

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Friday 28 February 2014 06:25
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, "S. Davari" &l= t;davarish@yahoo.com>, Shahram= Davari <davari@broadcom.com&= gt;, Kanwar Singh <kanwar@nuagen= etworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Vinay Bannai= <vbannai@paypal.com>, Ravi= Shekhar <rshekhar@juniper.net>
Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi Wim,

I haven=92t heard any complains fro= m NOCs operating any multi-layer transport network. You have TDM/OTN OAM, E= thernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differ= ently.

 

      = ;          Regards,

      = ;            &n= bsp;            = ; Greg

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, February 27, 2014 8:51 PM
To: S. Davari; Shahram Davari; Kanwar Singh
Cc: l2vpn@ietf.org; Vinay Bann= ai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 =

Having different OAM for IP and ETH is not v= ery friendly to the operations people.

 

From: "S. Davari" <davarish@yahoo.com>
Reply-To: "S. Davari" <davarish@yahoo.com>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Shahram Davari <davari@broadcom.com>, Kanwar Singh= <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>, Pradeep Jain= <pradeep@nuagenetworks.net= >, Vinay Bannai <vbannai@pa= ypal.com>, Ravi Shekhar <rshekhar@juniper.= net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

I meant using BFD inside the payload. not for the outer tunnel. You coul= d also use Ethernet OAM for L2 endpoints.

Thx
SD

 

 

From:wim.henderickx@alcatel-lucent.com>
To: Shahram Davari <davari= @broadcom.com>; Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>; Pradeep Jain= <pradeep@nuagenetworks.net= >; Vinay Bannai <vbannai@pa= ypal.com>; Ravi Shekhar <rshekhar@juniper.= net>
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Because we also need to trace L2 endpoints besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai= @paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWA= MP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the below draft that proposes Generic OAM and Datapath= Failure Detection Mechanism(s) for Overlay Networks.

 

We would like to solicit inputs from the members of L2VPN WG.=

 

Please review the same and update us w= ith your inputs/feedback.

 

Warm Regards
- Kanwar
 
 
A new version of I-D, draft-jain-nv=
o3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh =
and posted to the

IETF repository.

Name:  =
;         draft-jain-nvo3-overlay-oam
Revision: &nbs=
p;     01
Title:          Generic Ove=
rlay OAM and Datapath Failure Detection
Document date:  2014-02-12<=
br>Group:          Individual Submission
Pages:=
          44
URL:         &=
nbsp;  http://www.ietf.org/internet-=
drafts/draft-jain-nvo3-overlay-oam-01.txt
Status:     &nb=
sp;   https://datatracker.ietf.org/doc/d=
raft-jain-nvo3-overlay-oam/
Htmlized:      http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01<=
br>Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overlay-=
oam-01

Abstract:
   This proposal describes a mech=
anism that can be used to detect Data
   Path Failures of vari=
ous overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLS=
oUDP and verifying/sanity of their Control and Data
   Plane f=
or given Overlay Segment.  This document defines the following
&nbs=
p;  for each of the above Overlay Technologies:

   o =
 Encapsulation of OAM Packet, such that it has same Outer and
 =
;     Overlay Header as any End-System's data going over the same=

      Overlay Segment.

   o  The m=
echanism to trace the Underlay that is exercised by any
    &n=
bsp; Overlay Segment.

   o  Procedure to verify prese=
nce of any given Tenant VM or End-System
      within a g=
iven Overlay Segment at Overlay End-Point.

   Even though =
the present proposal addresses Overlay OAM for VXLAN,
   NVGRE=
, MPLSoGRE and MPLSoUDP, but the procedures described are
   g=
eneric enough to accommodate OAM for any other Overlay Technology.

 

 --_000_CF360072B25FFwimhenderickxalcatellucentcom_-- From nobody Fri Feb 28 00:26:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68771A00CB; Fri, 28 Feb 2014 00:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvY8VT9h3Jux; Fri, 28 Feb 2014 00:26:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 08EA11A0017; Fri, 28 Feb 2014 00:26:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBP37159; Fri, 28 Feb 2014 08:26:41 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 08:26:17 +0000 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 08:26:23 +0000 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 16:26:16 +0800 From: Zhuangshunwan To: , References: <20140214001110.27377.41608.idtracker@ietfa.amsl.com> In-Reply-To: <20140214001110.27377.41608.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt Date: Fri, 28 Feb 2014 16:26:15 +0800 Message-ID: <000401cf345e$bfc34790$3f49d6b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8pGVmHAvvRvDBZSmSXzfrFpcJJLALRARFw Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/9dy8uiOFoDM32GRXFsc3AMM3sZY Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 08:26:47 -0000 Dear Authors, I have a minor question, see inline. 8.4.1.1.1 Auto-Derivation from the Ethernet Tag ID The following is the procedure for deriving the RT attribute automatically from the Ethernet Tag ID associated with the advertisement: + The Global Administrator field of the RT MUST be set to the Autonomous System (AS) number that the PE belongs to. Vincent: Here Global Administrator field contains a 2 octets long = number, but the Autonomous System (AS) number could be 4 octets, how to = handle such case? + The Local Administrator field of the RT contains a 4 octets long number that encodes the Ethernet Tag-ID. If the Ethernet Tag-ID is a two octet VLAN ID then it MUST be encoded in the lower two octets of the Local Administrator=20 field and the higher two octets MUST be set to zero. Regards, Vincent -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: L2vpn [mailto:l2vpn-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 internet-drafts@ietf.org =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8814=E6=97=A5 = 8:11 =E6=94=B6=E4=BB=B6=E4=BA=BA: i-d-announce@ietf.org =E6=8A=84=E9=80=81: l2vpn@ietf.org =E4=B8=BB=E9=A2=98: I-D Action: draft-ietf-l2vpn-evpn-05.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 : BGP MPLS Based Ethernet VPN Authors : Ali Sajassi Rahul Aggarwal Wim Henderickx Aldrin Isaac James Uttaro Filename : draft-ietf-l2vpn-evpn-05.txt Pages : 49 Date : 2014-02-13 Abstract: This document describes procedures for BGP MPLS based Ethernet VPNs (EVPN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-evpn-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 28 00:31:18 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086331A03B5 for ; Fri, 28 Feb 2014 00:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1GuJO5SjT5l for ; Fri, 28 Feb 2014 00:31:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9284E1A005E for ; Fri, 28 Feb 2014 00:31:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBP37562; Fri, 28 Feb 2014 08:31:04 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 08:30:48 +0000 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 08:31:03 +0000 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.163) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 16:30:57 +0800 From: Zhuangshunwan To: "'Ali Sajassi (sajassi)'" , "'Jakob Heitz'" , References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F89932@eusaamb109.ericsson.se> In-Reply-To: Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt Date: Fri, 28 Feb 2014 16:30:56 +0800 Message-ID: <000901cf345f$67043460$350c9d20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPKRlYwzOqISXTKkKuRYQ1yRavy5q0SjEA//+EQoCAFp2ZIA== Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/UuKN-zffUR5JgA-rciSOke9cDKM X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 08:31:16 -0000 Dear Authors, I have a minor question, see inline. 8.4.1.1.1 Auto-Derivation from the Ethernet Tag ID The following is the procedure for deriving the RT attribute automatically from the Ethernet Tag ID associated with the advertisement: + The Global Administrator field of the RT MUST be set to the Autonomous System (AS) number that the PE belongs to. Vincent: Here Global Administrator field contains a 2 octets long = number, but the Autonomous System (AS) number could be 4 octets, how to handle = such case? + The Local Administrator field of the RT contains a 4 octets long number that encodes the Ethernet Tag-ID. If the Ethernet Tag-ID is a two octet VLAN ID then it MUST be encoded in the lower two octets of the Local Administrator=20 field and the higher two octets MUST be set to zero. Regards, Vincent -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: L2vpn [mailto:l2vpn-bounces@ietf.org] =B4=FA=B1=ED = Ali Sajassi (sajassi) =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C214=C8=D5 9:07 =CA=D5=BC=FE=C8=CB: Jakob Heitz; l2vpn@ietf.org =D6=F7=CC=E2: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt Hi Jakob, The reason the diff looks large is because some of the sections have = been reshuffled. Here are the main changes to this rev: 1. Modified section 5 to have a generalized format for ESI w/ additional ESI types 2. Clarified the advertisement of Ethernet A-D per ES route when the number of associated RTs is more than the limit to be advertised with a single route. In such case, instead of a single Ethernet A-D per ES = route, a set of such routes is advertised =20 3. Added a 2nd MPLS label to the MAC route. This label is optional 4. Added text to security section 5. Added text to IANA section Cheers, Ali On 2/13/14 4:30 PM, "Jakob Heitz" wrote: >The diff is large, but much seems to be language rewrites and >clarification. >Could the authors please submit a list of substantive changes. > >Thanks, >Jakob. > >-----Original Message----- >From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Thursday, February 13, 2014 4:11 PM >To: i-d-announce@ietf.org >Cc: l2vpn@ietf.org >Subject: I-D Action: draft-ietf-l2vpn-evpn-05.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 : BGP MPLS Based Ethernet VPN > Authors : Ali Sajassi > Rahul Aggarwal > Wim Henderickx > Aldrin Isaac > James Uttaro > Filename : draft-ietf-l2vpn-evpn-05.txt > Pages : 49 > Date : 2014-02-13 > >Abstract: > This document describes procedures for BGP MPLS based Ethernet VPNs > (EVPN). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-evpn-05 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > From pradeep@nuagenetworks.net Thu Feb 27 19:04:11 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869621A035D for ; Thu, 27 Feb 2014 19:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE7yXoWin9Dy for ; Thu, 27 Feb 2014 19:04:08 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id ED3611A0697 for ; Thu, 27 Feb 2014 19:04:07 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id gq1so3340276obb.18 for ; Thu, 27 Feb 2014 19:04:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6SZR0a/4l75UU1Sug9mtN2iqHIfrfw+6G4HwwLLELnI=; b=fzVDoL6qhEZULl09n2xzU+DiMs7A4PXPyGmIw0HwfOH+c+DbwwfxEpYL1Ed/CKg+uD qrXQUhzreGylnA2cCC3fkKhUy8M7YQlGQFy9bUEgcBja3qmK7c8NeKGg2QlYVgPDUqei jSTQGVuAwpstMEUTz+SS0Jkm9ZzbWmJDMs159PIwUQEoqpBBKd4zaEKJZK2PMdXAo8Nq 3rBzQe79/mnAJCJ6/aGurB53QWBLoJ8lpu8blVxPFmEKWp2jNa+Fz4nuwTRLsUk398Fj QhgV3riudqe6Zowl5wL1kgoS3sEyx3tG1gjN9+tenrUv+q70BF19CAZVNxUQaBO4x46z MKKA== X-Gm-Message-State: ALoCoQl14LYqAldWmLBCmSV9Ny/CThUa001Zsojz8wzQ1rh/vahaAZgINnXRv52b6ObERdti7Q83 MIME-Version: 1.0 X-Received: by 10.182.135.165 with SMTP id pt5mr4575obb.66.1393556646175; Thu, 27 Feb 2014 19:04:06 -0800 (PST) Received: by 10.76.82.230 with HTTP; Thu, 27 Feb 2014 19:04:06 -0800 (PST) In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> References: <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> Date: Thu, 27 Feb 2014 19:04:06 -0800 Message-ID: Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt From: Pradeep Jain To: Shahram Davari Content-Type: multipart/alternative; boundary=089e0112cb9eded39504f36eb02d Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Q6krJWLNVlOz1pFwEww63LS-Qis X-Mailman-Approved-At: Fri, 28 Feb 2014 00:58:51 -0800 Cc: "l2vpn@ietf.org" , Vinay Bannai , Ravi Shekhar X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:33:58 -0000 --089e0112cb9eded39504f36eb02d Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, Using BFD mandates that the probes need to be sent continuously. We don't want to impose this restriction and leave it to the user to decide if they want an on-demand probe or a continuous probe, which is what has been defined in the draft.. Regarding the second point about including VNI/VSID in TLV, for the hardware/forwarding plane which is not capable of giving the overlay context of the packet (based on VNI/VSID) to the control plane, we need to rely on the VNI/VSID in the TLV to derive the overlay context in the control plane... Regards Pradeep On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari wrote: > Anil, > > > > I don't agree. If you use for example BFD for inner IP, and if BFD says > connectivity is OK, this implies that the Overlay connectivity is also OK, > since BFD is inside the overlay. > > Also I am not sure why you are adding the VNI, VSID, etc in the message as > TLV, since these value are already in the packet header. > > > > Thx > Shahram > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Anil Lohiya > *Sent:* Thursday, February 27, 2014 10:19 AM > *To:* Thomas Nadeau; Henderickx, Wim (Wim) > > *Cc:* l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar > *Subject:* Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > > > Existing ping/traceroute mechanisms don't work in the virtualized > environment e.g. ping may report that IP reachability between the ingress > and egress tunnel endpoints is fine but the end systems (i.e. VM, physical > server etc.) connectivity for a tenant could still be broken. This is > because ping only verifies basic connectivity between two endpoints in the > underlay but NOT in the context of overlay segments. Hence, we need > debugging tools that work in the overlay environment. Think why there was a > need to have lsp ping ... requirement with IP overlays is not much different. > > > > Question is not whether applications are resilient or not... One can not > ignore the fact that operators have to think about having the right tools > when that "inevitable" call comes from their customer about deteriorating > application performance or traffic blackhole and there are no tools today > specific to overlay network debugging. > > > > - Anil > > > > *From: *Thomas Nadeau > *Date: *Thursday, February 27, 2014 8:05 AM > *To: *"Henderickx, Wim (Wim)" > *Cc: *"l2vpn@ietf.org" , Pradeep Jain < > pradeep@nuagenetworks.net>, Vinay Bannai , Ravi > Shekhar > *Subject: *Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > > > The question is, and perhaps the draft could explain this, is why existing > tools a) are insufficient and b) cannot be modified. > > Operationally speaking, b is preferred if you ask me as learning a new > tool/model for diagnosis and trouble-shooting is expensive and painful. > > For example, if we took the tact of reinventing say IP ping for every > underlying transport, then we'd have 50 tools by now. > > > > --Tom > > > > > > > > On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) < > wim.henderickx@alcatel-lucent.com> wrote: > > > > Because we also need to trace L2 endpoints besides IP endpoint. > > > > *From: *Shahram Davari > *Date: *Thursday 27 February 2014 16:58 > *To: *Kanwar Singh > *Cc: *"l2vpn@ietf.org" , Pradeep Jain < > pradeep@nuagenetworks.net>, Vinay Bannai , Ravi > Shekhar > *Subject: *Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt > > > > Hi > > > > Why don't you use existing IP based OAM messages such as BFD, OWAMP, > TWAMP, etc. > > Regards, > > Shahram > > > > > On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" > wrote: > > Dear All, > > > > We have submitted the below draft that proposes Generic OAM and Datapath > Failure Detection Mechanism(s) for Overlay Networks. > > > > We would like to solicit inputs from the members of L2VPN WG. > > > > Please review the same and update us with your inputs/feedback. > > > > Warm Regards > > - Kanwar > > > > > > A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh and posted to the > > IETF repository. > > Name: draft-jain-nvo3-overlay-oam > Revision: 01 > Title: Generic Overlay OAM and Datapath Failure Detection > Document date: 2014-02-12 > Group: Individual Submission > Pages: 44 > URL: http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt > Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/ > Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01 > > Abstract: > This proposal describes a mechanism that can be used to detect Data > Path Failures of various overlay technologies as VXLAN, NVGRE, > MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data > Plane for given Overlay Segment. This document defines the following > for each of the above Overlay Technologies: > > o Encapsulation of OAM Packet, such that it has same Outer and > Overlay Header as any End-System's data going over the same > Overlay Segment. > > o The mechanism to trace the Underlay that is exercised by any > Overlay Segment. > > o Procedure to verify presence of any given Tenant VM or End-System > within a given Overlay Segment at Overlay End-Point. > > Even though the present proposal addresses Overlay OAM for VXLAN, > NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are > generic enough to accommodate OAM for any other Overlay Technology. > > > --089e0112cb9eded39504f36eb02d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,

Using BFD mandates that the= probes need to be sent continuously. We don't want to impose this rest= riction and leave it to the user to decide if they want an on-demand probe = or a continuous probe, which is what has been defined in the draft..

Regarding the second point about including VNI/VS= ID in TLV, for the hardware/forwarding plane which is not capable of giving= the overlay context of the packet (based on VNI/VSID) to the control plane= , we need to rely on the VNI/VSID in the TLV to derive the overlay context = in the control plane...

Regards
Pradeep


On Thu, Feb 27, 2014 at 11:19 AM, Shah= ram Davari <davari@broadcom.com> wrote:

Anil,

 

I don’t agree. If y= ou use for example BFD for inner IP, and if BFD says connectivity is OK, th= is implies that the Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why yo= u are adding the VNI, VSID, etc in the message as TLV, since these value ar= e already in the packet header.

 

Thx
Shahram

 

From: L2vpn [m= ailto:l2vpn-bou= nces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)

<= br> Cc: l2vpn@ietf.o= rg; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draf= t-jain-nvo3-overlay-oam-01.txt

 

 

Existing ping/traceroute mechanisms don= 't work in the virtualized environment e.g. ping may report that IP rea= chability between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) conn= ectivity for a tenant could still be broken. This is because ping only veri= fies basic connectivity between two endpoints in the underlay but NOT in th= e context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why th= ere was a need to have lsp ping … requirement with IP overlays is no= t much different.

 

Question is not whether applications ar= e resilient or not… One can not ignore the fact that operators have = to think about having the right tools when that "inevitable" call  comes from their customer about deteriorating application perfo= rmance or traffic blackhole and there are no tools today specific to overla= y network debugging.

 

- Anil

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.= com>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Banna= i <vbannai@paypa= l.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

 

The question is, and perhaps the draft = could explain this, is why existing tools a) are insufficient and b) cannot= be modified.

Operationally speaking, b is preferred = if you ask me as learning a new tool/model for diagnosis and trouble-shooti= ng is expensive and painful.

For example, if we took the tact of rei= nventing say IP ping for every underlying transport, then we'd have 50 = tools by now.

 

--Tom

 

 

 

On Feb 27, 2014:11:02 AM, at 11:02 AM, = Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> wrote:



Because we also need to trace L2 endpoi= nts besides IP endpoint.

 

From: Shahram Davari <davari@broadcom.com>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <kanwar@nuagenetworks.net>
Cc: "l2vpn@= ietf.org" <= l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Banna= i <vbannai@paypa= l.com>, Ravi Shekhar <rshekhar@juniper.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.tx= t

 

Hi

 

Why don't you use existing IP based= OAM messages such as BFD, OWAMP, TWAMP, etc.

Regards,

Shahram

 


On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <kanwar@nuagenetworks.net&g= t; wrote:

Dear All,

 

We have submitted the below draft that = proposes Generic OAM and Datapath Failure Detection Mechanism(s) for Overla= y Networks.

 

We would like to solicit inputs from th= e members of L2VPN WG.

 

Please review the same and update us with= your inputs/feedback.

 

Warm Regards<=
/span>
- Kanwar
 =

 =

A new version of I-D, draft-jain-nvo3-overlay=
-oam-01.txt has been successfully submitted by Kanwar Singh and posted=
 to the
IETF repository.

Name:     &=
nbsp;     draft-jain-nvo3-overlay-oam
Revision:     =
  01
Title:          Generic Overlay OAM a=
nd Datapath Failure Detection

Document date:  2014-02-12
Group:          =
;Individual Submission
Pages:          44
UR=
L:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.=
txt

Status:         http=
s://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/=


Htmlized:      http://tools.ietf=
.org/html/draft-jain-nvo3-overlay-oam-01

Diff:              http://www.ietf.org/rfcdiff?url2=3Ddraft-jain-nvo3-overla=
y-oam-01


Abstract:
   This proposal describes a mechanism that can =
be used to detect Data
   Path Failures of various overlay tec=
hnologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verify=
ing/sanity of their Control and Data

   Plane for given Overlay Segment.  This document defines t=
he following
   for each of the above Overlay Technologies:
   o  Encapsulation of OAM Packet, such that it has sam=
e Outer and
      Overlay Header as any End-System's =
data going over the same

      Overlay Segment.

   o  The mecha=
nism to trace the Underlay that is exercised by any
     =
 Overlay Segment.

   o  Procedure to verify presence =
of any given Tenant VM or End-System
      within a given=
 Overlay Segment at Overlay End-Point.


   Even though the present proposal addresses Overlay OAM for=
 VXLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures de=
scribed are
   generic enough to accommodate OAM for any other=
 Overlay Technology.

 


--089e0112cb9eded39504f36eb02d--