From nobody Tue Jun 2 04:44:49 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5531B2D42; Tue, 2 Jun 2015 04:44:45 -0700 (PDT) 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 edud1d3oPUeO; Tue, 2 Jun 2015 04:44:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1D1B2D43; Tue, 2 Jun 2015 04:44:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-zheng-bfd-yang-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150602114437.12180.31753.idtracker@ietfa.amsl.com> Date: Tue, 02 Jun 2015 04:44:37 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 11:44:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Yang Data Model for Bidirectional Forwarding Detection (BFD) Authors : Lianshu Zheng Reshad Rahman Santosh Pallagatti Mahesh Jethanandani Filename : draft-zheng-bfd-yang-02.txt Pages : 31 Date : 2015-06-01 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zheng-bfd-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-zheng-bfd-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-zheng-bfd-yang-02 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 Wed Jun 10 23:18:25 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD51A8939 for ; Wed, 10 Jun 2015 23:18:23 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 BiJWVlDvb4vL for ; Wed, 10 Jun 2015 23:18:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93E81A87EB for ; Wed, 10 Jun 2015 23:18:20 -0700 (PDT) Received: from SN1PR0501MB1759.namprd05.prod.outlook.com (10.163.130.26) by SN1PR0501MB1679.namprd05.prod.outlook.com (10.163.130.15) with Microsoft SMTP Server (TLS) id 15.1.190.14; Thu, 11 Jun 2015 06:18:05 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1759.namprd05.prod.outlook.com (10.163.130.26) with Microsoft SMTP Server (TLS) id 15.1.190.14; Thu, 11 Jun 2015 06:18:04 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0190.013; Thu, 11 Jun 2015 06:18:04 +0000 From: Santosh P K To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Topic: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Index: AQHQo1pO6Bj6BVuujEy0X71t+IQKvZ2m1RwQ Date: Thu, 11 Jun 2015 06:18:04 +0000 Message-ID: References: <20150610084901.19165.15890.idtracker@ietfa.amsl.com> In-Reply-To: <20150610084901.19165.15890.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.17] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1759; 3:zX+2ldVMPFNp5BoOXW33KXfS8yr4T1AnNUVlz06Swp2K9PATEJ16AWihiQD4x5IeD1RygYVSZCwlIvKJ1QxKSlhSw27xiCGHTbKxfxvfub1MTsIcFOrggQ/AgFCE4psDqb1+FJ1VXMe23Hq6fRbZPg==; 10:1rNoPQ1c1a4U7utnI967Y5dCoENsFB5zcRPHtiX8o0T6T6EDK/y/Dr4XltWspfcihzWn7VOEMNP6vaH6iGzN3JX8LzinDs5RSazEKiGunlg=; 6:JkUywbnl5Z/4XCxqylNFHVTIel+aFaSkT5aRr7NlCnTBzOBU3Coc/fwywyCkVBei x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1679; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:SN1PR0501MB1759; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(377424004)(53754006)(51704005)(19300405004)(2900100001)(2950100001)(15975445007)(102836002)(77096005)(16236675004)(2420400003)(107886002)(5001960100002)(110136002)(5001920100001)(122556002)(19617315012)(92566002)(54356999)(76176999)(19580405001)(19580395003)(106116001)(50986999)(77156002)(450100001)(62966003)(99286002)(86362001)(87936001)(2656002)(5002640100001)(74316001)(33656002)(19625215002)(2501003)(230783001)(2351001)(66066001)(46102003)(7110500001)(76576001)(189998001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1759; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB17600E9966780C1B11803F91B3BC0SN1PR0501MB1760_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 06:18:04.5607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1759 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1679; 2:qXPmjw/R1h46tx6WQ7veI7qoMMsl9ahrwRJKKgzAQh80LT+IuaMrddtdR8ZV02R2; 2:CnrFC9YFyOHTLxtD2ZAyWJfVTTVNR3SvQzrIcWW3bwN0TvOOw890QEniJEGOzRMoK7FA/yVomQP2TLWZd+eQWjWoRmuEJ/rm8KXiIVx3UHnXyab0s/Fjh9xg/I+rGFQPyEWdGez3Fr+XIHu9bkdWsg==; 9:z6jPwcbtmaLEOur6B+OPwrI2cvfA05KMMrkjTABD58kGlo8/PXS/DhbJNVfq/Tg3H+AQXeDSNysuF1aaQHY4dZnFWZ+o4vDG8lFhkSomj9S1BMyK9yW5zk29+9i287z/3SsPG+jzPpKCLnAjcGSl4w== X-OriginatorOrg: juniper.net Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:18:23 -0000 --_000_SN1PR0501MB17600E9966780C1B11803F91B3BC0SN1PR0501MB1760_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsLA0KDQogICBBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0IGhhcyBiZWVuIHN1Ym1pdHRl ZC4gQmVsb3cgYXJlIHRoZSBjaGFuZ2VzIG1hZGUuDQoNCg0KDQoxLiAgICAgICBBZGRlZCB1c2Ug Y2FzZXMgZm9yIEJGRCBzdGFiaWxpdHkuDQoNCjIuICAgICAgIEFkZHJlc3NlZCByZXZpZXcgY29t bWVudHMgZ2l2ZW4gaW4gQkZEIHdvcmtpbmcgZ3JvdXAuDQoNCjMuICAgICAgIEFkZGVkIGRlbGF5 IG1lYXN1cmVtZW50IGRldGFpbHMuDQoNCg0KDQpQbGVhc2UgZG8gcmV2aWV3IGFuZCBnZXQgYmFj ayB0byB1cyB3aXRoIHJldmlldyBjb21tZW50cy4NCg0KDQoNClRoYW5rcw0KDQpTYW50b3NoIFAg Sw0KDQoNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQoN Cj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDEwLCAyMDE1IDI6MTkgUE0NCg0KPiBUbzogTWFjaCBD aGVuOyBBbmt1ciBTYXhlbmE7IE1haGVzaCBKZXRoYW5hbmRhbmk7IFNhbnRvc2ggUCBLOyBTYW50 b3NoIFANCg0KPiBLOyBBbmt1ciBTYXhlbmE7IEFzaGVzaCBNaXNocmE7IFBlbmcgRmFuOyBNYWNo IENoZW47IE1haGVzaA0KDQo+IEpldGhhbmFuZGFuaTsgUGVuZyBGYW47IEFzaGVzaCBNaXNocmEN Cg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFzaGVzaC1i ZmQtc3RhYmlsaXR5LTAzLnR4dA0KDQo+DQoNCj4NCg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseQ0K DQo+IHN1Ym1pdHRlZCBieSBTYW50b3NoIFBhbGxhZ2F0dGkgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQo+DQoNCj4gTmFtZTogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHkNCg0KPiBSZXZpc2lvbjogICAgICAgICAgMDMN Cg0KPiBUaXRsZTogICAgICAgICAgICAgICAgICBCRkQgU3RhYmlsaXR5DQoNCj4gRG9jdW1lbnQg ZGF0ZTogICAgICAgICAgIDIwMTUtMDYtMTANCg0KPiBHcm91cDogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KPiBQYWdlczogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgNw0KDQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktPGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hc2hlc2gtYmZkLXN0YWJpbGl0eS0w My50eHQ+DQoNCj4gMDMudHh0PGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1hc2hlc2gtYmZkLXN0YWJpbGl0eS0wMy50eHQ+DQoNCj4gU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFzaGVzaC1iZmQtc3RhYmlsaXR5 Lw0KDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YXNoZXNoLWJmZC1zdGFiaWxpdHktMDMNCg0KPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFzaGVzaC1iZmQtc3RhYmlsaXR5LTAzDQoNCj4N Cg0KPiBBYnN0cmFjdDoNCg0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBleHRlbnNpb25z IHRvIHRoZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcNCg0KPiAgICBEZXRlY3Rpb24gKEJGRCkg cHJvdG9jb2wgdG8gbWVhc3VyZSBCRkQgc3RhYmlsaXR5LiAgU3BlY2lmaWNhbGx5LCBpdA0KDQo+ ICAgIGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgZGV0ZWN0aW9uIG9mIEJGRCBmcmFtZSBsb3Nz Lg0KDQo+DQoNCj4NCg0KPg0KDQo+DQoNCj4NCg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQoNCj4g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KPg0KDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_SN1PR0501MB17600E9966780C1B11803F91B3BC0SN1PR0501MB1760_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEyOS43NXB0IDEuMGluIDEyOS43cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTMyNjczODM5Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTkwNTM1MzQ0NCA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTIwNzgw ODUwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTY0 MDUzOTYgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IZWxsbyBBbGws PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQSBu ZXcgdmVyc2lvbiBvZiBkcmFmdCBoYXMgYmVlbiBzdWJtaXR0ZWQuIEJlbG93IGFyZSB0aGUgY2hh bmdlcyBtYWRlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRl ZCB1c2UgY2FzZXMgZm9yIEJGRCBzdGFiaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkcmVzc2VkIHJldmlldyBjb21tZW50cyBnaXZlbiBp biBCRkQgd29ya2luZyBncm91cC4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMSBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBkZWxheSBtZWFzdXJlbWVudCBkZXRhaWxzLiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIGRvIHJldmlldyBhbmQgZ2V0IGJhY2sgdG8g dXMgd2l0aCByZXZpZXcgY29tbWVudHMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TYW50b3NoIFAg SyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBTZW50OiBXZWRuZXNkYXksIEp1bmUgMTAsIDIwMTUgMjoxOSBQTTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVG86IE1hY2ggQ2hlbjsgQW5rdXIgU2F4 ZW5hOyBNYWhlc2ggSmV0aGFuYW5kYW5pOyBTYW50b3NoIFAgSzsgU2FudG9zaCBQPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBLOyBBbmt1ciBTYXhlbmE7IEFzaGVzaCBNaXNocmE7 IFBlbmcgRmFuOyBNYWNoIENoZW47IE1haGVzaDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgSmV0aGFuYW5kYW5pOyBQZW5nIEZhbjsgQXNoZXNoIE1pc2hyYTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1hc2hlc2gtYmZkLXN0YWJpbGl0eS0wMy50eHQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYXNo ZXNoLWJmZC1zdGFiaWxpdHktMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgc3VibWl0dGVkIGJ5IFNhbnRvc2ggUGFsbGFnYXR0aSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE5hbWU6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRyYWZ0LWFzaGVzaC1iZmQtc3RhYmlsaXR5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBSZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMDM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRpdGxl OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCRkQgU3RhYmls aXR5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBEb2N1bWVudCBkYXRlOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAy MDE1LTA2LTEwPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBHcm91cDombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5k aXZpZHVhbCBTdWJtaXNzaW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBQYWdl czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgNzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVVJMOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt YXNoZXNoLWJmZC1zdGFiaWxpdHktMDMudHh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktMDMudHh0Ij48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Jmd0OyAwMy50eHQ8L3NwYW4+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3RhdHVzOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hc2hlc2gtYmZkLXN0YWJpbGl0eS8iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFzaGVzaC1iZmQtc3RhYmlsaXR5Lzwvc3Bhbj48 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIdG1saXplZDombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWFzaGVzaC1iZmQtc3RhYmlsaXR5LTAzIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktMDM8L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgRGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFzaGVzaC1iZmQtc3RhYmlsaXR5LTAzIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktMDM8L3Nw YW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBBYnN0cmFjdDo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lv bnMgdG8gdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7RGV0ZWN0aW9uIChCRkQpIHByb3RvY29sIHRv IG1lYXN1cmUgQkZEIHN0YWJpbGl0eS4mbmJzcDsgU3BlY2lmaWNhbGx5LCBpdDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3JpYmVzIGEgbWVj aGFuaXNtIGZvciBkZXRlY3Rpb24gb2YgQkZEIGZyYW1lIGxvc3MuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIElFVEYgU2VjcmV0 YXJpYXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0501MB17600E9966780C1B11803F91B3BC0SN1PR0501MB1760_-- From nobody Thu Jun 11 05:12:45 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D6C1ACDE8; Thu, 11 Jun 2015 05:12:43 -0700 (PDT) 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 Ra3arVzSCFmh; Thu, 11 Jun 2015 05:12:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E91631ACDE9; Thu, 11 Jun 2015 05:12:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-zheng-bfd-yang-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611121241.313.50893.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 05:12:41 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:12:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Yang Data Model for Bidirectional Forwarding Detection (BFD) Authors : Lianshu Zheng Reshad Rahman Santosh Pallagatti Mahesh Jethanandani Greg Mirsky Filename : draft-zheng-bfd-yang-03.txt Pages : 31 Date : 2015-06-11 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zheng-bfd-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-zheng-bfd-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-zheng-bfd-yang-03 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 Jun 12 01:33:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96EA1A88FE for ; Fri, 12 Jun 2015 01:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 28Ir5mpAMK4u for ; Fri, 12 Jun 2015 01:33:16 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6F81A88FA for ; Fri, 12 Jun 2015 01:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16534; q=dns/txt; s=iport; t=1434097995; x=1435307595; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dstSjB0xdIZ+plqRrI2rRmJSz7LyleuQk8J/B5Q/VJ4=; b=Oei7wBXa7fKrVyVC5kOgOrUjs9WVT4+DfSNPDgI0P9YF9HmQsRWPF/zH s8q3YfVLmW4Fwg0X4RHYnlWjG3WG4JtVn7EnMZP2Eja8BucVODsMkbNes TEDLPhpGpAwbto85sVGrNlY6vgGXy7gGbozs9LyR9EeVi5PP0JvdNQTmD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BPBABVmHpV/5tdJa1cgkVLVF8GvHlmCYFhhXoCgUU4FAEBAQEBAQGBCoQiAQEBAwEtSgcHBAIBCBEDAQEBKAcfExQJCAIEARKIJwgN1WgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OEdQ0LBoQnBYt5h1sHhECGcYEwQINAklIkg3lvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,601,1427760000"; d="scan'208,217";a="158788317" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jun 2015 08:33:14 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5C8XEEO003051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 08:33:14 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.172]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 12 Jun 2015 03:33:14 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Santosh P K , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Topic: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Index: AQHQo1pO6Bj6BVuujEy0X71t+IQKvZ2m1RwQgAJpDoA= Date: Fri, 12 Jun 2015 08:33:14 +0000 Message-ID: References: <20150610084901.19165.15890.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.32.183] Content-Type: multipart/alternative; boundary="_000_D1A0960A35B2mmudigonciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 08:33:18 -0000 --_000_D1A0960A35B2mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I need a quick clarification on the need for the sender time stamp here. If= the delay is measured by comparing the time stamps of two consecutive pack= ets, it can be done on the local end. Why send it to the other end? Receive= time stamp can still happen to measure the Rx path delays. I understand th= at we need to always maintain the previous packets TS to achieve this. Aski= ng this because we can measure these delays independently at both ends unle= ss you are also looking at accommodating transit delays over the link. Thanks Regards Mallik From: Santosh P K > Date: Thursday, 11 June 2015 11:48 To: "rtg-bfd@ietf.org" > Subject: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt Hello All, A new version of draft has been submitted. Below are the changes made. 1. Added use cases for BFD stability. 2. Addressed review comments given in BFD working group. 3. Added delay measurement details. Please do review and get back to us with review comments. Thanks Santosh P K > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Wednesday, June 10, 2015 2:19 PM > To: Mach Chen; Ankur Saxena; Mahesh Jethanandani; Santosh P K; Santosh P > K; Ankur Saxena; Ashesh Mishra; Peng Fan; Mach Chen; Mahesh > Jethanandani; Peng Fan; Ashesh Mishra > Subject: New Version Notification for draft-ashesh-bfd-stability-03.txt > > > A new version of I-D, draft-ashesh-bfd-stability-03.txt has been successf= ully > submitted by Santosh Pallagatti and posted to the IETF repository. > > Name: draft-ashesh-bfd-stability > Revision: 03 > Title: BFD Stability > Document date: 2015-06-10 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-ashesh-bfd-sta= bility- > 03.txt > Status: https://datatracker.ietf.org/doc/draft-ashesh-bfd-stabili= ty/ > Htmlized: https://tools.ietf.org/html/draft-ashesh-bfd-stability-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ashesh-bfd-stab= ility-03 > > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol to measure BFD stability. Specifically, it > describes a mechanism for detection of BFD frame loss. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat --_000_D1A0960A35B2mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6F51327D42D7964DAD7F112A391B30AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

I need a quick clarification on the need for the sender time stamp her= e. If the delay is measured by comparing the time stamps of two consecutive= packets, it can be done on the local end. Why send it to the other end? Re= ceive time stamp can still happen to measure the Rx path delays. I understand that we need to always maintai= n the previous packets TS to achieve this. Asking this because we can measu= re these delays independently at both ends unless you are also looking at a= ccommodating transit delays over the link.

Thanks

Regards
Mallik 

From: Santosh P K <santoshpk@juniper.net>
Date: Thursday, 11 June 2015 11:48<= br> To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: FW: New Version Notificati= on for draft-ashesh-bfd-stability-03.txt

Hello All,

   A new version of draft has been subm= itted. Below are the changes made.

 

1.   =     Added use cases for BFD stability.

2.   =     Addressed review comments given in BFD working = group.

3.   =     Added delay measurement details.

 

Please do review and get back to us with review c= omments.

 

Thanks

Santosh P K

 

 

> -----Original Message-----

> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

> Sent: Wednesday, June 10, 2015 2:19 PM

> To: Mach Chen; Ankur Saxena; Mahesh Jethanan= dani; Santosh P K; Santosh P

> K; Ankur Saxena; Ashesh Mishra; Peng Fan; Ma= ch Chen; Mahesh

> Jethanandani; Peng Fan; Ashesh Mishra

> Subject: New Version Notification for draft-= ashesh-bfd-stability-03.txt

>

>

> A new version of I-D, draft-ashesh-bfd-stabi= lity-03.txt has been successfully

> submitted by Santosh Pallagatti and posted t= o the IETF repository.

>

> Name:      &nb= sp;            =             draft-as= hesh-bfd-stability

> Revision:      = ;    03

> Title:      &n= bsp;           BFD Stabil= ity

> Document date:     =       2015-06-10

> Group:      &n= bsp;            = ;           Individual Su= bmission

> Pages:      &n= bsp;            = ;            7

> URL:      &nbs= p;     https://www.ietf.org/= internet-drafts/draft-ashesh-bfd-stability-

> 03.txt

> Status:      &= nbsp;  https://datatracker.i= etf.org/doc/draft-ashesh-bfd-stability/

> Htmlized:      = ; https://tools.ietf.or= g/html/draft-ashesh-bfd-stability-03

> Diff:      &nb= sp;    https://www.ietf.org/= rfcdiff?url2=3Ddraft-ashesh-bfd-stability-03

>

> Abstract:

>    This document describes ex= tensions to the Bidirectional Forwarding

>    Detection (BFD) protocol t= o measure BFD stability.  Specifically, it

>    describes a mechanism for = detection of BFD frame loss.

>

>

>

>

>

> Please note that it may take a couple of min= utes from the time of submission

> until the htmlized version and diff are avai= lable at tools.ietf.org.

>

> The IETF Secretariat

 

 --_000_D1A0960A35B2mmudigonciscocom_-- From nobody Mon Jun 15 11:07:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1BD1A0370 for ; Mon, 15 Jun 2015 11:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zjIDgRyIyMAo for ; Mon, 15 Jun 2015 11:07:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 00DCD1A036F for ; Mon, 15 Jun 2015 11:07:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9A56B1E39A; Mon, 15 Jun 2015 14:08:41 -0400 (EDT) Date: Mon, 15 Jun 2015 14:08:41 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nomcom-chair-2015@ietf.org: Third and FINAL call for volunteers, Nomcom 2015-2016] Message-ID: <20150615180841.GB2288@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 18:07:36 -0000 I did a stint on nomcom not that long ago. If you've ever been curious about some of the deep details about how IETF operates, you'll get your fill. You'll also help choose our leadership for open terms. -- Jeff ----- Forwarded message from NomCom Chair 2015 ----- Date: Mon, 15 Jun 2015 02:59:28 -0700 From: NomCom Chair 2015 To: IETF Announcement List Cc: ietf@ietf.org Subject: Third and FINAL call for volunteers, Nomcom 2015-2016 ***Reminder: Deadline for volunteering for Nomcom is in ONE WEEK.*** The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. As of today, we have 151 confirmed volunteers. 72 of those who ticked the box on the registration form for Hawaii, Dallas and Prague have still not responded. If you believe you have volunteered, and your name is NOT below, please contact me as soon as possible. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 hours) June 22, 2015, as follows: To: nomcom-chair-2015@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You will find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ Thank you! Harald Alvestrand hta+nomcom@alvestrand.no nomcom-chair-2015@ietf.org ===== qualified volunteers so far, in alphabetical order by first name Adam Montville Adrian Farrel ANDREW Dolganow Andrew Newton Andy Bierman ANM Zaheduzzaman Sarker Anoop Ghanwani Anthony Nadalin Ari Keranen Benno Overeinder Bernard Aboba Bhumip KHASNABISH Bing Liu Borje Ohlman Carl Moberg Carlos Martinez Cengiz Alaettinoglu Charles Eckel Charles Perkins Chris Bowers Christer Holmberg Christian Huitema Christian O'Flaherty Cong Liu Corinna Schmitt Cullen Jennings Damien Saucez Daniele Ceccarelli Dapeng Liu David Conrad David Lamparter David Mandelberg David Sinicrope Dean Bogdanovic Derek Atkins Dhruv Dhody Dimitri Papadimitriou Donald Eastlake 3rd Edward Lemon Eliot Lear Emil Ivov Eric Gray Eric Vyncke Fangwei Hu Fernando Gont Fred Baker George Michaelson George Swallow Georgios Karagiannis Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Huaimo Chen Ignas Bagdonas Jason Weil Jean-Marc Valin Jean-Michel Combes Jesus Maria Martin Garcia Joel Halpern John Bradley John Brzozowski John Drake John Mattsson John Scudder Jon Hudson Jon Mitchell jouni korhonen Karen O'Donoghue Keith Moore Kenneth Gray Kent Watsen Kepeng Li Keyur Patel Laurent Ciavaglia Lee Howard Liang Xia Linda Dunbar Lingli Deng Lixia Zhang Lucy Lynch Luigi Iannone Mach CHEN Magnus Westerlund Mahalingam Mani Mark Townsley Matthew Bocci Matthew Lepinski Mehmet Ersue Michael Jones Michael StJohns Min Ye nalini elkins Nancy Cam-Winget Nathan Egge Niel Harper Ning Kong Ning Zong Ole Jacobsen Ole Trøan Pascal Thubert Patrick McManus Paul Wouters Peng Fan Peter Koch Peter Yee Pål-Erik Martinsen QIN WU Rich Salz Richard Barnes Robby Simpson Ron Bonica Ross Callon Salvatore Loreto Sam K. Aldrin Sanjay Mishra Scott Mansfield Sheng Jiang SHUCHENG LIU Simon Perreault Sri Gundavelli Stephan Wenger Stephen Kent Steve Donovan Steve Olshansky Steven Wright Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Nadeau Thomas Walsh Tim Wicinski Timothy Terriberry Tina (Ting) Tsou (Zou) TIRUMALESWAR REDDY KONDA Tobias Gondrom Toerless Eckert Tomohiro Fujisaki Tony Hansen Uma Chunduri Vic Liu Vijay Gurbani Warren Kumari Wassim Haddad Wijnands IJsbrand Xufeng Liu Yi Zhao Yihong Huang Yizhou Li Yuanlong Jiang Zhaohui Zhang ----- End forwarded message ----- From nobody Mon Jun 15 13:19:38 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7530F1A0181 for ; Mon, 15 Jun 2015 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xUY9q8dbwbgt for ; Mon, 15 Jun 2015 13:19:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6701A039C for ; Mon, 15 Jun 2015 13:19:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F05561E39E; Mon, 15 Jun 2015 16:20:42 -0400 (EDT) Date: Mon, 15 Jun 2015 16:20:42 -0400 From: Jeffrey Haas To: Santosh P K Subject: Re: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt Message-ID: <20150615202042.GJ2288@pfrc.org> References: <20150610084901.19165.15890.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 20:19:37 -0000 Santosh, Thanks for the update. A few comments upon my most recent reading of the draft: - Please consider starting the auth-key-id at 1 rather than 0 and leave 0 reserved. - You don't document the sender timestamp format. :-) Going back to prior discussion from the Working Group, you probably require more clarification as to how you intend to use this mechanism. Since you are building upon authentication, choices include some of these and perhaps others that haven't been raised: - This is fine for the case where no authentication was intended to be used for the session. In this case, state transitions within this BFD session are suitable for standard use. - This is intended only for an adjunct session. In this case, perhaps you want to further document behavior in not taking the session to the Down state in order to permit continuous measurement at rate. - You intend to toggle into and out of this mode? (I suspect not, it complicates key rollover situations which are already a bit weak in our RFCs.) -- Jeff On Thu, Jun 11, 2015 at 06:18:04AM +0000, Santosh P K wrote: > Hello All, > > A new version of draft has been submitted. Below are the changes made. > > > > 1. Added use cases for BFD stability. > > 2. Addressed review comments given in BFD working group. > > 3. Added delay measurement details. > > > > Please do review and get back to us with review comments. > > > > Thanks > > Santosh P K From nobody Mon Jun 15 14:59:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063C1B2B79 for ; Mon, 15 Jun 2015 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 e6mlQ7WAAqz0 for ; Mon, 15 Jun 2015 14:59:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A19011B2B76 for ; Mon, 15 Jun 2015 14:59:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6A22E1E39F; Mon, 15 Jun 2015 18:00:42 -0400 (EDT) Date: Mon, 15 Jun 2015 18:00:42 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 93, shall we meet? Message-ID: <20150615220042.GQ2288@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 21:59:36 -0000 Working Group, IETF 93 is proving to be very popular, and the IETF has more requests for timeslots than can be possibly served from the pool of available ones. I had registered the WG for its usual 1 hour session a few weeks ago. Given the competition for scheduling, I must ask you all this question: Shall we meet? The mailing list has been quiet, but work has been going on. For example: - The BFD Yang design team has been very busy on their latest version. (Provide them feedback!) - The S-BFD have completed WGLC and are waiting for the last IPR attestations before going to shepherd write-up. - 5884 clarifications have passed IPR attestations, but didn't get enough support to move the document forward. We'll be trying again soon after some last minute comments are addressed. In non-chartered work: - BFD stability has had a new edition published. - BFD authentication optimizations is available for discussion. - BFD for VXLan was published for discussion. Minimally, the chairs will be requesting status updates for active work. This status need not be presented. As always, Working Group session time should be reserved for *active discussion*. Thus if you believe we have work that requires such active discussion, let us know. -- Jeff From nobody Tue Jun 16 06:41:20 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534EC1B3522 for ; Tue, 16 Jun 2015 06:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EI41up0Mp186 for ; Tue, 16 Jun 2015 06:41:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBCA1B354C for ; Tue, 16 Jun 2015 06:41:14 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1758.namprd05.prod.outlook.com (10.163.130.25) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 13:40:52 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0190.013; Tue, 16 Jun 2015 13:40:52 +0000 From: Santosh P K To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: IETF 93, shall we meet? Thread-Topic: IETF 93, shall we meet? Thread-Index: AQHQp7aVnYm1ZtaP2kyZWB++rGCqTp2vJFEA Date: Tue, 16 Jun 2015 13:40:52 +0000 Message-ID: References: <20150615220042.GQ2288@pfrc.org> In-Reply-To: <20150615220042.GQ2288@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pfrc.org; dkim=none (message not signed) header.d=none; x-originating-ip: [122.172.55.7] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1758; 3:YcQZGP8/zORlLeoFHo2QOWq97RVd5vR9ULpu/u06enJDAR+1cVVjzt+68fOPX0uhLG/3pq/9MKbs9NScdSxX6u5CPfCqupV6sz4O8HqvlI/HibxiAvEHO2Y6NAJOw6pxxP9xKcVMPdAjJw6Gpe4LcQ==; 10:F5L3mtRvo66wUZ/bPyHCVBt2bflZ81axIK2GwbR1poVzeX3+ywOyq+u6IzX7hH8m2xiBPC1Ofn4R3eAK+UsEHO6PQq7za0yUx4VeNaxx38E=; 6:VOYDGhY/CEp+UgIRzsOSADl6bANhlQA+Yc1zNxPwNOs+ZLGVIfC5ie/sFvaAPFGq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1758; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:SN1PR0501MB1758; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1758; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(74316001)(2501003)(66066001)(19580405001)(5001770100001)(107886002)(76576001)(5001960100002)(189998001)(87936001)(2656002)(46102003)(5002640100001)(50986999)(54356999)(76176999)(40100003)(102836002)(122556002)(86362001)(99286002)(2900100001)(62966003)(5003600100002)(77156002)(92566002)(77096005)(33656002)(106116001)(19580395003)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1758; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 13:40:52.3574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1758 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:41:19 -0000 Jeff, I have BFD over VXLAN to present in coming IETF. I have plans presenting= this both in Nov3 and BFD working group.=20 Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, June 16, 2015 3:31 AM > To: rtg-bfd@ietf.org > Subject: IETF 93, shall we meet? >=20 > Working Group, >=20 > IETF 93 is proving to be very popular, and the IETF has more requests for > timeslots than can be possibly served from the pool of available ones. I= had > registered the WG for its usual 1 hour session a few weeks ago. >=20 > Given the competition for scheduling, I must ask you all this question: > Shall we meet? >=20 > The mailing list has been quiet, but work has been going on. For example= : > - The BFD Yang design team has been very busy on their latest version. > (Provide them feedback!) > - The S-BFD have completed WGLC and are waiting for the last IPR > attestations before going to shepherd write-up. > - 5884 clarifications have passed IPR attestations, but didn't get enough > support to move the document forward. We'll be trying again soon after > some last minute comments are addressed. >=20 > In non-chartered work: > - BFD stability has had a new edition published. > - BFD authentication optimizations is available for discussion. > - BFD for VXLan was published for discussion. >=20 > Minimally, the chairs will be requesting status updates for active work. > This status need not be presented. >=20 > As always, Working Group session time should be reserved for *active > discussion*. Thus if you believe we have work that requires such active > discussion, let us know. >=20 > -- Jeff From nobody Tue Jun 16 06:43:52 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898701B3564 for ; Tue, 16 Jun 2015 06:43:51 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 EsViewwvTNvg for ; Tue, 16 Jun 2015 06:43:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A79E1B354C for ; Tue, 16 Jun 2015 06:43:48 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 13:43:29 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0190.013; Tue, 16 Jun 2015 13:43:29 +0000 From: Santosh P K To: "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Topic: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Index: AQHQo1pO6Bj6BVuujEy0X71t+IQKvZ2m1RwQgAJpDoCABe93UA== Date: Tue, 16 Jun 2015 13:43:29 +0000 Message-ID: References: <20150610084901.19165.15890.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [122.172.55.7] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1760; 3:JlnSSpGJ3+62JrNRTPGEhJTCRqDTpmQB5Npi2R7g22Van4oOaNfqkiVsbAxoj7lZUcfWy/Wr/9dgGVUCrdA+7jZuDLVhZi+GSlMdK0/D8KW3WQ/47FYXe41HG2nafRT4tL1aZDnMYYcp0kZ9YkSQbQ==; 10:SHKVKoYH9/2x+Sc9jNVX3ofcyy+tqNWQiYCVDRhgOtfCV4oUPfr/RjKb/h79q/DPreIHfyu7VUe3eKJJoo6Qutdf96FZxfptUSB8hm09VOM=; 6:PXetDKNBxlkPmz+iNvswcunVjLbd1hFgC/g3fYdMcClsiT7OLpXKNLNFeYm7jjAJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1760; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:SN1PR0501MB1760; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(377424004)(377454003)(51704005)(13464003)(106116001)(46102003)(99286002)(50986999)(76176999)(2900100001)(54356999)(15975445007)(102836002)(2420400003)(77096005)(86362001)(2656002)(87936001)(76576001)(19580395003)(19580405001)(74316001)(19617315012)(19625215002)(33656002)(66066001)(19300405004)(5002640100001)(5001770100001)(7110500001)(122556002)(5001920100001)(230783001)(16236675004)(2950100001)(107886002)(189998001)(40100003)(62966003)(77156002)(5003600100002)(5001960100002)(2501003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1760; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB176017AA8C3E2BED73D9BC85B3A70SN1PR0501MB1760_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 13:43:29.3486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1760 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:43:51 -0000 --_000_SN1PR0501MB176017AA8C3E2BED73D9BC85B3A70SN1PR0501MB1760_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mallik, We have made delay measurement an optional feature secondly we can measu= re RX side delay locally it is Tx side which is a problem and hence we have= time stamping. We did mention that we can send timestamping info to centra= l unit where the calculation can be done in that case BFD packet need not c= arry any timestamp. Did I answer your question? Thanks Santosh P K From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, June 12, 2015 2:03 PM To: Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-ashesh-bfd-stability-03.txt Hi, I need a quick clarification on the need for the sender time stamp here. If= the delay is measured by comparing the time stamps of two consecutive pack= ets, it can be done on the local end. Why send it to the other end? Receive= time stamp can still happen to measure the Rx path delays. I understand th= at we need to always maintain the previous packets TS to achieve this. Aski= ng this because we can measure these delays independently at both ends unle= ss you are also looking at accommodating transit delays over the link. Thanks Regards Mallik From: Santosh P K > Date: Thursday, 11 June 2015 11:48 To: "rtg-bfd@ietf.org" > Subject: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt Hello All, A new version of draft has been submitted. Below are the changes made. 1. Added use cases for BFD stability. 2. Addressed review comments given in BFD working group. 3. Added delay measurement details. Please do review and get back to us with review comments. Thanks Santosh P K > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Wednesday, June 10, 2015 2:19 PM > To: Mach Chen; Ankur Saxena; Mahesh Jethanandani; Santosh P K; Santosh P > K; Ankur Saxena; Ashesh Mishra; Peng Fan; Mach Chen; Mahesh > Jethanandani; Peng Fan; Ashesh Mishra > Subject: New Version Notification for draft-ashesh-bfd-stability-03.txt > > > A new version of I-D, draft-ashesh-bfd-stability-03.txt has been successf= ully > submitted by Santosh Pallagatti and posted to the IETF repository. > > Name: draft-ashesh-bfd-stability > Revision: 03 > Title: BFD Stability > Document date: 2015-06-10 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-ashesh-bfd-sta= bility- > 03.txt > Status: https://datatracker.ietf.org/doc/draft-ashesh-bfd-stabili= ty/ > Htmlized: https://tools.ietf.org/html/draft-ashesh-bfd-stability-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ashesh-bfd-stab= ility-03 > > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol to measure BFD stability. Specifically, it > describes a mechanism for detection of BFD frame loss. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat --_000_SN1PR0501MB176017AA8C3E2BED73D9BC85B3A70SN1PR0501MB1760_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mallik,

   We have m= ade delay measurement an optional feature secondly we can measure RX side d= elay locally it is Tx side which is a problem and hence we have time stampi= ng. We did mention that we can send timestamping info to central unit where the calculation can be done in that case BFD pa= cket need not carry any timestamp. Did I answer your question?

 

Thanks

Santosh P K

 

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmu= digon@cisco.com]
Sent: Friday, June 12, 2015 2:03 PM
To: Santosh P K; rtg-bfd@ietf.org
Subject: Re: New Version Notification for draft-ashesh-bfd-stability= -03.txt

 

Hi,

&n= bsp;

I need = a quick clarification on the need for the sender time stamp here. If the de= lay is measured by comparing the time stamps of two consecutive packets, it= can be done on the local end. Why send it to the other end? Receive time stamp can still happen to measure the Rx= path delays. I understand that we need to always maintain the previous pac= kets TS to achieve this. Asking this because we can measure these delays in= dependently at both ends unless you are also looking at accommodating transit delays over the link.

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards=

Mallik&= nbsp;

&n= bsp;

From: Santosh P K <santoshpk@juniper.net>
Date: Thursday, 11 June 2015 11:48
To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: FW: New Version Notification for draft-ashesh-bfd-stability= -03.txt

&n= bsp;

Hello All,=

   A new ve= rsion of draft has been submitted. Below are the changes made.

 

1.  =      Added use cases = for BFD stability.

2.  =      Addressed review= comments given in BFD working group.

3.  =      Added delay meas= urement details.

 

Please do review and = get back to us with review comments.

 

Thanks

Santosh P K

 

 

> -----Original Me= ssage-----

> From: internet-drafts@ietf.org [m= ailto:internet-drafts@ietf.org]

> Sent: Wednesday,= June 10, 2015 2:19 PM

> To: Mach Chen; A= nkur Saxena; Mahesh Jethanandani; Santosh P K; Santosh P<= /p>

> K; Ankur Saxena;= Ashesh Mishra; Peng Fan; Mach Chen; Mahesh

> Jethanandani; Pe= ng Fan; Ashesh Mishra

> Subject: New Ver= sion Notification for draft-ashesh-bfd-stability-03.txt

>

>

> A new version of= I-D, draft-ashesh-bfd-stability-03.txt has been successfully

> submitted by San= tosh Pallagatti and posted to the IETF repository.

>

> Name:  = ;            &n= bsp;            = ;    draft-ashesh-bfd-stability

> Revision: &= nbsp;        03

> Title: &nbs= p;            &= nbsp;   BFD Stability

> Document date:&n= bsp;          2015-06-10<= /o:p>

> Group: &nbs= p;            &= nbsp;           &nbs= p;   Individual Submission

> Pages: &nbs= p;            &= nbsp;           &nbs= p;    7

> URL:  =           https://www.ietf.org/= internet-drafts/draft-ashesh-bfd-stability-

> 03.txt

> Status: &nb= sp;       https://datatracker.i= etf.org/doc/draft-ashesh-bfd-stability/

> Htmlized: &= nbsp;     https://tools.ietf.or= g/html/draft-ashesh-bfd-stability-03

> Diff:  = ;         https://www.ietf.org/= rfcdiff?url2=3Ddraft-ashesh-bfd-stability-03

>

> Abstract:

>   &nbs= p;This document describes extensions to the Bidirectional Forwarding

>   &nbs= p;Detection (BFD) protocol to measure BFD stability.  Specifically, it=

>   &nbs= p;describes a mechanism for detection of BFD frame loss.<= /p>

>

>

>

>

>

> Please note that= it may take a couple of minutes from the time of submission

> until the htmliz= ed version and diff are available at tools.ietf.org.

>

> The IETF Secreta= riat

 

--_000_SN1PR0501MB176017AA8C3E2BED73D9BC85B3A70SN1PR0501MB1760_-- From nobody Tue Jun 16 06:49:39 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008A21B357F for ; Tue, 16 Jun 2015 06:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OarXiFTWCRuh for ; Tue, 16 Jun 2015 06:49:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6EB1B357D for ; Tue, 16 Jun 2015 06:49:36 -0700 (PDT) Received: from SN1PR0501MB1759.namprd05.prod.outlook.com (10.163.130.26) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 13:49:19 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1759.namprd05.prod.outlook.com (10.163.130.26) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 13:49:18 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0190.013; Tue, 16 Jun 2015 13:49:18 +0000 From: Santosh P K To: Jeffrey Haas Subject: RE: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Topic: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt Thread-Index: AQHQo1pO6Bj6BVuujEy0X71t+IQKvZ2m1RwQgAc1sACAASPpcA== Date: Tue, 16 Jun 2015 13:49:18 +0000 Message-ID: References: <20150610084901.19165.15890.idtracker@ietfa.amsl.com> <20150615202042.GJ2288@pfrc.org> In-Reply-To: <20150615202042.GJ2288@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pfrc.org; dkim=none (message not signed) header.d=none; x-originating-ip: [122.172.55.7] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1759; 3:ViQkZteUTaDFqmRMW6EU7sF8MGak3k0CNTbTLuPefRvi8wUy7rsj9Nn3EgZ+ynxHTIAXfU3KzWeJLLbazt3IT3BFQBVrAIXC/61rMpLS3Be5I0iWVQww48nPxpM59kFO30ohgq/cPfqPljYZsHui4w==; 10:vc4U4p46ju4/tJFhpTiE3jNBxVXC/yGcAtuBiaVhxyinFX5LRUeDFHjmYrpEEdc9eeqqYeUTA7w1aLTUguaJwvHU0Ni2+SlmrJZ8kSNEK0Q=; 6:Az2QlWmGuLuOK0N3kiyqlDdsvSXnyhKAkqn33qNV9t7W5zxZ/n3bQOjV8vJmxQJ1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:SN1PR0501MB1759; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(52604005)(53754006)(51704005)(92566002)(50986999)(106116001)(86362001)(76176999)(5002640100001)(77096005)(102836002)(77156002)(62966003)(99286002)(54356999)(33656002)(74316001)(87936001)(2656002)(230783001)(40100003)(5001920100001)(189998001)(5003600100002)(5001960100002)(66066001)(2950100001)(2900100001)(122556002)(46102003)(110136002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1759; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 13:49:18.3012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1759 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1710; 2:K26QQD2ZD8C3oxAtPiWHfqCX5cqYnr5mNvbk6nK69sXl2om+N6EbxmNEnCA7bLei; 2:uFotyX2oTHCeOL6YyEbvQGRPyblBwVT68jqT/i9++JWRQvmd5xB2HLjdLh3n/octHS3vWBJ4AnNWTnqrM3j/cIhrk+1/8YIgKS8mg612Jiix7HgppcQvAchG4mFnxFZRyU7bjsv47vyDJquoGBEz2w==; 9:rxDoopoRQhZzOip27sQd7m2wLqVs89e9++KT9s10AdztXXo2O5E+DYge9w6yEgpswU1fejETtQmT/OSSKZJbnVwZA2Mm3GUOCCKZI6keoJXvAwRTdqe68plezhCtQ/7V4czR8uyo22Wh9Lyw9x6YTw== X-OriginatorOrg: juniper.net Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:49:38 -0000 Jeff, > - Please consider starting the auth-key-id at 1 rather than 0 and leave 0 > reserved. > - You don't document the sender timestamp format. :-) Sure will make the changes.=20 >=20 > Going back to prior discussion from the Working Group, you probably requi= re > more clarification as to how you intend to use this mechanism. Since you= are > building upon authentication, choices include some of these and perhaps > others that haven't been raised: You mean how will auth work along with this change?=20 >=20 > - This is fine for the case where no authentication was intended to be us= ed > for the session. In this case, state transitions within this BFD sessio= n > are suitable for standard use. > - This is intended only for an adjunct session. In this case, perhaps yo= u > want to further document behavior in not taking the session to the Down > state in order to permit continuous measurement at rate. > - You intend to toggle into and out of this mode? (I suspect not, it > complicates key rollover situations which are already a bit weak in our > RFCs.) Thanks for raising this point. I think you are right we should put in more = details on this. The whole purpose of using AUTH TLV for this mechanism is = because we want this to work along with normal authentication. I will add m= ore text on how auth and this mechanism can work together.=20 Thanks Santosh P K =20 >=20 > -- Jeff >=20 > On Thu, Jun 11, 2015 at 06:18:04AM +0000, Santosh P K wrote: > > Hello All, > > > > A new version of draft has been submitted. Below are the changes mad= e. > > > > > > > > 1. Added use cases for BFD stability. > > > > 2. Addressed review comments given in BFD working group. > > > > 3. Added delay measurement details. > > > > > > > > Please do review and get back to us with review comments. > > > > > > > > Thanks > > > > Santosh P K From nobody Tue Jun 16 08:06:17 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6DD1B3AA2; Tue, 16 Jun 2015 08:06:14 -0700 (PDT) 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 1JfuvySBYc69; Tue, 16 Jun 2015 08:06:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 764BB1B3AA3; Tue, 16 Jun 2015 08:06:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-rfc5884-clarifications-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150616150611.24131.27893.idtracker@ietfa.amsl.com> Date: Tue, 16 Jun 2015 08:06:11 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 15:06:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Clarifications to RFC 5884 Authors : Vengada Prasad Govindan Kalyani Rajaraman Gregory Mirsky Nobo Akiya Sam Aldrin Filename : draft-ietf-bfd-rfc5884-clarifications-02.txt Pages : 6 Date : 2015-06-16 Abstract: This document clarifies the procedures for establishing, maintaining and removing multiple, concurrent BFD sessions for a given described in RFC5884. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc5884-clarifications/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-rfc5884-clarifications-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-rfc5884-clarifications-02 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 Wed Jun 17 00:15:58 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796D91A1AE3 for ; Wed, 17 Jun 2015 00:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SYJGM4zmjtOn for ; Wed, 17 Jun 2015 00:15:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADCC1A1AFC for ; Wed, 17 Jun 2015 00:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5465; q=dns/txt; s=iport; t=1434525354; x=1435734954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=20TYCYogsJ2gNnHnpHBSKj3uq0iYBf/DqzJgGcdo+ng=; b=fqbCYHFtMVCReAQDAg8mkihEmYIeHzQwKGaJd6331Q6mLfi+OwtaBjYP utSLbeAqPOaniBkjbVTDKxYrMzblngofi0tznBMqnpw5kmruUiZYNa4MQ rjcGy6sugj7uMjhNRVgesCGKbfWz3j9vVtuCvSDo34vDJcySa/psrph00 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DWBACZHYFV/49dJa1bgxCBMwa9M2YJh10CgU44FAEBAQEBAQGBCoQiAQEBBB0dNAsMBAIBCBEEAQEfCQcyFAkIAgQBDQWIL812AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tEhCMRASYrBwaEJwEEk18BhTOGEYEzhAmPAYNbJoN5b4EMOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,631,1427760000"; d="scan'208";a="160205303" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP; 17 Jun 2015 07:15:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5H7Frbl024339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 07:15:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.147]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 02:15:53 -0500 From: "Srihari Raghavan (srihari)" To: Santosh P K , "Vengada Prasad Govindan (venggovi)" , "draft-ietf-bfd-rfc5884-clarifications@tools.ietf.org" Subject: Re: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Topic: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Index: AQHQhqSv8MkBNz0V20iOED4dcvJNKp175wyAgAj+VSCACAgTAIAkUCeA Date: Wed, 17 Jun 2015 07:15:52 +0000 Message-ID: References: <20150504195805.GB25036@pfrc.org> <315041E4211CB84E86EF7C25A2AB583D544F9242@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.210] Content-Type: text/plain; charset="us-ascii" Content-ID: <78BCF01C7CDAA240A8FFEE060C03E692@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 07:15:57 -0000 As one of the implementors of RFC 5884 and involved in the internal discussions of the clarifications draft, I support to take the draft further along. Thanks Srihari On 25/05/15 3:43 pm, "Santosh P K" wrote: >Prasad, > Sorry for delayed response. Below text looks good to me. > >> The egress MUST use the discriminators exchanged when the session was >> brought to indicate a session DOWN back to the ingress. The egress >>SHOULD >> reset this to zero after transmitting detectMult number of packets. >> Please suggest your thoughts on making the above text better. > > > >Thanks >Santosh P K=20 > >> -----Original Message----- >> From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] >> Sent: Wednesday, May 20, 2015 6:12 PM >> To: Santosh P K; draft-ietf-bfd-rfc5884-clarifications@tools.ietf.org >> Cc: Jeffrey Haas; Nobo Akiya; rtg-bfd@ietf.org >> Subject: RE: Working Group Last Call for >>draft-ietf-bfd-rfc5884-clarifications >>=20 >> Hello Santosh, >> Thanks for your careful review. You bring up a valid point, that needs >> clarification. Even without multiple BFD sessions on the if >>the >> egress were to inform about a BFD session going to DOWN (potentially >>using >> the diag code 0x4 - Neighbor Signalled Down), the YourDisc field needs >>to be >> non-zero, so the ingress can demux the packet to the correct session. >>With >> multiple sessions per FEC, LSP, this becomes absolutely needed, as you >> remark below. Could we consider adding the following statement: >> The egress MUST use the discriminators exchanged when the session was >> brought to indicate a session DOWN back to the ingress. The egress >>SHOULD >> reset this to zero after transmitting detectMult number of packets. >> Please suggest your thoughts on making the above text better. >> Thanks >> Prasad >> Copying the list for their inputs as well. >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Thursday, May 14, 2015 7:44 PM >> To: draft-ietf-bfd-rfc5884-clarifications@tools.ietf.org >> Cc: Jeffrey Haas; Nobo Akiya >> Subject: RE: Working Group Last Call for >>draft-ietf-bfd-rfc5884-clarifications >>=20 >> Hello Authors, >> Sorry for being so late in the game. I had few points which are >>not clear >> from draft. >>=20 >>=20 >> As per RFC 5880 section 6.8.1 it says that when BFD session goes down >>due to >> control timer expiry then remote discr MUST be set to 0. >>=20 >> >> " bfd.RemoteDiscr >>=20 >> The remote discriminator for this BFD session. This is the >> discriminator chosen by the remote system, and is totally opaque >> to the local system. This MUST be initialized to zero. If a >> period of a Detection Time passes without the receipt of a valid, >> authenticated BFD packet from the remote system, this variable >> MUST be set to zero." >>=20 >> >>=20 >> As per RFC 5884 it says that all the demux MUST happen with remote >> Discriminator and also it talks about Discr not changing only when >>session is >> UP. >>=20 >> >> Section 7: >>=20 >> Note that once the BFD session for the MPLS LSP is UP, either end of >> the BFD session MUST NOT change the source IP address and the local >> discriminator values of the BFD Control packets it generates, unless >> it first brings down the session. >> >>=20 >>=20 >> As per clarification draft " draft-ietf-bfd-rfc5884-clarifications" >>section 2.4 >> iterates the same statement. >>=20 >> >> Section 2.4: >>=20 >> The discriminators of a BFD session established over an MPLS LSP >> cannot be changed when it is in UP state. >> >>=20 >>=20 >> Problem: >>=20 >> Now for example if we have multiple LSP's with the same FEC then at >>egress >> it might be sending packet to same designation address. In this case if >>one of >> the BFD session goes down on egress then it would send BFD packet with >> down state with 0 discr. Seeing this ingress would try to demux with >>IFL and >> source address on the packet, this will lead to multiple sessions. I >>think this >> needs to be clarified as well. >>=20 >> I am not sure if this point is already covered or not. Do you think it >>is worth >> clarifying this point? I think it plays very important role in bringing >>down the >> BFD session in MPLS environment. Any thoughts? >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >> > -----Original Message----- >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >> > Haas >> > Sent: Tuesday, May 05, 2015 1:28 AM >> > To: rtg-bfd@ietf.org >> > Cc: mpls@ietf.org >> > Subject: Working Group Last Call for >> > draft-ietf-bfd-rfc5884-clarifications >> > >> > The BFD mailing list has been quiet since shortly after IETF 92. We >> > have a number of documents that seem stable and ready to advance. >> > >> > This email begins a two week Working Group Last Call for >> > draft-ietf-bfd- rfc5884-clarifications-01, Clarifications to RFC 5884. >> > >> > This last call will end on May 15. >> > >> > Simultaneously, the authors of this draft should state to the mailing >> > list whether there is any IPR associated with this draft or not. >> > >> > This WGLC is also being cc'd to mpls@ietf to permit additional >> > commentary > From nobody Wed Jun 17 01:07:06 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B223D1A6F11; Wed, 17 Jun 2015 01:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RjcdFca3HMcV; Wed, 17 Jun 2015 01:07:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482EC1A1C06; Wed, 17 Jun 2015 01:07:00 -0700 (PDT) Received: from SN1PR0501MB1757.namprd05.prod.outlook.com (10.163.130.24) by SN1PR0501MB1696.namprd05.prod.outlook.com (10.163.130.154) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 17 Jun 2015 08:06:45 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1757.namprd05.prod.outlook.com (10.163.130.24) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 17 Jun 2015 08:06:44 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0190.013; Wed, 17 Jun 2015 08:06:44 +0000 From: Santosh P K To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-rfc5884-clarifications-02.txt Thread-Topic: I-D Action: draft-ietf-bfd-rfc5884-clarifications-02.txt Thread-Index: AQHQqEYhncXOAEFIu0efiRcGIvgg852wV/WA Date: Wed, 17 Jun 2015 08:06:44 +0000 Message-ID: References: <20150616150611.24131.27893.idtracker@ietfa.amsl.com> In-Reply-To: <20150616150611.24131.27893.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1757; 3:XLB55WG9I/HR+jwKr4a8dT7Wfr5MfZ30zRcYTXYldLHMB3ljt7FwYSui/xwWIjLUkIdFrzJn+z8+LhyyCfIzmNIONSAsjRfqy4QPVHVEp89uQBE9a/QYaNAoeJbTInSj8uoI7bY/C+QnKi53tCijbg==; 10:hKcDRvONKh0RYfly0EPehxwIIFaTX+4kdFrMM9TdPL8lzHz2toPkXKK3zShuneRnk0+o5FAIGnEVlZyjtrhg1yptykxZxfxBJrJpRASeVAI=; 6:SiMxenddJOT01EoGo/k85K9+fvrex83ZQ+emTt3ZTDPWEBkm+ZLnACB9CmOEPE0N x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1757; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1696; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:SN1PR0501MB1757; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1757; x-forefront-prvs: 0610D16BBE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(377424004)(86362001)(2656002)(87936001)(106116001)(74316001)(99286002)(5002640100001)(92566002)(5001960100002)(19580395003)(189998001)(40100003)(50986999)(76176999)(54356999)(122556002)(76576001)(230783001)(46102003)(450100001)(62966003)(77156002)(33656002)(77096005)(5003600100002)(66066001)(19580405001)(2900100001)(102836002)(15975445007)(2501003)(5001770100001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1757; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2015 08:06:44.6631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1757 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1696; 2:a2eMvcRBa3kg5uKMj1Zi+RktbFbYMYm8rLHgIYRmRcyybmsEv+y1gSVLKe8CRrTk; 2:O/fjmyn+fHzSO7U4HEEWPnJTGAxVJov33XoOSA9Bl0Lid3rqQXWIVo2OU8mU2f/crhC3ZU+5lf70u6kqHpFvhJO8qVyBG4ovaMQah+R3MpmguVroRGs+Td0k0alT5XtnJXp/hO6sI5vEp4RZY5n1OA==; 9:p+IZViip8FsBTWgd63CIPs5BLrBQLlBRKNVtE3AnI1im0WiVZibEoyTURJ4QW9q3j501/HWccDwiKNgNuPbRIKqE1WQfBcC91W8YQiFGnp1HqP1aQyE0zaJop7GbXzeMIIXv+9Tzyu4mG6+FJPL18w== X-OriginatorOrg: juniper.net Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 08:07:04 -0000 SSBoYXZlIHJlYWQgdGhlIGxhdGVzdCByZXZpc2lvbiBkb2N1bWVudCBhbmQgSSBzdXBwb3J0IHRo aXMgZHJhZnQgdG8gbW92ZSBmb3J3YXJkLiANCg0KVGhhbmtzDQpTYW50b3NoIFAgSyANCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJm ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtDQo+IGRyYWZ0c0BpZXRm Lm9yZw0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE2LCAyMDE1IDg6MzYgUE0NCj4gVG86IGktZC1h bm5vdW5jZUBpZXRmLm9yZw0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWJmZC1yZmM1ODg0LWNsYXJpZmljYXRpb25zLTAyLnR4dA0KPiAN Cj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gV29ya2luZw0KPiBH cm91cCBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogQ2xhcmlm aWNhdGlvbnMgdG8gUkZDIDU4ODQNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBWZW5nYWRh IFByYXNhZCBHb3ZpbmRhbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEthbHlhbmkgUmFq YXJhbWFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZ29yeSBNaXJza3kNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBOb2JvIEFraXlhDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgU2FtIEFsZHJpbg0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1iZmQtcmZj NTg4NC1jbGFyaWZpY2F0aW9ucy0wMi50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDYNCj4gCURh dGUgICAgICAgICAgICA6IDIwMTUtMDYtMTYNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRv Y3VtZW50IGNsYXJpZmllcyB0aGUgcHJvY2VkdXJlcyBmb3IgZXN0YWJsaXNoaW5nLCBtYWludGFp bmluZw0KPiAgICBhbmQgcmVtb3ZpbmcgbXVsdGlwbGUsIGNvbmN1cnJlbnQgQkZEIHNlc3Npb25z IGZvciBhIGdpdmVuIDxNUExTIExTUCwNCj4gICAgRkVDPiBkZXNjcmliZWQgaW4gUkZDNTg4NC4N Cj4gDQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQt cmZjNTg4NC1jbGFyaWZpY2F0aW9ucy8NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl cnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy0wMg0KPiANCj4gQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy0wMg0K PiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From nobody Wed Jun 17 06:11:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37381A913E for ; Wed, 17 Jun 2015 06:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 03n5YSsGfgBn for ; Wed, 17 Jun 2015 06:11:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BE01A913D for ; Wed, 17 Jun 2015 06:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5761; q=dns/txt; s=iport; t=1434546667; x=1435756267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VYuvtdRKnGvDvZtnK+o2XuEXvAbhpT7n/p2lrjPObIw=; b=J/EOuwu41TDL7Kvm11UbMlVUt/Ts9PgJLDfmOXLjjgxYvy7huhnym9Ug 3anr6Xnqz2WYaj+dx4E56wfYI66d4fCW8VRMq7/puPqlRPAQRzffkx6pu P4LG6y0WxHRUb9eX6Ral+JQeKTbFs2Us3oECHUxm7gweOL9iz/OiXFvpj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CBBQAacYFV/40NJK1cgxCBMwa9IGYJh18CgTo4FAEBAQEBAQF/C4QiAQEBBB0dNAsMBAIBCBEEAQEBHgkHHxMUCQgCBA4FiC/KFAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLRIQjEQEmKwcGhCUFkRGCVwEHhS2GEoE0hAqPB4NbJoN5b4EMOoECAQEB X-IronPort-AV: E=Sophos;i="5.13,632,1427760000"; d="scan'208";a="160090780" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 17 Jun 2015 13:11:06 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5HDB6Nc029474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 13:11:06 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.243]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 08:11:06 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "draft-ietf-bfd-rfc5884-clarifications@tools.ietf.org" Subject: Re: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Topic: Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Index: AQHQhqSvNu+6VdAp2EqlcyU9itUN15175wyAgAj+VSCACAgTAIAj8/cAgAC/cQA= Date: Wed, 17 Jun 2015 13:11:06 +0000 Message-ID: References: <20150504195805.GB25036@pfrc.org> <315041E4211CB84E86EF7C25A2AB583D544F9242@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.169] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 13:11:12 -0000 I support WGLC of this draft. Regards Mallik On 17/06/15 12:45, "Srihari Raghavan (srihari)" wrote: >As one of the implementors of RFC 5884 and involved in the internal >discussions of the clarifications draft, I support to take the draft >further along. > >Thanks >Srihari > >On 25/05/15 3:43 pm, "Santosh P K" wrote: > >>Prasad, >> Sorry for delayed response. Below text looks good to me. >> >>> The egress MUST use the discriminators exchanged when the session was >>> brought to indicate a session DOWN back to the ingress. The egress >>>SHOULD >>> reset this to zero after transmitting detectMult number of packets. >>> Please suggest your thoughts on making the above text better. >> >> >> >>Thanks >>Santosh P K=20 >> >>> -----Original Message----- >>> From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] >>> Sent: Wednesday, May 20, 2015 6:12 PM >>> To: Santosh P K; draft-ietf-bfd-rfc5884-clarifications@tools.ietf.org >>> Cc: Jeffrey Haas; Nobo Akiya; rtg-bfd@ietf.org >>> Subject: RE: Working Group Last Call for >>>draft-ietf-bfd-rfc5884-clarifications >>>=20 >>> Hello Santosh, >>> Thanks for your careful review. You bring up a valid point, that >>>needs >>> clarification. Even without multiple BFD sessions on the if >>>the >>> egress were to inform about a BFD session going to DOWN (potentially >>>using >>> the diag code 0x4 - Neighbor Signalled Down), the YourDisc field needs >>>to be >>> non-zero, so the ingress can demux the packet to the correct session. >>>With >>> multiple sessions per FEC, LSP, this becomes absolutely needed, as you >>> remark below. Could we consider adding the following statement: >>> The egress MUST use the discriminators exchanged when the session was >>> brought to indicate a session DOWN back to the ingress. The egress >>>SHOULD >>> reset this to zero after transmitting detectMult number of packets. >>> Please suggest your thoughts on making the above text better. >>> Thanks >>> Prasad >>> Copying the list for their inputs as well. >>>=20 >>> -----Original Message----- >>> From: Santosh P K [mailto:santoshpk@juniper.net] >>> Sent: Thursday, May 14, 2015 7:44 PM >>> To: draft-ietf-bfd-rfc5884-clarifications@tools.ietf.org >>> Cc: Jeffrey Haas; Nobo Akiya >>> Subject: RE: Working Group Last Call for >>>draft-ietf-bfd-rfc5884-clarifications >>>=20 >>> Hello Authors, >>> Sorry for being so late in the game. I had few points which are >>>not clear >>> from draft. >>>=20 >>>=20 >>> As per RFC 5880 section 6.8.1 it says that when BFD session goes down >>>due to >>> control timer expiry then remote discr MUST be set to 0. >>>=20 >>> >>> " bfd.RemoteDiscr >>>=20 >>> The remote discriminator for this BFD session. This is the >>> discriminator chosen by the remote system, and is totally opaque >>> to the local system. This MUST be initialized to zero. If a >>> period of a Detection Time passes without the receipt of a valid, >>> authenticated BFD packet from the remote system, this variable >>> MUST be set to zero." >>>=20 >>> >>>=20 >>> As per RFC 5884 it says that all the demux MUST happen with remote >>> Discriminator and also it talks about Discr not changing only when >>>session is >>> UP. >>>=20 >>> >>> Section 7: >>>=20 >>> Note that once the BFD session for the MPLS LSP is UP, either end of >>> the BFD session MUST NOT change the source IP address and the local >>> discriminator values of the BFD Control packets it generates, unless >>> it first brings down the session. >>> >>>=20 >>>=20 >>> As per clarification draft " draft-ietf-bfd-rfc5884-clarifications" >>>section 2.4 >>> iterates the same statement. >>>=20 >>> >>> Section 2.4: >>>=20 >>> The discriminators of a BFD session established over an MPLS LSP >>> cannot be changed when it is in UP state. >>> >>>=20 >>>=20 >>> Problem: >>>=20 >>> Now for example if we have multiple LSP's with the same FEC then at >>>egress >>> it might be sending packet to same designation address. In this case if >>>one of >>> the BFD session goes down on egress then it would send BFD packet with >>> down state with 0 discr. Seeing this ingress would try to demux with >>>IFL and >>> source address on the packet, this will lead to multiple sessions. I >>>think this >>> needs to be clarified as well. >>>=20 >>> I am not sure if this point is already covered or not. Do you think it >>>is worth >>> clarifying this point? I think it plays very important role in bringing >>>down the >>> BFD session in MPLS environment. Any thoughts? >>>=20 >>>=20 >>> Thanks >>> Santosh P K >>>=20 >>> > -----Original Message----- >>> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>> > Haas >>> > Sent: Tuesday, May 05, 2015 1:28 AM >>> > To: rtg-bfd@ietf.org >>> > Cc: mpls@ietf.org >>> > Subject: Working Group Last Call for >>> > draft-ietf-bfd-rfc5884-clarifications >>> > >>> > The BFD mailing list has been quiet since shortly after IETF 92. We >>> > have a number of documents that seem stable and ready to advance. >>> > >>> > This email begins a two week Working Group Last Call for >>> > draft-ietf-bfd- rfc5884-clarifications-01, Clarifications to RFC >>>5884. >>> > >>> > This last call will end on May 15. >>> > >>> > Simultaneously, the authors of this draft should state to the mailing >>> > list whether there is any IPR associated with this draft or not. >>> > >>> > This WGLC is also being cc'd to mpls@ietf to permit additional >>> > commentary >> > From nobody Wed Jun 17 11:15:39 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A782B1B2CB3 for ; Wed, 17 Jun 2015 11:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JRcbLL7eTfqp for ; Wed, 17 Jun 2015 11:15:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 029411B2CB1 for ; Wed, 17 Jun 2015 11:15:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7D1341E3A6; Wed, 17 Jun 2015 14:16:46 -0400 (EDT) Date: Wed, 17 Jun 2015 14:16:46 -0400 From: Jeffrey Haas To: Santosh P K Subject: Re: IETF 93, shall we meet? Message-ID: <20150617181646.GJ15534@pfrc.org> References: <20150615220042.GQ2288@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 18:15:37 -0000 Santosh, On Tue, Jun 16, 2015 at 01:40:52PM +0000, Santosh P K wrote: > Jeff, > I have BFD over VXLAN to present in coming IETF. I have plans presenting this both in Nov3 and BFD working group. Thus far, yours is the only real presentation request. Your proposal is pretty straight forward. That's a good thing. :-) What's unclear is why you think, beyond getting WG attention on the draft, that we're likely to need to drive discussion in-session? For the NVO3 audience, I agree this is perhaps very useful. FWIW, even if we don't meet, I'm pushing to have presentations added to the conference proceedings. -- Jeff From nobody Wed Jun 17 11:20:12 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796B1B2CD1 for ; Wed, 17 Jun 2015 11:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ts1_BEMPLrRW for ; Wed, 17 Jun 2015 11:20:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D3C1B2C96 for ; Wed, 17 Jun 2015 11:20:05 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1758.namprd05.prod.outlook.com (10.163.130.25) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 17 Jun 2015 18:19:48 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0190.013; Wed, 17 Jun 2015 18:19:48 +0000 From: Santosh P K To: Jeffrey Haas Subject: RE: IETF 93, shall we meet? Thread-Topic: IETF 93, shall we meet? Thread-Index: AQHQp7aVnYm1ZtaP2kyZWB++rGCqTp2vJFEAgAHfzACAAAALkA== Date: Wed, 17 Jun 2015 18:19:48 +0000 Message-ID: References: <20150615220042.GQ2288@pfrc.org> <20150617181646.GJ15534@pfrc.org> In-Reply-To: <20150617181646.GJ15534@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pfrc.org; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.16] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1758; 3:CKDM8JX0V4XTEvGSSg/JgL9sagivFk0YIR2mrS+BkvqYTul2+oYV5/EqQsJI0y348xrFcj8yzlD7jA+JR8/52QIh4QqiI3d+NZUZxN5JMNxGhZoOSMAKnZ+wMM4V0/zuPqaLu3+S6gmGCttOEdJr+Q==; 10:LnkU1+oM/82ZCJZVptFySMK6ju4RPX6Xjg+aLJL9iTdolx2dYZ5cyi542S2/0lZmKn8/9mvdVjO949hE5D/uE1zrr2ZEPHGuZqIy8zSRZBc=; 6:pNos0GDeqtj/75FzsjTwIDGiAn0wuxZecHSo1RU+fEN4htzhKBplYjS4eCj0zebE x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1758; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:SN1PR0501MB1758; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1758; x-forefront-prvs: 0610D16BBE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(86362001)(76176999)(33656002)(40100003)(110136002)(189998001)(5001960100002)(122556002)(77156002)(62966003)(46102003)(77096005)(102836002)(50986999)(54356999)(76576001)(99286002)(5002640100001)(106116001)(5003600100002)(2950100001)(2900100001)(92566002)(74316001)(87936001)(2656002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1758; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2015 18:19:48.2844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1758 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 18:20:08 -0000 Jeff, =20 > What's unclear is why you think, beyond getting WG attention on the draft= , > that we're likely to need to drive discussion in-session? I am ok if we are not meeting :). I think we are making good progress on th= is draft already in BFD WG.=20 >=20 > For the NVO3 audience, I agree this is perhaps very useful. >=20 Yes, we have not got much attention in NVO3 WG. Thanks Santosh P K=20 From nobody Thu Jun 18 09:06:09 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C01B32F3 for ; Thu, 18 Jun 2015 09:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kUFtc4rvY_Gr for ; Thu, 18 Jun 2015 09:06:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 91C241B32CB for ; Thu, 18 Jun 2015 09:06:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7642D1E3A6; Thu, 18 Jun 2015 12:07:14 -0400 (EDT) Date: Thu, 18 Jun 2015 12:07:14 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF-93 BFD canceled Message-ID: <20150618160714.GA6948@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 16:06:06 -0000 Working Group, We were a bit short of material that required discussion at the upcoming IETF session in Prague. Thus, I have canceled the meeting. I will be contacting Working Group members that have active work for status to be either added to the conference proceedings or posted to the WG wiki. -- Jeff From nobody Fri Jun 19 23:42:21 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A3B1A1B81; Fri, 19 Jun 2015 23:42:18 -0700 (PDT) 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 PvLFol1EF3r9; Fri, 19 Jun 2015 23:42:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF481A1B86; Fri, 19 Jun 2015 23:42:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-base-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150620064216.12195.57432.idtracker@ietfa.amsl.com> Date: Fri, 19 Jun 2015 23:42:16 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 06:42:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Santosh Pallagatti Filename : draft-ietf-bfd-seamless-base-05.txt Pages : 21 Date : 2015-06-19 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-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 Sat Jun 20 18:54:16 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785F11A8AF8; Sat, 20 Jun 2015 18:54:14 -0700 (PDT) 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 ZkuY9pbpCBw3; Sat, 20 Jun 2015 18:54:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA71A8AFA; Sat, 20 Jun 2015 18:54:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-ip-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150621015412.23049.15927.idtracker@ietfa.amsl.com> Date: Sat, 20 Jun 2015 18:54:12 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 01:54:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS Authors : Nobo Akiya Carlos Pignataro Dave Ward Filename : draft-ietf-bfd-seamless-ip-02.txt Pages : 7 Date : 2015-06-19 Abstract: This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-ip-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-ip-02 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 Sun Jun 21 14:58:06 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30291A898F; Sun, 21 Jun 2015 14:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.811 X-Spam-Level: X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 B2DopXBjIFYR; Sun, 21 Jun 2015 14:58:02 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4F51A8989; Sun, 21 Jun 2015 14:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=812; q=dns/txt; s=iport; t=1434923882; x=1436133482; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1NwOBhdQ3GS4YGgFjKjzLjZgSpgqVJtGWNF2+s/lwCY=; b=Sw8upUUEc4MaIYgWz24v2M0BTthLdzUn2SeZLF0FaKlAKEdd1qjRq8sP hfTD5MqJEPoyFjsjd0jTriNSLXjg9U6hPhSbJZI8klYstSa7idwy2caJU PdUMKJlwwvtMqy1JGUDX+03Ls9OYmhegX0t9xZvyvjoxdS34MMfMX8zQz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BABPModV/5RdJa1cgxBUXwa9F2YJgVwKhXgCgSA4FAEBAQEBAQGBCoQjAQEEAQEBGh00CxIBCA4oNwslAgQBDQWILw3HRgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0WEIxEBUQeEKwEEkSKCWwGLTZgxJoN5b4EMOoECAQEB X-IronPort-AV: E=Sophos;i="5.13,655,1427760000"; d="scan'208";a="161307989" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 21 Jun 2015 21:58:01 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5LLw1Wf030900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Jun 2015 21:58:01 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.103]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Sun, 21 Jun 2015 16:58:01 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Topic: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Index: AQHQrG1WP/dij1gdrE6MeqHOKnZL1w== Date: Sun, 21 Jun 2015 21:58:00 +0000 Message-ID: In-Reply-To: <20150504195805.GB25036@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.249.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <60B76843B37C4B43ACEB20CB526F4996@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 21:58:04 -0000 Hi, Support. (Sorry for the delay) -Nagendra On 5/4/15, 3:58 PM, "Jeffrey Haas" wrote: >The BFD mailing list has been quiet since shortly after IETF 92. We have >a >number of documents that seem stable and ready to advance. > >This email begins a two week Working Group Last Call for >draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. > >This last call will end on May 15. > >Simultaneously, the authors of this draft should state to the mailing list >whether there is any IPR associated with this draft or not. > >This WGLC is also being cc'd to mpls@ietf to permit additional commentary. > >-- Jeff and Nobo > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Jun 23 12:08:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376D51B2FC1; Tue, 23 Jun 2015 12:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 M716EGIZ6lMH; Tue, 23 Jun 2015 12:08:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBAF1B2F40; Tue, 23 Jun 2015 12:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2291; q=dns/txt; s=iport; t=1435086492; x=1436296092; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6iy1pFJxFjfxguZVTybcf6m2dLa70VookH9fBZvMJac=; b=X7pLuK39gX22qj/3BviugdXqt6dgZtJX3LT1FaDqko/gSk1x5gPMseus w2VHlENcM0mDoOtcZ1tWnp3/cklDA4fvQh7vOyUXmduv0gCL1i3A6htqb xwrHqWD7YCFhPD+BcSflcHpcOA9XzwejvGYPdv9NnWAr10eSRR+/fk2/Y Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AABAAgrolV/5xdJa1bgxBUXwaDGLlnZgmBXAqFeAKBUDgUAQEBAQEBAYEKhCIBAQEDAQEBARoGSwsFCwIBCA4KKgICJwslAgQOBQ6IGQgNtkiWSQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0qEIxEBUQeCaC+BFAWTfwGCI4FQh12YNSaDem+BDDqBAgEBAQ X-IronPort-AV: E=Sophos; i="5.13,667,1427760000"; d="asc'?scan'208"; a="5941824" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jun 2015 19:08:11 +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 t5NJ8B7N010875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 19:08:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.112]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 14:08:11 -0500 From: "Carlos Pignataro (cpignata)" To: Jeff Haas Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Topic: [mpls] Working Group Last Call for draft-ietf-bfd-rfc5884-clarifications Thread-Index: AQHQrefyViLYR7RfpEqcI3DlV4r1sw== Date: Tue, 23 Jun 2015 19:08:10 +0000 Message-ID: <5B780E4E-85F1-4A8D-938D-36AA8387752C@cisco.com> References: <20150504195805.GB25036@pfrc.org> In-Reply-To: <20150504195805.GB25036@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.53] Content-Type: multipart/signed; boundary="Apple-Mail=_04F57626-F4F3-4ACF-98B4-63170BFCBFC0"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 19:08:15 -0000 --Apple-Mail=_04F57626-F4F3-4ACF-98B4-63170BFCBFC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jeff, Late reply =E2=80=94 I support advancing this document as it provides = useful clarifications for RFC 5884. Thanks, =E2=80=94 Carlos. > On May 4, 2015, at 3:58 PM, Jeffrey Haas wrote: >=20 > The BFD mailing list has been quiet since shortly after IETF 92. We = have a > number of documents that seem stable and ready to advance. >=20 > This email begins a two week Working Group Last Call for > draft-ietf-bfd-rfc5884-clarifications-01, Clarifications to RFC 5884. >=20 > This last call will end on May 15. >=20 > Simultaneously, the authors of this draft should state to the mailing = list > whether there is any IPR associated with this draft or not. >=20 > This WGLC is also being cc'd to mpls@ietf to permit additional = commentary. >=20 > -- Jeff and Nobo >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_04F57626-F4F3-4ACF-98B4-63170BFCBFC0 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 - http://gpgtools.org iQIcBAEBCAAGBQJVia6aAAoJEIXgpQGOZny9hG4P/1wcsEojotFNFv/2FmId0thE cARAKgPHj9Ln3smhOmqzT/MPxEh6G9sLJcwBh1tUh7AwGeTOtPikIIO7RZxTZEwP rXWiOllkHEtVOwllDRtIRfqEloytyreXZmMDmOjCZ+/XNE+RpntrQ3AVFGKH/LM8 m56f7V2fDqQusMIviLpE8hCDDqkV5pu/+cmW2SoCJJa+RAOlNHYjaKWj/qLHpQMr mDMTDHqPAbU+PIG7vZz8NrVfynbNM4dte+tH44NDKiqGWU2wd1Y0Mb4OU0HGuvja EtSW/IwlnFGXq92HVTF2bL2oIgpAVRDrYmloXcvc1rOGS4T1c92zys19GRazNBmD SfH/lVAi/bPQr2kSg9dUbRXWMJvurQ0uC9oQtDiKZGEuJ5H2kS0n7JpweSwJqPzF tY7SCYLBuneLJ+78+fXHk6X5p5NPTZGN+zzGRtZBUeYdjN/hfoIhUjn9ZNPvFCHH WLHe3G6sqgVT0LZFfD6kijvoQteDeGYbpRQ4aa3c/hl6XxLzbCmBB5Ve6eIXF2yG lzQmcjbnbMrCokPyEpv1yWYQxHVht1XaHq7gm+ByH1eXgG+p8sn1fIQiOT0vEOeh FCwiLpXbqqY3kHenrF3F1w/jsD4SEflORQdfpm8F5VPQoBCR1vfNkzgxL1EqIWgN 7BAaFR0UsQy5QpThf+Ch =q3wQ -----END PGP SIGNATURE----- --Apple-Mail=_04F57626-F4F3-4ACF-98B4-63170BFCBFC0-- From nobody Thu Jun 25 07:48:27 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629CF1A8A0C for ; Thu, 25 Jun 2015 07:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 3v6P6Ox3j_Qd for ; Thu, 25 Jun 2015 07:48:23 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7B81A8A66 for ; Thu, 25 Jun 2015 07:47:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,677,1427785200"; d="scan'208";a="68518378" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 25 Jun 2015 08:44:40 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Jun 2015 07:47:34 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Thu, 25 Jun 2015 07:47:34 -0700 From: Shahram Davari To: Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLA= Date: Thu, 25 Jun 2015 14:47:33 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F29591@SJEXCHMB12.corp.ad.broadcom.com> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@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: [10.16.203.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 14:48:26 -0000 Hi Santosh, I think you probably have misunderstood the use of OAM/BFD in general. VXLA= N is not a networking layer, rather it is a service demultiplexer (service = identifier). I think the misunderstanding might be from the name "VXLAN tun= nel". Since VXLAN is not a tunnel. The tunnel is actually an IP tunnel that= has VXLAN as service identifier. A single IP tunnel can carry many VXLANs. Not only doing BFD per VXLAN doe= sn't make sense, but it is also not scalable. My suggestion is do BFD for t= he IP tunnel and you can achieve what you want. Thx Shahram -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, May 25, 2015 5:43 AM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (m= mudigon) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Greg, Thanks a lot for your review comments. Please see my inline comments. =20 >you reference RFC 5880 but don't specify which of defined in BFD base docu= ment modes are in scope of this work. I assume that, like in RFC 5884, it i= s only Asynchronous mode and Section 7 excludes Echo BFD but Demand mode no= t mentioned. >Making >more explicit statement would be helpful. Sure we can add text for Demand mode as well.=20 >section 2: >I think that these three cases hardly apply to the proposed solution. In p= articular, BFD may very coarsely localize path failure as we should remembe= r that path and remote peer failure are undistinguishable. Thus failure det= ected at one VM, with Tunnel >BFD session operational, cannot be interprete= d as peer VM failure. I am sorry I did not understand this, can you please elaborate more on this= ?=20 >section 3: >what ensures that reverse direction of the BFD session between IP1 (ingres= s) and IP2 (egress) , i.e. egress transmits BFD control packets toward the = ingress, uses the same tunnel traversed by BFD control packets sent from in= gress toward the egress? >Perhaps use of BFD Reverse Path TLV and BFD Discr= iminator TLV may be one solution? In case of IP if reverse path has multiple paths to a destination then taki= ng a particular path means IP header stacking? Correct me if I am wrong. =20 >Perhaps this section could be the right place to discuss and define behavi= or of the egress in terms of its role in BFD session: >packet encapsulation; >failure reporting; >path selection (discussed above). >And the issues of the encapsulation, reverse path selection are relevant f= or S-BFD scenario as well (I think that Prasad's suggestion to split into t= wo documents, BFD and S-BFD, is quite reasonable). If all the above point has different methods for BFD and S-BFD then of cour= se we should spilt the draft in to two.=20 >section 6.1: >considering 5884clarification work, can multiple BFD session operate betwe= en IP1 and IP2 over the same tunnel? I do not see a case where we need multiple BFD session between IP pair when= BFD session terminates at VTEP itself.=20 Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada Prasad= Govindan (venggovi) Sent: Friday, May 08, 2015 12:39 AM To: Santosh P K; MALLIK MUDIGONDA (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =A0 Hello Santosh/ Authors, Thanks for your prompt considerations of the comments submitted in this thr= ead. I request you to consider the following points for discussion: 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for OA= M layering in NVO3. Though, an individual draft at the moment, I submit tha= t we consider this for providing more context to the discussion here.=20 2) Per my understanding of your proposal, the intent is to use BFD for OAM = at the NV edge layer. Please let me know if this understanding is incorrect= . 3) The clarifications requested earlier this thread concern about the inner= IP address (SIP in particular) of the BFD packet . Would they be used from= the overlay IP address space (belonging to the tenant). If this is the cas= e, what would the difference between a BFD session using the tenant IP (at = the NV edge), a particular VNI, and that of a service layer OAM session tha= t can be run using single-hop BFD (RFC 5880).=20 In other words, how can the OAM (BFD in this case) operating at the NV Edge= layer operate without using IP from the Tenant layer if the packet is requ= ired to be VxLAN encapsulated? Thanks Prasad =A0 -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, May 06, 2015 3:03 PM To: MALLIK MUDIGONDA (mmudigon) Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =A0 Mallik, =A0=A0 Thanks for your review comments.=20 =A0 =A0 >1. It is not clear if this draft is addressing both VM to VM and VTEP to V= TEP verification through BFD. I assume it is both. =A0 Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 aware)= BFD as per RFC 5880/5881 should work as it is. VM's will not be aware of a= ny tunnel. Draft talks about tunnel verification which terminates at VTEP's= . =A0 >2. If the VMs are Layer 2 only, then what is the inner IP address=20 >(especially source IP)? I understand that outer IP is going to carry the V= TEPs addresses. =A0 As mentioned in the draft it would be outgoing interface IP sending VTEP.=20 =A0 >3. Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/10= 4? I understand that it is to avoid the packet being routed but, how can an= IP packet addressed to a particular VTEP be consumed by any other node in = the network and then route the inner >payload? =A0 The same argument holds true for MPLS as well right? The motivation for usi= ng the address range 127/8 is the same as described in Section 2.1 of RFC43= 79. =A0 >4. The service node's use case is not very clear. Mat be you can add a lit= tle bit of details here. =A0 Yes, we can do that.=20 =A0 >5. I understand that VTEP knows that the packet is to be terminated at the= VTEP based on TTL being 1. What about the case of VM to VM BFD? What shoul= d be the TTL value here? =A0 Is it 255 or something different? It is hardco= ded to "1" in the draft. =A0 VM's will use normal Async BFD so will use TTL 255.=20 =A0 >6. Since we are using a destination UDP port of 3784, shouldn't the TTL=20 >be 255 to be consistent with the RFC 5880? =A0 Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP port= number set to 3784.=20 =A0 =A0 Thanks Santosh P K =A0 =A0 =A0 From: "Vengada Prasad Govindan (venggovi)" Date: Wednesday, 6 May 2015 9:39 am To: Santosh P K , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =A0 Hello Santosh/ Authors, Thanks for sharing the document, please find a few thoughts below. 1. The current document talks about both BFD and S-BFD - would it be benefi= cial to make separate documents for BFD and SBFD to maintain consistency wi= th the current set of documents. 2. Motivation: It would be nice to state the requirements or motivation tha= t this draft addresses, i.e. what problems does this draft address that can= not be solved using the existing BFD/ SBFD protocol treating the VxLAN as a= tunnel/ underlay transport transparent to BFD. I would submit that BFD ove= r VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW = (VCCV) given the differences in the nature of the transport between MPLS an= d VxLAN. 3. Inner Ethernet header: The document does not address the contents of the= Inner Ethernet header (present after the VxLAN header). This needs to be s= pecified. 4. Destination IP: The document mandates that this needs to be 127/8. What = disadvantages do you observe if the DIP were to be the IP of the destinatio= n VTEP? When using 127/8 as the DIP. one problem is that there is no indica= tion of the intended DIP of the BFD session by using 127/8. What if the nod= e at which the VxLAN tunnel is (prematurely) terminated happens to support = BFD? It may be better to use the IP address of the Destination VTEP as the = DIP. 5. Inner TTL: For the same reasons discussed in (2), why does the document = mandate this to be set to 1? 6. It may be beneficial to run a spell-checker to fix typos in the document= . I request the authors/ WG to comment on the above aspects. Thanks Prasad =A0 =A0 -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, May 04, 2015 10:55 PM To: rtg-bfd@ietf.org Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =A0 Hello All, =A0=A0=A0=A0A new BFD for VXLAN draft has been submitted. Please do review = and get back to us with any comments/feedback.=20 =A0 Thanks Santosh P K=20 =A0 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, May 04, 2015 9:29 PM To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; Basil Sa= ji; Sudarsan Paragiri Mohan Subject: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt has been successfully submitted by Santosh Pallagatti and posted to the IET= F repository. Name: draft-spallagatti-bfd-vxlan Revision: 00 Title: BFD for VXLAN Document date: 2015-05-04 Group: Individual Submission Pages: 9 URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0https://www.ietf.org/internet-draft= s/draft-spallagatti-bfd-vxlan- 00.txt Status:=A0=A0=A0=A0=A0=A0=A0=A0 https://datatracker.ietf.org/doc/draft-spal= lagatti-bfd-vxlan/ Htmlized:=A0=A0=A0=A0=A0=A0 https://tools.ietf.org/html/draft-spallagatti-b= fd-vxlan-00 Abstract: =A0=A0=A0=A0This document describes use of Bidirectional Forwarding Detecti= on =A0=A0=A0=A0(BFD) protocol for VXLAN . Comments on this draft should be dir= ected =A0=A0=A0=A0to nvo3@ietf.org. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =A0 =A0 =A0 From nobody Fri Jun 26 00:19:53 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4B1B3496 for ; Fri, 26 Jun 2015 00:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1I0Mf6bRwo29 for ; Fri, 26 Jun 2015 00:19:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47021B3499 for ; Fri, 26 Jun 2015 00:19:48 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1727.namprd05.prod.outlook.com (10.163.130.18) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 26 Jun 2015 07:19:47 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 26 Jun 2015 07:19:46 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0195.005; Fri, 26 Jun 2015 07:19:46 +0000 From: Santosh P K To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMA== Date: Fri, 26 Jun 2015 07:19:46 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F29591@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadcom.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.13] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1760; 5:/NrNupZ27svtDwD4X6VKB329sCwTxmdSxNKEcUHfS23bibYO5cMscH5BagbIj3544SIymk/FkYg71H18hMbKtoM202Itl5rJe/dJJjRpC/myzlRjvENCtrjDRpUPrjItIeAWaQdc1ZJujXr5nij2WA==; 24:rysUv17nzRaClp+SHC1PxbCw4UZ5eBAsdQhGKyblyDAp5hpRfG6Kelv9WDUrla3bp4lK9LZ1zR/kXw1b8xrC24kNCG+a2aarGX3wDkB27KA=; 20:qkFbuQgsU4FE0e0DCe1tyCagrUy5PUS8yAI4VqN+AEC4/L/VEsyJvqA5En4u/56nDityM+RIq/tbsQXvAcUV/w== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1727; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1760; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; x-forefront-prvs: 0619D53754 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(52604005)(377454003)(377424004)(53754006)(13464003)(106116001)(2950100001)(5002640100001)(230783001)(54356999)(122556002)(5001960100002)(40100003)(74316001)(15975445007)(76176999)(77096005)(189998001)(92566002)(2900100001)(76576001)(102836002)(5001770100001)(99286002)(93886004)(87936001)(19580405001)(2656002)(33656002)(19580395003)(86362001)(62966003)(561944003)(5003600100002)(77156002)(46102003)(50986999)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1760; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2015 07:19:46.3120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1760 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1727; 2:WmJGAaEaUCgfWHCeqyGDNLEIEn66q9m9rH2FpsdyYLx/D8Hof+9vjnh5Dn+LJvSx; 3:8p2fO3u61NAuYe1bOcl3r7hLP6x6cejhXcIa6uwuX9/Rex54F8FTN21J4E8iLuwYTQs5pCMQ4eoLZp9VIriqfWgRGwe8q2bTsHghu07fnYM8RoMUBG2PGA2bcKInfOUyoNeB07MdWsQegNDAhMNi/g==; 23:nqVXfsZ1gEVVmu0o7Qh0UqYa3bAfqYPGwW7817TCXzEbyp7UCKf0bincP9naYW6ndJ9MAH1T/1CgPawyIF7K8pDMjnLhZN+zZZX7+CJdASRRxTaMxn6rDv0E9RNfe17md8DITlLwm6/RqLl4Iu6Qmoap2qlZZTfr8vxWO4j+8wlj6oGf8mdzIN6cDSCmbLqMAvq6PcENVfTVEOLJN7H/fVjSuIME9/KYjzC/S6c5sOXsTTiQt1fSpz+Zfx8W80vf X-OriginatorOrg: juniper.net Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 07:19:51 -0000 Hello Shahram, Thanks a lot for your comments. Indeed "VXLAN tunnel" is confusing, wh= at we are trying to do here is address the requirement from draft " https:/= /tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.txt". Here= we have a requirement for running proactive OAM between NV edge to NV edge= per VNI. This is an individual draft for now. Thanks Santosh P K=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, June 25, 2015 8:18 PM > To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); > MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Santosh, >=20 > I think you probably have misunderstood the use of OAM/BFD in general. > VXLAN is not a networking layer, rather it is a service demultiplexer (se= rvice > identifier). I think the misunderstanding might be from the name "VXLAN > tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP tunnel= that > has VXLAN as service identifier. >=20 > A single IP tunnel can carry many VXLANs. Not only doing BFD per VXLAN > doesn't make sense, but it is also not scalable. My suggestion is do BFD = for > the IP tunnel and you can achieve what you want. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Monday, May 25, 2015 5:43 AM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK > MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Greg, > Thanks a lot for your review comments. Please see my inline comments. >=20 > >you reference RFC 5880 but don't specify which of defined in BFD base > document modes are in scope of this work. I assume that, like in RFC 5884= , it > is only Asynchronous mode and Section 7 excludes Echo BFD but Demand > mode not mentioned. >Making >more explicit statement would be helpful. >=20 > Sure we can add text for Demand mode as well. >=20 >=20 > >section 2: > >I think that these three cases hardly apply to the proposed solution. In > particular, BFD may very coarsely localize path failure as we should > remember that path and remote peer failure are undistinguishable. Thus > failure detected at one VM, with Tunnel >BFD session operational, cannot = be > interpreted as peer VM failure. >=20 > I am sorry I did not understand this, can you please elaborate more on th= is? >=20 > >section 3: > >what ensures that reverse direction of the BFD session between IP1 > (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets to= ward > the ingress, uses the same tunnel traversed by BFD control packets sent > from ingress toward the egress? >Perhaps use of BFD Reverse Path TLV and > BFD Discriminator TLV may be one solution? >=20 > In case of IP if reverse path has multiple paths to a destination then ta= king a > particular path means IP header stacking? Correct me if I am wrong. >=20 > >Perhaps this section could be the right place to discuss and define beha= vior > of the egress in terms of its role in BFD session: > >packet encapsulation; > >failure reporting; > >path selection (discussed above). > >And the issues of the encapsulation, reverse path selection are relevant= for > S-BFD scenario as well (I think that Prasad's suggestion to split into tw= o > documents, BFD and S-BFD, is quite reasonable). >=20 > If all the above point has different methods for BFD and S-BFD then of co= urse > we should spilt the draft in to two. >=20 > >section 6.1: > >considering 5884clarification work, can multiple BFD session operate > between IP1 and IP2 over the same tunnel? >=20 > I do not see a case where we need multiple BFD session between IP pair > when BFD session terminates at VTEP itself. >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada > Prasad Govindan (venggovi) > Sent: Friday, May 08, 2015 12:39 AM > To: Santosh P K; MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Santosh/ Authors, > Thanks for your prompt considerations of the comments submitted in this > thread. I request you to consider the following points for discussion: > 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for > OAM layering in NVO3. Though, an individual draft at the moment, I submit > that we consider this for providing more context to the discussion here. > 2) Per my understanding of your proposal, the intent is to use BFD for OA= M > at the NV edge layer. Please let me know if this understanding is incorre= ct. > 3) The clarifications requested earlier this thread concern about the inn= er IP > address (SIP in particular) of the BFD packet . Would they be used from t= he > overlay IP address space (belonging to the tenant). If this is the case, = what > would the difference between a BFD session using the tenant IP (at the NV > edge), a particular VNI, and that of a service layer OAM session that can= be > run using single-hop BFD (RFC 5880). > In other words, how can the OAM (BFD in this case) operating at the NV Ed= ge > layer operate without using IP from the Tenant layer if the packet is req= uired > to be VxLAN encapsulated? > Thanks > Prasad >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Wednesday, May 06, 2015 3:03 PM > To: MALLIK MUDIGONDA (mmudigon) > Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Mallik, > =A0=A0 Thanks for your review comments. >=20 >=20 > >1. It is not clear if this draft is addressing both VM to VM and VTEP to= VTEP > verification through BFD. I assume it is both. >=20 > Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 awar= e) > BFD as per RFC 5880/5881 should work as it is. VM's will not be aware of = any > tunnel. Draft talks about tunnel verification which terminates at VTEP's. >=20 > >2. If the VMs are Layer 2 only, then what is the inner IP address > >(especially source IP)? I understand that outer IP is going to carry the= VTEPs > addresses. >=20 > As mentioned in the draft it would be outgoing interface IP sending VTEP. >=20 > >3. Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/= 104? > I understand that it is to avoid the packet being routed but, how can an = IP > packet addressed to a particular VTEP be consumed by any other node in th= e > network and then route the inner >payload? >=20 > The same argument holds true for MPLS as well right? The motivation for > using the address range 127/8 is the same as described in Section 2.1 of > RFC4379. >=20 > >4. The service node's use case is not very clear. Mat be you can add a l= ittle > bit of details here. >=20 > Yes, we can do that. >=20 > >5. I understand that VTEP knows that the packet is to be terminated at t= he > VTEP based on TTL being 1. What about the case of VM to VM BFD? What > should be the TTL value here? =A0 Is it 255 or something different? It is > hardcoded to "1" in the draft. >=20 > VM's will use normal Async BFD so will use TTL 255. >=20 > >6. Since we are using a destination UDP port of 3784, shouldn't the TTL > >be 255 to be consistent with the RFC 5880? >=20 > Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP po= rt > number set to 3784. >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 > From: "Vengada Prasad Govindan (venggovi)" > Date: Wednesday, 6 May 2015 9:39 am > To: Santosh P K , "rtg-bfd@ietf.org" bfd@ietf.org> > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Santosh/ Authors, > Thanks for sharing the document, please find a few thoughts below. > 1. The current document talks about both BFD and S-BFD - would it be > beneficial to make separate documents for BFD and SBFD to maintain > consistency with the current set of documents. > 2. Motivation: It would be nice to state the requirements or motivation t= hat > this draft addresses, i.e. what problems does this draft address that can= not > be solved using the existing BFD/ SBFD protocol treating the VxLAN as a > tunnel/ underlay transport transparent to BFD. I would submit that BFD ov= er > VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW > (VCCV) given the differences in the nature of the transport between MPLS > and VxLAN. > 3. Inner Ethernet header: The document does not address the contents of > the Inner Ethernet header (present after the VxLAN header). This needs to > be specified. > 4. Destination IP: The document mandates that this needs to be 127/8. Wha= t > disadvantages do you observe if the DIP were to be the IP of the destinat= ion > VTEP? When using 127/8 as the DIP. one problem is that there is no indica= tion > of the intended DIP of the BFD session by using 127/8. What if the node a= t > which the VxLAN tunnel is (prematurely) terminated happens to support > BFD? It may be better to use the IP address of the Destination VTEP as th= e > DIP. > 5. Inner TTL: For the same reasons discussed in (2), why does the documen= t > mandate this to be set to 1? > 6. It may be beneficial to run a spell-checker to fix typos in the docume= nt. > I request the authors/ WG to comment on the above aspects. > Thanks > Prasad >=20 >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Monday, May 04, 2015 10:55 PM > To: rtg-bfd@ietf.org > Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello All, > =A0=A0=A0=A0A new BFD for VXLAN draft has been submitted. Please do revie= w and get > back to us with any comments/feedback. >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, May 04, 2015 9:29 PM > To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; Basil = Saji; > Sudarsan Paragiri Mohan > Subject: New Version Notification for > draft-spallagatti-bfd-vxlan-00.txt > A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt > has been successfully submitted by Santosh Pallagatti and posted to the I= ETF > repository. > Name: draft-spallagatti-bfd-vxlan > Revision: 00 > Title: BFD for VXLAN > Document date: 2015-05-04 > Group: Individual Submission > Pages: 9 > URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0https://www.ietf.org/internet-dra= fts/draft-spallagatti-bfd-vxlan- > 00.txt > Status:=A0=A0=A0=A0=A0=A0=A0=A0 https://datatracker.ietf.org/doc/draft-sp= allagatti-bfd-vxlan/ > Htmlized:=A0=A0=A0=A0=A0=A0 https://tools.ietf.org/html/draft-spallagatti= -bfd-vxlan-00 > Abstract: > =A0=A0=A0=A0This document describes use of Bidirectional Forwarding Detec= tion > =A0=A0=A0=A0(BFD) protocol for VXLAN . Comments on this draft should be d= irected > =A0=A0=A0=A0to nvo3@ietf.org. > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat >=20 >=20 >=20 From nobody Fri Jun 26 00:32:21 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29AF1B34D5 for ; Fri, 26 Jun 2015 00:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sa3dMVbn865V for ; Fri, 26 Jun 2015 00:32:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1361B34C5 for ; Fri, 26 Jun 2015 00:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12794; q=dns/txt; s=iport; t=1435303938; x=1436513538; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1mVzUV/aSjrqNsTulO3iLhfA99k2oUXyG0DPyucC7RY=; b=a/MLatZfNnY0Tz9D+zfSzG1LPx1JkAnmTJah2LWDdBwquTbamE4A4CvY cr0paw8mw01kGJ1Lmb6IV1aKSOnM0T/UfArKik9h0rF/8HoZNF9LfN0Z5 ft2G9kKBTgZCi/s2bRJ6ftMSLVZzsK37OIZuTopl/Y+rAvTT/S/zHvUxo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHAwDE/4xV/4YNJK1bgxFUXwa8KGYJgWiFdgKBOTgUAQEBAQEBAYEKhCIBAQEEOj0CDAQCAQgRAwEBAR8JBx8TFAkIAgQBDQUbiBQNzl0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qFBgcGhCUBBIwSh3IBB4RQhnqBOkKDTo8Sg1wmggwcgVJvAYFFgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,683,1427760000"; d="scan'208";a="10494645" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jun 2015 07:32:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q7W9Jk014342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 07:32:09 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 26 Jun 2015 02:32:09 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Santosh P K , Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAtX+A Date: Fri, 26 Jun 2015 07:32:08 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@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: [10.143.25.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <939C746223A52E4B8FD578089C4C84F0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 07:32:20 -0000 Hi Shahram, Agree that running a separate session for each VNI is not going to be scalable. But the current draft only allows implementations to provide such a functionality. Implementations may choose to run a separate BFD session for a select set of VNIs (prioritise a select few) and so we do not want to preclude this possibility. We will leave it to implementations on which VNIs require this. May be we can rephrase the following in the draft under Section Deployment to avoid confusion. Replace this=20 Separate BFD sessions can be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" wrote: >Hello Shahram, > Thanks a lot for your comments. Indeed "VXLAN tunnel" is confusing, >what we are trying to do here is address the requirement from draft " >https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.tx >t". Here we have a requirement for running proactive OAM between NV edge >to NV edge per VNI. This is an individual draft for now. > >Thanks >Santosh P K=20 > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Thursday, June 25, 2015 8:18 PM >> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); >> MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Santosh, >>=20 >> I think you probably have misunderstood the use of OAM/BFD in general. >> VXLAN is not a networking layer, rather it is a service demultiplexer >>(service >> identifier). I think the misunderstanding might be from the name "VXLAN >> tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP >>tunnel that >> has VXLAN as service identifier. >>=20 >> A single IP tunnel can carry many VXLANs. Not only doing BFD per VXLAN >> doesn't make sense, but it is also not scalable. My suggestion is do >>BFD for >> the IP tunnel and you can achieve what you want. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, May 25, 2015 5:43 AM >> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK >> MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Greg, >> Thanks a lot for your review comments. Please see my inline comments. >>=20 >> >you reference RFC 5880 but don't specify which of defined in BFD base >> document modes are in scope of this work. I assume that, like in RFC >>5884, it >> is only Asynchronous mode and Section 7 excludes Echo BFD but Demand >> mode not mentioned. >Making >more explicit statement would be helpful. >>=20 >> Sure we can add text for Demand mode as well. >>=20 >>=20 >> >section 2: >> >I think that these three cases hardly apply to the proposed solution. >>In >> particular, BFD may very coarsely localize path failure as we should >> remember that path and remote peer failure are undistinguishable. Thus >> failure detected at one VM, with Tunnel >BFD session operational, >>cannot be >> interpreted as peer VM failure. >>=20 >> I am sorry I did not understand this, can you please elaborate more on >>this? >>=20 >> >section 3: >> >what ensures that reverse direction of the BFD session between IP1 >> (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets >>toward >> the ingress, uses the same tunnel traversed by BFD control packets sent >> from ingress toward the egress? >Perhaps use of BFD Reverse Path TLV and >> BFD Discriminator TLV may be one solution? >>=20 >> In case of IP if reverse path has multiple paths to a destination then >>taking a >> particular path means IP header stacking? Correct me if I am wrong. >>=20 >> >Perhaps this section could be the right place to discuss and define >>behavior >> of the egress in terms of its role in BFD session: >> >packet encapsulation; >> >failure reporting; >> >path selection (discussed above). >> >And the issues of the encapsulation, reverse path selection are >>relevant for >> S-BFD scenario as well (I think that Prasad's suggestion to split into >>two >> documents, BFD and S-BFD, is quite reasonable). >>=20 >> If all the above point has different methods for BFD and S-BFD then of >>course >> we should spilt the draft in to two. >>=20 >> >section 6.1: >> >considering 5884clarification work, can multiple BFD session operate >> between IP1 and IP2 over the same tunnel? >>=20 >> I do not see a case where we need multiple BFD session between IP pair >> when BFD session terminates at VTEP itself. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada >> Prasad Govindan (venggovi) >> Sent: Friday, May 08, 2015 12:39 AM >> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for your prompt considerations of the comments submitted in this >> thread. I request you to consider the following points for discussion: >> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for >> OAM layering in NVO3. Though, an individual draft at the moment, I >>submit >> that we consider this for providing more context to the discussion here. >> 2) Per my understanding of your proposal, the intent is to use BFD for >>OAM >> at the NV edge layer. Please let me know if this understanding is >>incorrect. >> 3) The clarifications requested earlier this thread concern about the >>inner IP >> address (SIP in particular) of the BFD packet . Would they be used from >>the >> overlay IP address space (belonging to the tenant). If this is the >>case, what >> would the difference between a BFD session using the tenant IP (at the >>NV >> edge), a particular VNI, and that of a service layer OAM session that >>can be >> run using single-hop BFD (RFC 5880). >> In other words, how can the OAM (BFD in this case) operating at the NV >>Edge >> layer operate without using IP from the Tenant layer if the packet is >>required >> to be VxLAN encapsulated? >> Thanks >> Prasad >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Wednesday, May 06, 2015 3:03 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Mallik, >> Thanks for your review comments. >>=20 >>=20 >> >1. It is not clear if this draft is addressing both VM to VM and VTEP >>to VTEP >> verification through BFD. I assume it is both. >>=20 >> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>aware) >> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware >>of any >> tunnel. Draft talks about tunnel verification which terminates at >>VTEP's. >>=20 >> >2. If the VMs are Layer 2 only, then what is the inner IP address >> >(especially source IP)? I understand that outer IP is going to carry >>the VTEPs >> addresses. >>=20 >> As mentioned in the draft it would be outgoing interface IP sending >>VTEP. >>=20 >> >3. Why is the inner IP destination address 127/8 or >>0:0:0:0:0:FFFF:7F00/104? >> I understand that it is to avoid the packet being routed but, how can >>an IP >> packet addressed to a particular VTEP be consumed by any other node in >>the >> network and then route the inner >payload? >>=20 >> The same argument holds true for MPLS as well right? The motivation for >> using the address range 127/8 is the same as described in Section 2.1 of >> RFC4379. >>=20 >> >4. The service node's use case is not very clear. Mat be you can add a >>little >> bit of details here. >>=20 >> Yes, we can do that. >>=20 >> >5. I understand that VTEP knows that the packet is to be terminated at >>the >> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >> should be the TTL value here? Is it 255 or something different? It is >> hardcoded to "1" in the draft. >>=20 >> VM's will use normal Async BFD so will use TTL 255. >>=20 >> >6. Since we are using a destination UDP port of 3784, shouldn't the TTL >> >be 255 to be consistent with the RFC 5880? >>=20 >> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP >>port >> number set to 3784. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> From: "Vengada Prasad Govindan (venggovi)" >> Date: Wednesday, 6 May 2015 9:39 am >> To: Santosh P K , "rtg-bfd@ietf.org" > bfd@ietf.org> >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for sharing the document, please find a few thoughts below. >> 1. The current document talks about both BFD and S-BFD - would it be >> beneficial to make separate documents for BFD and SBFD to maintain >> consistency with the current set of documents. >> 2. Motivation: It would be nice to state the requirements or motivation >>that >> this draft addresses, i.e. what problems does this draft address that >>cannot >> be solved using the existing BFD/ SBFD protocol treating the VxLAN as a >> tunnel/ underlay transport transparent to BFD. I would submit that BFD >>over >> VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW >> (VCCV) given the differences in the nature of the transport between MPLS >> and VxLAN. >> 3. Inner Ethernet header: The document does not address the contents of >> the Inner Ethernet header (present after the VxLAN header). This needs >>to >> be specified. >> 4. Destination IP: The document mandates that this needs to be 127/8. >>What >> disadvantages do you observe if the DIP were to be the IP of the >>destination >> VTEP? When using 127/8 as the DIP. one problem is that there is no >>indication >> of the intended DIP of the BFD session by using 127/8. What if the node >>at >> which the VxLAN tunnel is (prematurely) terminated happens to support >> BFD? It may be better to use the IP address of the Destination VTEP as >>the >> DIP. >> 5. Inner TTL: For the same reasons discussed in (2), why does the >>document >> mandate this to be set to 1? >> 6. It may be beneficial to run a spell-checker to fix typos in the >>document. >> I request the authors/ WG to comment on the above aspects. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, May 04, 2015 10:55 PM >> To: rtg-bfd@ietf.org >> Subject: FW: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello All, >> A new BFD for VXLAN draft has been submitted. Please do review and >>get >> back to us with any comments/feedback. >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, May 04, 2015 9:29 PM >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; >>Basil Saji; >> Sudarsan Paragiri Mohan >> Subject: New Version Notification for >> draft-spallagatti-bfd-vxlan-00.txt >> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >> has been successfully submitted by Santosh Pallagatti and posted to the >>IETF >> repository. >> Name: draft-spallagatti-bfd-vxlan >> Revision: 00 >> Title: BFD for VXLAN >> Document date: 2015-05-04 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >> 00.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >> Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . Comments on this draft should be directed >> to nvo3@ietf.org. >> 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. >> The IETF Secretariat >>=20 >>=20 >>=20 > From nobody Fri Jun 26 01:47:31 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7469E1A03B3 for ; Fri, 26 Jun 2015 01:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gVhUAhGwOXZ2 for ; Fri, 26 Jun 2015 01:47:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AE61A03C7 for ; Fri, 26 Jun 2015 01:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14405; q=dns/txt; s=iport; t=1435308447; x=1436518047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pn6XHwOWq//DFIbA/qoN3oDQRKbPsh+PC6EUVUI/7uE=; b=UEs5cFix9vvzhRdglj9ZdYmnAzR8WVmNHvRY7lujjwoAHJDu7sKKaBUU i54gM+V70l6j52KTJ5x+DaBDJ5w1Kde9HDZO2662Xd6XRzh5/Kxk+ayq1 IZQLq3TCDjq4ifhNNCF3BLlDJpQf3PRhrfylPDl0KmW3n8cKUj3D2C6UH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHAwChEI1V/51dJa1bgxFUXwa8L2YJgWaFeAKBOzgUAQEBAQEBAYEKhCIBAQEEOj0CDAQCAQgRAwEBAQsUCQcyFAkIAgQBDQUIE4gUDc5gAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhFUxBwaDEYEUAQSMEodyAYRXiDRCg06PEoNcJoIMHIFSb4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,683,1427760000"; d="scan'208";a="162987164" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 26 Jun 2015 08:47:25 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q8lPCI016661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 08:47:25 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 26 Jun 2015 03:47:25 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , Shahram Davari , Gregory Mirsky Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAtX+A//9ROeA= Date: Fri, 26 Jun 2015 08:47:24 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5457B2F8@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@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: [10.143.25.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:47:30 -0000 Hello Shahram/ BFD WG, A few points to consider: 1. From a layering perspective, I have the following observation to make: > My suggestion is do BFD for the IP tunnel and you can achieve what you w= ant. Equating IP connectivity between the two VTEPs purely in the underlay space= may not be the same as having connectivity in the overlay space. In other = words, there is considerable merit in running a BFD session over the VxLAN = tunnel (using any subset of VNI(s) provisioned by the operator) than runnin= g multi-hop BFD between the VTEPs. Kindly clarify if you differ here. 2. One more aspect that will need to be included in future versions of this= draft (in my opinion) is the possibility of having multiple BFD sessions b= etween the two VTEPs. Clearly, the zero-discriminator demux followed by the= single-hop approach may not work here, but a mechanism is needed to exerci= se the connectivity tracking of realizable ECMP paths may be very useful. N= eedless to say, how these paths are discovered is outside the scope of the = BFD specification. Thanks Prasad -----Original Message----- From: MALLIK MUDIGONDA (mmudigon)=20 Sent: Friday, June 26, 2015 1:02 PM To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (v= enggovi) Cc: rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, Agree that running a separate session for each VNI is not going to be scala= ble. But the current draft only allows implementations to provide such a fu= nctionality. Implementations may choose to run a separate BFD session for a= select set of VNIs (prioritise a select few) and so we do not want to prec= lude this possibility. We will leave it to implementations on which VNIs re= quire this. May be we can rephrase the following in the draft under Section Deployment = to avoid confusion. Replace this=20 Separate BFD sessions can be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" wrote: >Hello Shahram, > Thanks a lot for your comments. Indeed "VXLAN tunnel" is=20 >confusing, what we are trying to do here is address the requirement from d= raft " >https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03 >.tx t". Here we have a requirement for running proactive OAM between NV=20 >edge to NV edge per VNI. This is an individual draft for now. > >Thanks >Santosh P K > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Thursday, June 25, 2015 8:18 PM >> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); =20 >>MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Santosh, >>=20 >> I think you probably have misunderstood the use of OAM/BFD in general. >> VXLAN is not a networking layer, rather it is a service demultiplexer=20 >>(service identifier). I think the misunderstanding might be from the=20 >>name "VXLAN tunnel". Since VXLAN is not a tunnel. The tunnel is=20 >>actually an IP tunnel that has VXLAN as service identifier. >>=20 >> A single IP tunnel can carry many VXLANs. Not only doing BFD per=20 >>VXLAN doesn't make sense, but it is also not scalable. My suggestion=20 >>is do BFD for the IP tunnel and you can achieve what you want. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 25, 2015 5:43 AM >> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK =20 >>MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Greg, >> Thanks a lot for your review comments. Please see my inline comments. >>=20 >> >you reference RFC 5880 but don't specify which of defined in BFD=20 >> >base >> document modes are in scope of this work. I assume that, like in RFC=20 >>5884, it is only Asynchronous mode and Section 7 excludes Echo BFD=20 >>but Demand mode not mentioned. >Making >more explicit statement would=20 >>be helpful. >>=20 >> Sure we can add text for Demand mode as well. >>=20 >>=20 >> >section 2: >> >I think that these three cases hardly apply to the proposed solution. >>In >> particular, BFD may very coarsely localize path failure as we should =20 >>remember that path and remote peer failure are undistinguishable. Thus =20 >>failure detected at one VM, with Tunnel >BFD session operational,=20 >>cannot be interpreted as peer VM failure. >>=20 >> I am sorry I did not understand this, can you please elaborate more=20 >>on this? >>=20 >> >section 3: >> >what ensures that reverse direction of the BFD session between IP1 >> (ingress) and IP2 (egress) , i.e. egress transmits BFD control=20 >>packets toward the ingress, uses the same tunnel traversed by BFD=20 >>control packets sent from ingress toward the egress? >Perhaps use of=20 >>BFD Reverse Path TLV and BFD Discriminator TLV may be one solution? >>=20 >> In case of IP if reverse path has multiple paths to a destination=20 >>then taking a particular path means IP header stacking? Correct me if=20 >>I am wrong. >>=20 >> >Perhaps this section could be the right place to discuss and define >>behavior >> of the egress in terms of its role in BFD session: >> >packet encapsulation; >> >failure reporting; >> >path selection (discussed above). >> >And the issues of the encapsulation, reverse path selection are >>relevant for >> S-BFD scenario as well (I think that Prasad's suggestion to split=20 >>into two documents, BFD and S-BFD, is quite reasonable). >>=20 >> If all the above point has different methods for BFD and S-BFD then=20 >>of course we should spilt the draft in to two. >>=20 >> >section 6.1: >> >considering 5884clarification work, can multiple BFD session operate >> between IP1 and IP2 over the same tunnel? >>=20 >> I do not see a case where we need multiple BFD session between IP=20 >> pair when BFD session terminates at VTEP itself. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada =20 >>Prasad Govindan (venggovi) >> Sent: Friday, May 08, 2015 12:39 AM >> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for your prompt considerations of the comments submitted in=20 >>this thread. I request you to consider the following points for discussi= on: >> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context=20 >>for OAM layering in NVO3. Though, an individual draft at the moment,=20 >>I submit that we consider this for providing more context to the=20 >>discussion here. >> 2) Per my understanding of your proposal, the intent is to use BFD=20 >>for OAM at the NV edge layer. Please let me know if this=20 >>understanding is incorrect. >> 3) The clarifications requested earlier this thread concern about the=20 >>inner IP address (SIP in particular) of the BFD packet . Would they=20 >>be used from the overlay IP address space (belonging to the tenant).=20 >>If this is the case, what would the difference between a BFD session=20 >>using the tenant IP (at the NV edge), a particular VNI, and that of a=20 >>service layer OAM session that can be run using single-hop BFD (RFC=20 >>5880). >> In other words, how can the OAM (BFD in this case) operating at the=20 >>NV Edge layer operate without using IP from the Tenant layer if the=20 >>packet is required to be VxLAN encapsulated? >> Thanks >> Prasad >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Wednesday, May 06, 2015 3:03 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Mallik, >> Thanks for your review comments. >>=20 >>=20 >> >1. It is not clear if this draft is addressing both VM to VM and=20 >> >VTEP >>to VTEP >> verification through BFD. I assume it is both. >>=20 >> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>aware) >> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware=20 >>of any tunnel. Draft talks about tunnel verification which terminates=20 >>at VTEP's. >>=20 >> >2. If the VMs are Layer 2 only, then what is the inner IP address=20 >> >(especially source IP)? I understand that outer IP is going to carry >>the VTEPs >> addresses. >>=20 >> As mentioned in the draft it would be outgoing interface IP sending=20 >>VTEP. >>=20 >> >3. Why is the inner IP destination address 127/8 or >>0:0:0:0:0:FFFF:7F00/104? >> I understand that it is to avoid the packet being routed but, how can=20 >>an IP packet addressed to a particular VTEP be consumed by any other=20 >>node in the network and then route the inner >payload? >>=20 >> The same argument holds true for MPLS as well right? The motivation=20 >> for using the address range 127/8 is the same as described in Section=20 >> 2.1 of RFC4379. >>=20 >> >4. The service node's use case is not very clear. Mat be you can add=20 >> >a >>little >> bit of details here. >>=20 >> Yes, we can do that. >>=20 >> >5. I understand that VTEP knows that the packet is to be terminated=20 >> >at >>the >> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >> should be the TTL value here? Is it 255 or something different? It is >> hardcoded to "1" in the draft. >>=20 >> VM's will use normal Async BFD so will use TTL 255. >>=20 >> >6. Since we are using a destination UDP port of 3784, shouldn't the=20 >> >TTL be 255 to be consistent with the RFC 5880? >>=20 >> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas=20 >>UDP port number set to 3784. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> From: "Vengada Prasad Govindan (venggovi)" >> Date: Wednesday, 6 May 2015 9:39 am >> To: Santosh P K , "rtg-bfd@ietf.org" >bfd@ietf.org> >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for sharing the document, please find a few thoughts below. >> 1. The current document talks about both BFD and S-BFD - would it be =20 >>beneficial to make separate documents for BFD and SBFD to maintain =20 >>consistency with the current set of documents. >> 2. Motivation: It would be nice to state the requirements or=20 >>motivation that this draft addresses, i.e. what problems does this=20 >>draft address that cannot be solved using the existing BFD/ SBFD=20 >>protocol treating the VxLAN as a tunnel/ underlay transport=20 >>transparent to BFD. I would submit that BFD over VxLAN not be treated=20 >>along the same lines of BFD over MPLS or BFD for PW >> (VCCV) given the differences in the nature of the transport between=20 >>MPLS and VxLAN. >> 3. Inner Ethernet header: The document does not address the contents=20 >>of the Inner Ethernet header (present after the VxLAN header). This=20 >>needs to be specified. >> 4. Destination IP: The document mandates that this needs to be 127/8. >>What >> disadvantages do you observe if the DIP were to be the IP of the=20 >>destination VTEP? When using 127/8 as the DIP. one problem is that=20 >>there is no indication of the intended DIP of the BFD session by=20 >>using 127/8. What if the node at which the VxLAN tunnel is=20 >>(prematurely) terminated happens to support BFD? It may be better to=20 >>use the IP address of the Destination VTEP as the DIP. >> 5. Inner TTL: For the same reasons discussed in (2), why does the=20 >>document mandate this to be set to 1? >> 6. It may be beneficial to run a spell-checker to fix typos in the=20 >>document. >> I request the authors/ WG to comment on the above aspects. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 04, 2015 10:55 PM >> To: rtg-bfd@ietf.org >> Subject: FW: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello All, >> A new BFD for VXLAN draft has been submitted. Please do review=20 >>and get back to us with any comments/feedback. >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, May 04, 2015 9:29 PM >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;=20 >>Basil Saji; Sudarsan Paragiri Mohan >> Subject: New Version Notification for =20 >>draft-spallagatti-bfd-vxlan-00.txt >> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >> has been successfully submitted by Santosh Pallagatti and posted to=20 >>the IETF repository. >> Name: draft-spallagatti-bfd-vxlan >> Revision: 00 >> Title: BFD for VXLAN >> Document date: 2015-05-04 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >> 00.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >> Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . Comments on this draft should be directed >> to nvo3@ietf.org. >> 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=20 >>tools.ietf.org. >> The IETF Secretariat >>=20 >>=20 >>=20 > From nobody Fri Jun 26 11:39:16 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1DE1A92E0 for ; Fri, 26 Jun 2015 11:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 AbAY43jrYHpT for ; Fri, 26 Jun 2015 11:39:12 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5461A92DD for ; Fri, 26 Jun 2015 11:39:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,686,1427785200"; d="scan'208";a="68366668" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw3-out.broadcom.com with ESMTP; 26 Jun 2015 11:53:03 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Jun 2015 11:39:10 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Fri, 26 Jun 2015 11:39:10 -0700 From: Shahram Davari To: Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAv1pQ Date: Fri, 26 Jun 2015 18:39:10 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F2B4C7@SJEXCHMB12.corp.ad.broadcom.com> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@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: [10.16.203.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:39:15 -0000 Hi Stantosh, I don't agree with the requirements draft you mentioned. I don't think it i= s required or makes sense to run OAM for a VNI. Thx Shahram -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Friday, June 26, 2015 12:20 AM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi); MAL= LIK MUDIGONDA (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, Thanks a lot for your comments. Indeed "VXLAN tunnel" is confusing, wh= at we are trying to do here is address the requirement from draft " https:/= /tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.txt". Here= we have a requirement for running proactive OAM between NV edge to NV edge= per VNI. This is an individual draft for now. Thanks Santosh P K=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, June 25, 2015 8:18 PM > To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); > MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Santosh, >=20 > I think you probably have misunderstood the use of OAM/BFD in general. > VXLAN is not a networking layer, rather it is a service demultiplexer (se= rvice > identifier). I think the misunderstanding might be from the name "VXLAN > tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP tunnel= that > has VXLAN as service identifier. >=20 > A single IP tunnel can carry many VXLANs. Not only doing BFD per VXLAN > doesn't make sense, but it is also not scalable. My suggestion is do BFD = for > the IP tunnel and you can achieve what you want. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Monday, May 25, 2015 5:43 AM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK > MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Greg, > Thanks a lot for your review comments. Please see my inline comments. >=20 > >you reference RFC 5880 but don't specify which of defined in BFD base > document modes are in scope of this work. I assume that, like in RFC 5884= , it > is only Asynchronous mode and Section 7 excludes Echo BFD but Demand > mode not mentioned. >Making >more explicit statement would be helpful. >=20 > Sure we can add text for Demand mode as well. >=20 >=20 > >section 2: > >I think that these three cases hardly apply to the proposed solution. In > particular, BFD may very coarsely localize path failure as we should > remember that path and remote peer failure are undistinguishable. Thus > failure detected at one VM, with Tunnel >BFD session operational, cannot = be > interpreted as peer VM failure. >=20 > I am sorry I did not understand this, can you please elaborate more on th= is? >=20 > >section 3: > >what ensures that reverse direction of the BFD session between IP1 > (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets to= ward > the ingress, uses the same tunnel traversed by BFD control packets sent > from ingress toward the egress? >Perhaps use of BFD Reverse Path TLV and > BFD Discriminator TLV may be one solution? >=20 > In case of IP if reverse path has multiple paths to a destination then ta= king a > particular path means IP header stacking? Correct me if I am wrong. >=20 > >Perhaps this section could be the right place to discuss and define beha= vior > of the egress in terms of its role in BFD session: > >packet encapsulation; > >failure reporting; > >path selection (discussed above). > >And the issues of the encapsulation, reverse path selection are relevant= for > S-BFD scenario as well (I think that Prasad's suggestion to split into tw= o > documents, BFD and S-BFD, is quite reasonable). >=20 > If all the above point has different methods for BFD and S-BFD then of co= urse > we should spilt the draft in to two. >=20 > >section 6.1: > >considering 5884clarification work, can multiple BFD session operate > between IP1 and IP2 over the same tunnel? >=20 > I do not see a case where we need multiple BFD session between IP pair > when BFD session terminates at VTEP itself. >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada > Prasad Govindan (venggovi) > Sent: Friday, May 08, 2015 12:39 AM > To: Santosh P K; MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Santosh/ Authors, > Thanks for your prompt considerations of the comments submitted in this > thread. I request you to consider the following points for discussion: > 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for > OAM layering in NVO3. Though, an individual draft at the moment, I submit > that we consider this for providing more context to the discussion here. > 2) Per my understanding of your proposal, the intent is to use BFD for OA= M > at the NV edge layer. Please let me know if this understanding is incorre= ct. > 3) The clarifications requested earlier this thread concern about the inn= er IP > address (SIP in particular) of the BFD packet . Would they be used from t= he > overlay IP address space (belonging to the tenant). If this is the case, = what > would the difference between a BFD session using the tenant IP (at the NV > edge), a particular VNI, and that of a service layer OAM session that can= be > run using single-hop BFD (RFC 5880). > In other words, how can the OAM (BFD in this case) operating at the NV Ed= ge > layer operate without using IP from the Tenant layer if the packet is req= uired > to be VxLAN encapsulated? > Thanks > Prasad >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Wednesday, May 06, 2015 3:03 PM > To: MALLIK MUDIGONDA (mmudigon) > Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Mallik, > =A0=A0 Thanks for your review comments. >=20 >=20 > >1. It is not clear if this draft is addressing both VM to VM and VTEP to= VTEP > verification through BFD. I assume it is both. >=20 > Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 awar= e) > BFD as per RFC 5880/5881 should work as it is. VM's will not be aware of = any > tunnel. Draft talks about tunnel verification which terminates at VTEP's. >=20 > >2. If the VMs are Layer 2 only, then what is the inner IP address > >(especially source IP)? I understand that outer IP is going to carry the= VTEPs > addresses. >=20 > As mentioned in the draft it would be outgoing interface IP sending VTEP. >=20 > >3. Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/= 104? > I understand that it is to avoid the packet being routed but, how can an = IP > packet addressed to a particular VTEP be consumed by any other node in th= e > network and then route the inner >payload? >=20 > The same argument holds true for MPLS as well right? The motivation for > using the address range 127/8 is the same as described in Section 2.1 of > RFC4379. >=20 > >4. The service node's use case is not very clear. Mat be you can add a l= ittle > bit of details here. >=20 > Yes, we can do that. >=20 > >5. I understand that VTEP knows that the packet is to be terminated at t= he > VTEP based on TTL being 1. What about the case of VM to VM BFD? What > should be the TTL value here? =A0 Is it 255 or something different? It is > hardcoded to "1" in the draft. >=20 > VM's will use normal Async BFD so will use TTL 255. >=20 > >6. Since we are using a destination UDP port of 3784, shouldn't the TTL > >be 255 to be consistent with the RFC 5880? >=20 > Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP po= rt > number set to 3784. >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 > From: "Vengada Prasad Govindan (venggovi)" > Date: Wednesday, 6 May 2015 9:39 am > To: Santosh P K , "rtg-bfd@ietf.org" bfd@ietf.org> > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Santosh/ Authors, > Thanks for sharing the document, please find a few thoughts below. > 1. The current document talks about both BFD and S-BFD - would it be > beneficial to make separate documents for BFD and SBFD to maintain > consistency with the current set of documents. > 2. Motivation: It would be nice to state the requirements or motivation t= hat > this draft addresses, i.e. what problems does this draft address that can= not > be solved using the existing BFD/ SBFD protocol treating the VxLAN as a > tunnel/ underlay transport transparent to BFD. I would submit that BFD ov= er > VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW > (VCCV) given the differences in the nature of the transport between MPLS > and VxLAN. > 3. Inner Ethernet header: The document does not address the contents of > the Inner Ethernet header (present after the VxLAN header). This needs to > be specified. > 4. Destination IP: The document mandates that this needs to be 127/8. Wha= t > disadvantages do you observe if the DIP were to be the IP of the destinat= ion > VTEP? When using 127/8 as the DIP. one problem is that there is no indica= tion > of the intended DIP of the BFD session by using 127/8. What if the node a= t > which the VxLAN tunnel is (prematurely) terminated happens to support > BFD? It may be better to use the IP address of the Destination VTEP as th= e > DIP. > 5. Inner TTL: For the same reasons discussed in (2), why does the documen= t > mandate this to be set to 1? > 6. It may be beneficial to run a spell-checker to fix typos in the docume= nt. > I request the authors/ WG to comment on the above aspects. > Thanks > Prasad >=20 >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Monday, May 04, 2015 10:55 PM > To: rtg-bfd@ietf.org > Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello All, > =A0=A0=A0=A0A new BFD for VXLAN draft has been submitted. Please do revie= w and get > back to us with any comments/feedback. >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, May 04, 2015 9:29 PM > To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; Basil = Saji; > Sudarsan Paragiri Mohan > Subject: New Version Notification for > draft-spallagatti-bfd-vxlan-00.txt > A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt > has been successfully submitted by Santosh Pallagatti and posted to the I= ETF > repository. > Name: draft-spallagatti-bfd-vxlan > Revision: 00 > Title: BFD for VXLAN > Document date: 2015-05-04 > Group: Individual Submission > Pages: 9 > URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0https://www.ietf.org/internet-dra= fts/draft-spallagatti-bfd-vxlan- > 00.txt > Status:=A0=A0=A0=A0=A0=A0=A0=A0 https://datatracker.ietf.org/doc/draft-sp= allagatti-bfd-vxlan/ > Htmlized:=A0=A0=A0=A0=A0=A0 https://tools.ietf.org/html/draft-spallagatti= -bfd-vxlan-00 > Abstract: > =A0=A0=A0=A0This document describes use of Bidirectional Forwarding Detec= tion > =A0=A0=A0=A0(BFD) protocol for VXLAN . Comments on this draft should be d= irected > =A0=A0=A0=A0to nvo3@ietf.org. > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat >=20 >=20 >=20 From nobody Fri Jun 26 11:42:30 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B021A92EE for ; Fri, 26 Jun 2015 11:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 tB_7mSklj-GQ for ; Fri, 26 Jun 2015 11:42:26 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id DB0A81A90E2 for ; Fri, 26 Jun 2015 11:42:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,686,1427785200"; d="scan'208";a="68510967" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 26 Jun 2015 11:57:26 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Jun 2015 11:42:25 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Fri, 26 Jun 2015 11:42:25 -0700 From: Shahram Davari To: "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAtX+AgAAKYJA= Date: Fri, 26 Jun 2015 18:42:23 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F2B511@SJEXCHMB12.corp.ad.broadcom.com> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@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: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:42:29 -0000 Hi Mallik, We have been through this route before in other protocols. Such as LM/DM. b= elieve me customers will run OAM for all flows not a subset. We can't say yes we know it is not scalable, so please don't run too many o= f them. A better way is define an OAM that can aggregate many Of these flows. For example run OAM on the IP tunnel. Thx Shahram -----Original Message----- From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]=20 Sent: Friday, June 26, 2015 12:32 AM To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (v= enggovi) Cc: rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, Agree that running a separate session for each VNI is not going to be scalable. But the current draft only allows implementations to provide such a functionality. Implementations may choose to run a separate BFD session for a select set of VNIs (prioritise a select few) and so we do not want to preclude this possibility. We will leave it to implementations on which VNIs require this. May be we can rephrase the following in the draft under Section Deployment to avoid confusion. Replace this=20 Separate BFD sessions can be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" wrote: >Hello Shahram, > Thanks a lot for your comments. Indeed "VXLAN tunnel" is confusing, >what we are trying to do here is address the requirement from draft " >https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.tx >t". Here we have a requirement for running proactive OAM between NV edge >to NV edge per VNI. This is an individual draft for now. > >Thanks >Santosh P K=20 > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Thursday, June 25, 2015 8:18 PM >> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); >> MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Santosh, >>=20 >> I think you probably have misunderstood the use of OAM/BFD in general. >> VXLAN is not a networking layer, rather it is a service demultiplexer >>(service >> identifier). I think the misunderstanding might be from the name "VXLAN >> tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP >>tunnel that >> has VXLAN as service identifier. >>=20 >> A single IP tunnel can carry many VXLANs. Not only doing BFD per VXLAN >> doesn't make sense, but it is also not scalable. My suggestion is do >>BFD for >> the IP tunnel and you can achieve what you want. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, May 25, 2015 5:43 AM >> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK >> MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Greg, >> Thanks a lot for your review comments. Please see my inline comments. >>=20 >> >you reference RFC 5880 but don't specify which of defined in BFD base >> document modes are in scope of this work. I assume that, like in RFC >>5884, it >> is only Asynchronous mode and Section 7 excludes Echo BFD but Demand >> mode not mentioned. >Making >more explicit statement would be helpful. >>=20 >> Sure we can add text for Demand mode as well. >>=20 >>=20 >> >section 2: >> >I think that these three cases hardly apply to the proposed solution. >>In >> particular, BFD may very coarsely localize path failure as we should >> remember that path and remote peer failure are undistinguishable. Thus >> failure detected at one VM, with Tunnel >BFD session operational, >>cannot be >> interpreted as peer VM failure. >>=20 >> I am sorry I did not understand this, can you please elaborate more on >>this? >>=20 >> >section 3: >> >what ensures that reverse direction of the BFD session between IP1 >> (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets >>toward >> the ingress, uses the same tunnel traversed by BFD control packets sent >> from ingress toward the egress? >Perhaps use of BFD Reverse Path TLV and >> BFD Discriminator TLV may be one solution? >>=20 >> In case of IP if reverse path has multiple paths to a destination then >>taking a >> particular path means IP header stacking? Correct me if I am wrong. >>=20 >> >Perhaps this section could be the right place to discuss and define >>behavior >> of the egress in terms of its role in BFD session: >> >packet encapsulation; >> >failure reporting; >> >path selection (discussed above). >> >And the issues of the encapsulation, reverse path selection are >>relevant for >> S-BFD scenario as well (I think that Prasad's suggestion to split into >>two >> documents, BFD and S-BFD, is quite reasonable). >>=20 >> If all the above point has different methods for BFD and S-BFD then of >>course >> we should spilt the draft in to two. >>=20 >> >section 6.1: >> >considering 5884clarification work, can multiple BFD session operate >> between IP1 and IP2 over the same tunnel? >>=20 >> I do not see a case where we need multiple BFD session between IP pair >> when BFD session terminates at VTEP itself. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada >> Prasad Govindan (venggovi) >> Sent: Friday, May 08, 2015 12:39 AM >> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for your prompt considerations of the comments submitted in this >> thread. I request you to consider the following points for discussion: >> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for >> OAM layering in NVO3. Though, an individual draft at the moment, I >>submit >> that we consider this for providing more context to the discussion here. >> 2) Per my understanding of your proposal, the intent is to use BFD for >>OAM >> at the NV edge layer. Please let me know if this understanding is >>incorrect. >> 3) The clarifications requested earlier this thread concern about the >>inner IP >> address (SIP in particular) of the BFD packet . Would they be used from >>the >> overlay IP address space (belonging to the tenant). If this is the >>case, what >> would the difference between a BFD session using the tenant IP (at the >>NV >> edge), a particular VNI, and that of a service layer OAM session that >>can be >> run using single-hop BFD (RFC 5880). >> In other words, how can the OAM (BFD in this case) operating at the NV >>Edge >> layer operate without using IP from the Tenant layer if the packet is >>required >> to be VxLAN encapsulated? >> Thanks >> Prasad >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Wednesday, May 06, 2015 3:03 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Mallik, >> Thanks for your review comments. >>=20 >>=20 >> >1. It is not clear if this draft is addressing both VM to VM and VTEP >>to VTEP >> verification through BFD. I assume it is both. >>=20 >> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>aware) >> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware >>of any >> tunnel. Draft talks about tunnel verification which terminates at >>VTEP's. >>=20 >> >2. If the VMs are Layer 2 only, then what is the inner IP address >> >(especially source IP)? I understand that outer IP is going to carry >>the VTEPs >> addresses. >>=20 >> As mentioned in the draft it would be outgoing interface IP sending >>VTEP. >>=20 >> >3. Why is the inner IP destination address 127/8 or >>0:0:0:0:0:FFFF:7F00/104? >> I understand that it is to avoid the packet being routed but, how can >>an IP >> packet addressed to a particular VTEP be consumed by any other node in >>the >> network and then route the inner >payload? >>=20 >> The same argument holds true for MPLS as well right? The motivation for >> using the address range 127/8 is the same as described in Section 2.1 of >> RFC4379. >>=20 >> >4. The service node's use case is not very clear. Mat be you can add a >>little >> bit of details here. >>=20 >> Yes, we can do that. >>=20 >> >5. I understand that VTEP knows that the packet is to be terminated at >>the >> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >> should be the TTL value here? Is it 255 or something different? It is >> hardcoded to "1" in the draft. >>=20 >> VM's will use normal Async BFD so will use TTL 255. >>=20 >> >6. Since we are using a destination UDP port of 3784, shouldn't the TTL >> >be 255 to be consistent with the RFC 5880? >>=20 >> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP >>port >> number set to 3784. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> From: "Vengada Prasad Govindan (venggovi)" >> Date: Wednesday, 6 May 2015 9:39 am >> To: Santosh P K , "rtg-bfd@ietf.org" > bfd@ietf.org> >> Subject: RE: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for sharing the document, please find a few thoughts below. >> 1. The current document talks about both BFD and S-BFD - would it be >> beneficial to make separate documents for BFD and SBFD to maintain >> consistency with the current set of documents. >> 2. Motivation: It would be nice to state the requirements or motivation >>that >> this draft addresses, i.e. what problems does this draft address that >>cannot >> be solved using the existing BFD/ SBFD protocol treating the VxLAN as a >> tunnel/ underlay transport transparent to BFD. I would submit that BFD >>over >> VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW >> (VCCV) given the differences in the nature of the transport between MPLS >> and VxLAN. >> 3. Inner Ethernet header: The document does not address the contents of >> the Inner Ethernet header (present after the VxLAN header). This needs >>to >> be specified. >> 4. Destination IP: The document mandates that this needs to be 127/8. >>What >> disadvantages do you observe if the DIP were to be the IP of the >>destination >> VTEP? When using 127/8 as the DIP. one problem is that there is no >>indication >> of the intended DIP of the BFD session by using 127/8. What if the node >>at >> which the VxLAN tunnel is (prematurely) terminated happens to support >> BFD? It may be better to use the IP address of the Destination VTEP as >>the >> DIP. >> 5. Inner TTL: For the same reasons discussed in (2), why does the >>document >> mandate this to be set to 1? >> 6. It may be beneficial to run a spell-checker to fix typos in the >>document. >> I request the authors/ WG to comment on the above aspects. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, May 04, 2015 10:55 PM >> To: rtg-bfd@ietf.org >> Subject: FW: New Version Notification for >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello All, >> A new BFD for VXLAN draft has been submitted. Please do review and >>get >> back to us with any comments/feedback. >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, May 04, 2015 9:29 PM >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; >>Basil Saji; >> Sudarsan Paragiri Mohan >> Subject: New Version Notification for >> draft-spallagatti-bfd-vxlan-00.txt >> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >> has been successfully submitted by Santosh Pallagatti and posted to the >>IETF >> repository. >> Name: draft-spallagatti-bfd-vxlan >> Revision: 00 >> Title: BFD for VXLAN >> Document date: 2015-05-04 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >> 00.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >> Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . Comments on this draft should be directed >> to nvo3@ietf.org. >> 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. >> The IETF Secretariat >>=20 >>=20 >>=20 > From nobody Fri Jun 26 11:46:09 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67321A92FC for ; Fri, 26 Jun 2015 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 Rm2gLz3yzfOS for ; Fri, 26 Jun 2015 11:46:04 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id C4A0C1A92F8 for ; Fri, 26 Jun 2015 11:46:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,686,1427785200"; d="scan'208";a="68511367" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 26 Jun 2015 12:01:05 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Jun 2015 11:46:04 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Fri, 26 Jun 2015 11:46:04 -0700 From: Shahram Davari To: "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , Gregory Mirsky Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAtX+A//9ROeCAALoMAA== Date: Fri, 26 Jun 2015 18:46:03 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F2B599@SJEXCHMB12.corp.ad.broadcom.com> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@SJEXCHMB12.corp.ad.broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457B2F8@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D5457B2F8@xmb-rcd-x15.cisco.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:46:08 -0000 Hi Vengada, Yes off course I differ. Please provide an example of a failure that can o= nly be detected by your draft and can't be detected by a BFD on the IP tunn= el. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Friday, June 26, 2015 1:47 AM To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory Mirsk= y Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram/ BFD WG, A few points to consider: 1. From a layering perspective, I have the following observation to make: > My suggestion is do BFD for the IP tunnel and you can achieve what you w= ant. Equating IP connectivity between the two VTEPs purely in the underlay space= may not be the same as having connectivity in the overlay space. In other = words, there is considerable merit in running a BFD session over the VxLAN = tunnel (using any subset of VNI(s) provisioned by the operator) than runnin= g multi-hop BFD between the VTEPs. Kindly clarify if you differ here. 2. One more aspect that will need to be included in future versions of this= draft (in my opinion) is the possibility of having multiple BFD sessions b= etween the two VTEPs. Clearly, the zero-discriminator demux followed by the= single-hop approach may not work here, but a mechanism is needed to exerci= se the connectivity tracking of realizable ECMP paths may be very useful. N= eedless to say, how these paths are discovered is outside the scope of the = BFD specification. Thanks Prasad -----Original Message----- From: MALLIK MUDIGONDA (mmudigon)=20 Sent: Friday, June 26, 2015 1:02 PM To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (v= enggovi) Cc: rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, Agree that running a separate session for each VNI is not going to be scala= ble. But the current draft only allows implementations to provide such a fu= nctionality. Implementations may choose to run a separate BFD session for a= select set of VNIs (prioritise a select few) and so we do not want to prec= lude this possibility. We will leave it to implementations on which VNIs re= quire this. May be we can rephrase the following in the draft under Section Deployment = to avoid confusion. Replace this=20 Separate BFD sessions can be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" wrote: >Hello Shahram, > Thanks a lot for your comments. Indeed "VXLAN tunnel" is=20 >confusing, what we are trying to do here is address the requirement from d= raft " >https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03 >.tx t". Here we have a requirement for running proactive OAM between NV=20 >edge to NV edge per VNI. This is an individual draft for now. > >Thanks >Santosh P K > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Thursday, June 25, 2015 8:18 PM >> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); =20 >>MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Santosh, >>=20 >> I think you probably have misunderstood the use of OAM/BFD in general. >> VXLAN is not a networking layer, rather it is a service demultiplexer=20 >>(service identifier). I think the misunderstanding might be from the=20 >>name "VXLAN tunnel". Since VXLAN is not a tunnel. The tunnel is=20 >>actually an IP tunnel that has VXLAN as service identifier. >>=20 >> A single IP tunnel can carry many VXLANs. Not only doing BFD per=20 >>VXLAN doesn't make sense, but it is also not scalable. My suggestion=20 >>is do BFD for the IP tunnel and you can achieve what you want. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 25, 2015 5:43 AM >> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK =20 >>MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Greg, >> Thanks a lot for your review comments. Please see my inline comments. >>=20 >> >you reference RFC 5880 but don't specify which of defined in BFD=20 >> >base >> document modes are in scope of this work. I assume that, like in RFC=20 >>5884, it is only Asynchronous mode and Section 7 excludes Echo BFD=20 >>but Demand mode not mentioned. >Making >more explicit statement would=20 >>be helpful. >>=20 >> Sure we can add text for Demand mode as well. >>=20 >>=20 >> >section 2: >> >I think that these three cases hardly apply to the proposed solution. >>In >> particular, BFD may very coarsely localize path failure as we should =20 >>remember that path and remote peer failure are undistinguishable. Thus =20 >>failure detected at one VM, with Tunnel >BFD session operational,=20 >>cannot be interpreted as peer VM failure. >>=20 >> I am sorry I did not understand this, can you please elaborate more=20 >>on this? >>=20 >> >section 3: >> >what ensures that reverse direction of the BFD session between IP1 >> (ingress) and IP2 (egress) , i.e. egress transmits BFD control=20 >>packets toward the ingress, uses the same tunnel traversed by BFD=20 >>control packets sent from ingress toward the egress? >Perhaps use of=20 >>BFD Reverse Path TLV and BFD Discriminator TLV may be one solution? >>=20 >> In case of IP if reverse path has multiple paths to a destination=20 >>then taking a particular path means IP header stacking? Correct me if=20 >>I am wrong. >>=20 >> >Perhaps this section could be the right place to discuss and define >>behavior >> of the egress in terms of its role in BFD session: >> >packet encapsulation; >> >failure reporting; >> >path selection (discussed above). >> >And the issues of the encapsulation, reverse path selection are >>relevant for >> S-BFD scenario as well (I think that Prasad's suggestion to split=20 >>into two documents, BFD and S-BFD, is quite reasonable). >>=20 >> If all the above point has different methods for BFD and S-BFD then=20 >>of course we should spilt the draft in to two. >>=20 >> >section 6.1: >> >considering 5884clarification work, can multiple BFD session operate >> between IP1 and IP2 over the same tunnel? >>=20 >> I do not see a case where we need multiple BFD session between IP=20 >> pair when BFD session terminates at VTEP itself. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada =20 >>Prasad Govindan (venggovi) >> Sent: Friday, May 08, 2015 12:39 AM >> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for your prompt considerations of the comments submitted in=20 >>this thread. I request you to consider the following points for discussi= on: >> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context=20 >>for OAM layering in NVO3. Though, an individual draft at the moment,=20 >>I submit that we consider this for providing more context to the=20 >>discussion here. >> 2) Per my understanding of your proposal, the intent is to use BFD=20 >>for OAM at the NV edge layer. Please let me know if this=20 >>understanding is incorrect. >> 3) The clarifications requested earlier this thread concern about the=20 >>inner IP address (SIP in particular) of the BFD packet . Would they=20 >>be used from the overlay IP address space (belonging to the tenant).=20 >>If this is the case, what would the difference between a BFD session=20 >>using the tenant IP (at the NV edge), a particular VNI, and that of a=20 >>service layer OAM session that can be run using single-hop BFD (RFC=20 >>5880). >> In other words, how can the OAM (BFD in this case) operating at the=20 >>NV Edge layer operate without using IP from the Tenant layer if the=20 >>packet is required to be VxLAN encapsulated? >> Thanks >> Prasad >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Wednesday, May 06, 2015 3:03 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Mallik, >> Thanks for your review comments. >>=20 >>=20 >> >1. It is not clear if this draft is addressing both VM to VM and=20 >> >VTEP >>to VTEP >> verification through BFD. I assume it is both. >>=20 >> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>aware) >> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware=20 >>of any tunnel. Draft talks about tunnel verification which terminates=20 >>at VTEP's. >>=20 >> >2. If the VMs are Layer 2 only, then what is the inner IP address=20 >> >(especially source IP)? I understand that outer IP is going to carry >>the VTEPs >> addresses. >>=20 >> As mentioned in the draft it would be outgoing interface IP sending=20 >>VTEP. >>=20 >> >3. Why is the inner IP destination address 127/8 or >>0:0:0:0:0:FFFF:7F00/104? >> I understand that it is to avoid the packet being routed but, how can=20 >>an IP packet addressed to a particular VTEP be consumed by any other=20 >>node in the network and then route the inner >payload? >>=20 >> The same argument holds true for MPLS as well right? The motivation=20 >> for using the address range 127/8 is the same as described in Section=20 >> 2.1 of RFC4379. >>=20 >> >4. The service node's use case is not very clear. Mat be you can add=20 >> >a >>little >> bit of details here. >>=20 >> Yes, we can do that. >>=20 >> >5. I understand that VTEP knows that the packet is to be terminated=20 >> >at >>the >> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >> should be the TTL value here? Is it 255 or something different? It is >> hardcoded to "1" in the draft. >>=20 >> VM's will use normal Async BFD so will use TTL 255. >>=20 >> >6. Since we are using a destination UDP port of 3784, shouldn't the=20 >> >TTL be 255 to be consistent with the RFC 5880? >>=20 >> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas=20 >>UDP port number set to 3784. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> From: "Vengada Prasad Govindan (venggovi)" >> Date: Wednesday, 6 May 2015 9:39 am >> To: Santosh P K , "rtg-bfd@ietf.org" >bfd@ietf.org> >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for sharing the document, please find a few thoughts below. >> 1. The current document talks about both BFD and S-BFD - would it be =20 >>beneficial to make separate documents for BFD and SBFD to maintain =20 >>consistency with the current set of documents. >> 2. Motivation: It would be nice to state the requirements or=20 >>motivation that this draft addresses, i.e. what problems does this=20 >>draft address that cannot be solved using the existing BFD/ SBFD=20 >>protocol treating the VxLAN as a tunnel/ underlay transport=20 >>transparent to BFD. I would submit that BFD over VxLAN not be treated=20 >>along the same lines of BFD over MPLS or BFD for PW >> (VCCV) given the differences in the nature of the transport between=20 >>MPLS and VxLAN. >> 3. Inner Ethernet header: The document does not address the contents=20 >>of the Inner Ethernet header (present after the VxLAN header). This=20 >>needs to be specified. >> 4. Destination IP: The document mandates that this needs to be 127/8. >>What >> disadvantages do you observe if the DIP were to be the IP of the=20 >>destination VTEP? When using 127/8 as the DIP. one problem is that=20 >>there is no indication of the intended DIP of the BFD session by=20 >>using 127/8. What if the node at which the VxLAN tunnel is=20 >>(prematurely) terminated happens to support BFD? It may be better to=20 >>use the IP address of the Destination VTEP as the DIP. >> 5. Inner TTL: For the same reasons discussed in (2), why does the=20 >>document mandate this to be set to 1? >> 6. It may be beneficial to run a spell-checker to fix typos in the=20 >>document. >> I request the authors/ WG to comment on the above aspects. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 04, 2015 10:55 PM >> To: rtg-bfd@ietf.org >> Subject: FW: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello All, >> A new BFD for VXLAN draft has been submitted. Please do review=20 >>and get back to us with any comments/feedback. >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, May 04, 2015 9:29 PM >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;=20 >>Basil Saji; Sudarsan Paragiri Mohan >> Subject: New Version Notification for =20 >>draft-spallagatti-bfd-vxlan-00.txt >> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >> has been successfully submitted by Santosh Pallagatti and posted to=20 >>the IETF repository. >> Name: draft-spallagatti-bfd-vxlan >> Revision: 00 >> Title: BFD for VXLAN >> Document date: 2015-05-04 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >> 00.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >> Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . Comments on this draft should be directed >> to nvo3@ietf.org. >> 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=20 >>tools.ietf.org. >> The IETF Secretariat >>=20 >>=20 >>=20 > From nobody Fri Jun 26 11:50:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDD91A905C for ; Fri, 26 Jun 2015 11:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fM_79dZ25tUJ for ; Fri, 26 Jun 2015 11:50:08 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076F71AC3A1 for ; Fri, 26 Jun 2015 11:50:07 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-b6-558d444a0199 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.FC.12958.A444D855; Fri, 26 Jun 2015 14:23:38 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Fri, 26 Jun 2015 14:50:06 -0400 From: Gregory Mirsky To: Shahram Davari , "MALLIK MUDIGONDA (mmudigon)" , Santosh P K , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAtX+AgAAKYJCAAAIOMA== Date: Fri, 26 Jun 2015 18:50:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9EEBAD@eusaamb106.ericsson.se> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F2B511@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F2B511@SJEXCHMB12.corp.ad.broadcom.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXRPlK6XS2+owcpGDYv1vZ4WR14dY7b4 /Gcbo8W1u1uZLWZ+2MTswOox6/5ZNo8pvzeyeixZ8pPJ43rTVfYAligum5TUnMyy1CJ9uwSu jC87ZzIXHM+vmLtlPmMD4+KoLkYODgkBE4kp3WVdjJxAppjEhXvr2UBsIYGjjBL9t7W7GLmA 7OWMElsObmIESbAJGEm82NjDDmKLCBxglHh1IwvEZhbQlGg68ZkdZKawgI/ExtkcECW+Erdf LWGDsOsktn55xQpSwiKgKtF5IxvE5AUq+dRSAbFpL6vEh/5WZpA4p0C4xN+PMiCdjECXfT+1 hglikbjErSfzmSAuFpBYsuc8M4QtKvHy8T9WCFtJYtLSc6wQ9ToSC3Z/YoOwtSWWLXwNVs8r IChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIymYxJsujsY97y0PMQo wMGoxMO7wLEnVIg1say4MvcQozQHi5I4r2NUXqiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xoqHZ5lCrzOJZMVukZ6zoGhdjeR/UX7OEB0p5cfbTv9tvbMpc/WU2OMLT9XemWmWvkeScZ4A n8XNRJfY318u9bUV2TUE+MxWqNbwM226pvVf7r2Y4NW4U0x1Mw6/TVJ11fj9rHxGsN9hIZ3+ GH33vdMKuXlTtk1U6P3Lb5n9eE6IjFfbOmdrJZbijERDLeai4kQAt0tw4YcCAAA= Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:50:12 -0000 Hi Shahram, I think that requirement to support Service-level OAM is practical and well= -justified. I agree that when and how Service-level OAM can and will be use= d by operators depends upon choice of vendors being made. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, June 26, 2015 11:42 AM To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Gregory Mirsky; Vengada Prasa= d Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Mallik, We have been through this route before in other protocols. Such as LM/DM. b= elieve me customers will run OAM for all flows not a subset. We can't say yes we know it is not scalable, so please don't run too many o= f them. A better way is define an OAM that can aggregate many Of these flow= s. For example run OAM on the IP tunnel. Thx Shahram -----Original Message----- From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, June 26, 2015 12:32 AM To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (v= enggovi) Cc: rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, Agree that running a separate session for each VNI is not going to be scala= ble. But the current draft only allows implementations to provide such a fu= nctionality. Implementations may choose to run a separate BFD session for a= select set of VNIs (prioritise a select few) and so we do not want to prec= lude this possibility. We will leave it to implementations on which VNIs re= quire this. May be we can rephrase the following in the draft under Section Deployment = to avoid confusion. Replace this=20 Separate BFD sessions can be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" wrote: >Hello Shahram, > Thanks a lot for your comments. Indeed "VXLAN tunnel" is=20 >confusing, what we are trying to do here is address the requirement from d= raft " >https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03 >.tx t". Here we have a requirement for running proactive OAM between NV=20 >edge to NV edge per VNI. This is an individual draft for now. > >Thanks >Santosh P K > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Thursday, June 25, 2015 8:18 PM >> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); =20 >>MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Santosh, >>=20 >> I think you probably have misunderstood the use of OAM/BFD in general. >> VXLAN is not a networking layer, rather it is a service demultiplexer=20 >>(service identifier). I think the misunderstanding might be from the=20 >>name "VXLAN tunnel". Since VXLAN is not a tunnel. The tunnel is=20 >>actually an IP tunnel that has VXLAN as service identifier. >>=20 >> A single IP tunnel can carry many VXLANs. Not only doing BFD per=20 >>VXLAN doesn't make sense, but it is also not scalable. My suggestion=20 >>is do BFD for the IP tunnel and you can achieve what you want. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 25, 2015 5:43 AM >> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK =20 >>MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Greg, >> Thanks a lot for your review comments. Please see my inline comments. >>=20 >> >you reference RFC 5880 but don't specify which of defined in BFD=20 >> >base >> document modes are in scope of this work. I assume that, like in RFC=20 >>5884, it is only Asynchronous mode and Section 7 excludes Echo BFD=20 >>but Demand mode not mentioned. >Making >more explicit statement would=20 >>be helpful. >>=20 >> Sure we can add text for Demand mode as well. >>=20 >>=20 >> >section 2: >> >I think that these three cases hardly apply to the proposed solution. >>In >> particular, BFD may very coarsely localize path failure as we should =20 >>remember that path and remote peer failure are undistinguishable. Thus =20 >>failure detected at one VM, with Tunnel >BFD session operational,=20 >>cannot be interpreted as peer VM failure. >>=20 >> I am sorry I did not understand this, can you please elaborate more=20 >>on this? >>=20 >> >section 3: >> >what ensures that reverse direction of the BFD session between IP1 >> (ingress) and IP2 (egress) , i.e. egress transmits BFD control=20 >>packets toward the ingress, uses the same tunnel traversed by BFD=20 >>control packets sent from ingress toward the egress? >Perhaps use of=20 >>BFD Reverse Path TLV and BFD Discriminator TLV may be one solution? >>=20 >> In case of IP if reverse path has multiple paths to a destination=20 >>then taking a particular path means IP header stacking? Correct me if=20 >>I am wrong. >>=20 >> >Perhaps this section could be the right place to discuss and define >>behavior >> of the egress in terms of its role in BFD session: >> >packet encapsulation; >> >failure reporting; >> >path selection (discussed above). >> >And the issues of the encapsulation, reverse path selection are >>relevant for >> S-BFD scenario as well (I think that Prasad's suggestion to split=20 >>into two documents, BFD and S-BFD, is quite reasonable). >>=20 >> If all the above point has different methods for BFD and S-BFD then=20 >>of course we should spilt the draft in to two. >>=20 >> >section 6.1: >> >considering 5884clarification work, can multiple BFD session operate >> between IP1 and IP2 over the same tunnel? >>=20 >> I do not see a case where we need multiple BFD session between IP=20 >> pair when BFD session terminates at VTEP itself. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada =20 >>Prasad Govindan (venggovi) >> Sent: Friday, May 08, 2015 12:39 AM >> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for your prompt considerations of the comments submitted in=20 >>this thread. I request you to consider the following points for discussi= on: >> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context=20 >>for OAM layering in NVO3. Though, an individual draft at the moment,=20 >>I submit that we consider this for providing more context to the=20 >>discussion here. >> 2) Per my understanding of your proposal, the intent is to use BFD=20 >>for OAM at the NV edge layer. Please let me know if this=20 >>understanding is incorrect. >> 3) The clarifications requested earlier this thread concern about the=20 >>inner IP address (SIP in particular) of the BFD packet . Would they=20 >>be used from the overlay IP address space (belonging to the tenant).=20 >>If this is the case, what would the difference between a BFD session=20 >>using the tenant IP (at the NV edge), a particular VNI, and that of a=20 >>service layer OAM session that can be run using single-hop BFD (RFC=20 >>5880). >> In other words, how can the OAM (BFD in this case) operating at the=20 >>NV Edge layer operate without using IP from the Tenant layer if the=20 >>packet is required to be VxLAN encapsulated? >> Thanks >> Prasad >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Wednesday, May 06, 2015 3:03 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Mallik, >> Thanks for your review comments. >>=20 >>=20 >> >1. It is not clear if this draft is addressing both VM to VM and=20 >> >VTEP >>to VTEP >> verification through BFD. I assume it is both. >>=20 >> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>aware) >> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware=20 >>of any tunnel. Draft talks about tunnel verification which terminates=20 >>at VTEP's. >>=20 >> >2. If the VMs are Layer 2 only, then what is the inner IP address=20 >> >(especially source IP)? I understand that outer IP is going to carry >>the VTEPs >> addresses. >>=20 >> As mentioned in the draft it would be outgoing interface IP sending=20 >>VTEP. >>=20 >> >3. Why is the inner IP destination address 127/8 or >>0:0:0:0:0:FFFF:7F00/104? >> I understand that it is to avoid the packet being routed but, how can=20 >>an IP packet addressed to a particular VTEP be consumed by any other=20 >>node in the network and then route the inner >payload? >>=20 >> The same argument holds true for MPLS as well right? The motivation=20 >> for using the address range 127/8 is the same as described in Section=20 >> 2.1 of RFC4379. >>=20 >> >4. The service node's use case is not very clear. Mat be you can add=20 >> >a >>little >> bit of details here. >>=20 >> Yes, we can do that. >>=20 >> >5. I understand that VTEP knows that the packet is to be terminated=20 >> >at >>the >> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >> should be the TTL value here? Is it 255 or something different? It is >> hardcoded to "1" in the draft. >>=20 >> VM's will use normal Async BFD so will use TTL 255. >>=20 >> >6. Since we are using a destination UDP port of 3784, shouldn't the=20 >> >TTL be 255 to be consistent with the RFC 5880? >>=20 >> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas=20 >>UDP port number set to 3784. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> From: "Vengada Prasad Govindan (venggovi)" >> Date: Wednesday, 6 May 2015 9:39 am >> To: Santosh P K , "rtg-bfd@ietf.org" >bfd@ietf.org> >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for sharing the document, please find a few thoughts below. >> 1. The current document talks about both BFD and S-BFD - would it be =20 >>beneficial to make separate documents for BFD and SBFD to maintain =20 >>consistency with the current set of documents. >> 2. Motivation: It would be nice to state the requirements or=20 >>motivation that this draft addresses, i.e. what problems does this=20 >>draft address that cannot be solved using the existing BFD/ SBFD=20 >>protocol treating the VxLAN as a tunnel/ underlay transport=20 >>transparent to BFD. I would submit that BFD over VxLAN not be treated=20 >>along the same lines of BFD over MPLS or BFD for PW >> (VCCV) given the differences in the nature of the transport between=20 >>MPLS and VxLAN. >> 3. Inner Ethernet header: The document does not address the contents=20 >>of the Inner Ethernet header (present after the VxLAN header). This=20 >>needs to be specified. >> 4. Destination IP: The document mandates that this needs to be 127/8. >>What >> disadvantages do you observe if the DIP were to be the IP of the=20 >>destination VTEP? When using 127/8 as the DIP. one problem is that=20 >>there is no indication of the intended DIP of the BFD session by=20 >>using 127/8. What if the node at which the VxLAN tunnel is=20 >>(prematurely) terminated happens to support BFD? It may be better to=20 >>use the IP address of the Destination VTEP as the DIP. >> 5. Inner TTL: For the same reasons discussed in (2), why does the=20 >>document mandate this to be set to 1? >> 6. It may be beneficial to run a spell-checker to fix typos in the=20 >>document. >> I request the authors/ WG to comment on the above aspects. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 04, 2015 10:55 PM >> To: rtg-bfd@ietf.org >> Subject: FW: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello All, >> A new BFD for VXLAN draft has been submitted. Please do review=20 >>and get back to us with any comments/feedback. >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, May 04, 2015 9:29 PM >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;=20 >>Basil Saji; Sudarsan Paragiri Mohan >> Subject: New Version Notification for =20 >>draft-spallagatti-bfd-vxlan-00.txt >> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >> has been successfully submitted by Santosh Pallagatti and posted to=20 >>the IETF repository. >> Name: draft-spallagatti-bfd-vxlan >> Revision: 00 >> Title: BFD for VXLAN >> Document date: 2015-05-04 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >> 00.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >> Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . Comments on this draft should be directed >> to nvo3@ietf.org. >> 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=20 >>tools.ietf.org. >> The IETF Secretariat >>=20 >>=20 >>=20 > From nobody Fri Jun 26 11:57:31 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A331A1B7B for ; Fri, 26 Jun 2015 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Rr79ZucB311L for ; Fri, 26 Jun 2015 11:57:26 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF78E1ABC75 for ; Fri, 26 Jun 2015 11:57:25 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-8d-558d4600c452 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.6D.12958.0064D855; Fri, 26 Jun 2015 14:30:56 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Fri, 26 Jun 2015 14:57:24 -0400 From: Gregory Mirsky To: Shahram Davari , "Vengada Prasad Govindan (venggovi)" , "MALLIK MUDIGONDA (mmudigon)" , Santosh P K Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQhoMzEknWHHNqr0WZplypYqzrJZ1sESBQgAIITPCAAUTJAP//UQqAgAMDsJCAAReXEIAZ912wgDDabLCAARWZMIAAtX+A//9ROeCAALoMAIAAA1Qg Date: Fri, 26 Jun 2015 18:57:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9EEBDB@eusaamb106.ericsson.se> References: <315041E4211CB84E86EF7C25A2AB583D54474DD2@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D544798F2@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B97EC1B@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F29591@SJEXCHMB12.corp.ad.broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457B2F8@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F2B599@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F2B599@SJEXCHMB12.corp.ad.broadcom.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPny6DW2+owZvrKhbrez0tjrw6xmzx +c82Rotrd7cyW8z8sInZgdVj1v2zbB5Tfm9k9Viy5CeTx/Wmq+wBLFFcNimpOZllqUX6dglc GVduP2MtmFBZ0XzyBHsDY3dSFyMnh4SAicT1bR2sELaYxIV769m6GLk4hASOMkqcudfCAuEs Z5Q40rMXrIpNwEjixcYedpCEiMABRoldGx6CJZgFNCWaTnwGSnBwCAv4SGyczQESFhHwlbj9 agkbRH0To8SVvossIAkWAVWJ751zwHp5gYr2PvoBta2BTWLK40PMIIM4BcIlVqxzBalhBDrv +6k1TBC7xCVuPZnPBHG2gMSSPeeZIWxRiZeP/0G9oyQxaek5qNt0JBbs/sQGYWtLLFv4mhli r6DEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyipGjtDi1LDfdyGATIzCyjkmw6e5g3PPS8hCj AAejEg/vAseeUCHWxLLiytxDjNIcLErivI5ReaFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GHnnFf9QbDdyPbZVkoVl2qWgr4yvlnfL87vIzz25mnWjyhyx1iUvJtyd9vfEtBMzuqRq5xbk 1U+LtuFZZfdA3lRrRWvenRZdIZciuwPxs36nrA2zaGt5E8eucres5nJwmt32iGnT9jVuqijZ EfU2QMPwz96bUcUcsTHStuzXJtuf9iyfq7RtuxJLcUaioRZzUXEiABvOovONAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:57:29 -0000 Hi Shahram, unless monitoring of IP tunnel complemented by e2e Service-level OAM, which= is even more questionable since VMs would have less HW support to OAM, abi= lity to run VTEP-VTEP OAM at Service level seems as very strong requirement= . Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Friday, June 26, 2015 11:46 AM To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Santos= h P K; Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Vengada, Yes off course I differ. Please provide an example of a failure that can o= nly be detected by your draft and can't be detected by a BFD on the IP tunn= el. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] Sent: Friday, June 26, 2015 1:47 AM To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory Mirsk= y Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram/ BFD WG, A few points to consider: 1. From a layering perspective, I have the following observation to make: > My suggestion is do BFD for the IP tunnel and you can achieve what you w= ant. Equating IP connectivity between the two VTEPs purely in the underlay space= may not be the same as having connectivity in the overlay space. In other = words, there is considerable merit in running a BFD session over the VxLAN = tunnel (using any subset of VNI(s) provisioned by the operator) than runnin= g multi-hop BFD between the VTEPs. Kindly clarify if you differ here. 2. One more aspect that will need to be included in future versions of this= draft (in my opinion) is the possibility of having multiple BFD sessions b= etween the two VTEPs. Clearly, the zero-discriminator demux followed by the= single-hop approach may not work here, but a mechanism is needed to exerci= se the connectivity tracking of realizable ECMP paths may be very useful. N= eedless to say, how these paths are discovered is outside the scope of the = BFD specification. Thanks Prasad -----Original Message----- From: MALLIK MUDIGONDA (mmudigon) Sent: Friday, June 26, 2015 1:02 PM To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (v= enggovi) Cc: rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, Agree that running a separate session for each VNI is not going to be scala= ble. But the current draft only allows implementations to provide such a fu= nctionality. Implementations may choose to run a separate BFD session for a= select set of VNIs (prioritise a select few) and so we do not want to prec= lude this possibility. We will leave it to implementations on which VNIs re= quire this. May be we can rephrase the following in the draft under Section Deployment = to avoid confusion. Replace this=20 Separate BFD sessions can be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" wrote: >Hello Shahram, > Thanks a lot for your comments. Indeed "VXLAN tunnel" is=20 >confusing, what we are trying to do here is address the requirement from d= raft " >https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03 >.tx t". Here we have a requirement for running proactive OAM between NV=20 >edge to NV edge per VNI. This is an individual draft for now. > >Thanks >Santosh P K > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Thursday, June 25, 2015 8:18 PM >> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi);=20 >>MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Santosh, >>=20 >> I think you probably have misunderstood the use of OAM/BFD in general. >> VXLAN is not a networking layer, rather it is a service demultiplexer=20 >>(service identifier). I think the misunderstanding might be from the=20 >>name "VXLAN tunnel". Since VXLAN is not a tunnel. The tunnel is=20 >>actually an IP tunnel that has VXLAN as service identifier. >>=20 >> A single IP tunnel can carry many VXLANs. Not only doing BFD per=20 >>VXLAN doesn't make sense, but it is also not scalable. My suggestion=20 >>is do BFD for the IP tunnel and you can achieve what you want. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 25, 2015 5:43 AM >> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK=20 >>MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Greg, >> Thanks a lot for your review comments. Please see my inline comments. >>=20 >> >you reference RFC 5880 but don't specify which of defined in BFD=20 >> >base >> document modes are in scope of this work. I assume that, like in RFC=20 >>5884, it is only Asynchronous mode and Section 7 excludes Echo BFD=20 >>but Demand mode not mentioned. >Making >more explicit statement would=20 >>be helpful. >>=20 >> Sure we can add text for Demand mode as well. >>=20 >>=20 >> >section 2: >> >I think that these three cases hardly apply to the proposed solution. >>In >> particular, BFD may very coarsely localize path failure as we should=20 >>remember that path and remote peer failure are undistinguishable. Thus=20 >>failure detected at one VM, with Tunnel >BFD session operational,=20 >>cannot be interpreted as peer VM failure. >>=20 >> I am sorry I did not understand this, can you please elaborate more=20 >>on this? >>=20 >> >section 3: >> >what ensures that reverse direction of the BFD session between IP1 >> (ingress) and IP2 (egress) , i.e. egress transmits BFD control=20 >>packets toward the ingress, uses the same tunnel traversed by BFD=20 >>control packets sent from ingress toward the egress? >Perhaps use of=20 >>BFD Reverse Path TLV and BFD Discriminator TLV may be one solution? >>=20 >> In case of IP if reverse path has multiple paths to a destination=20 >>then taking a particular path means IP header stacking? Correct me if=20 >>I am wrong. >>=20 >> >Perhaps this section could be the right place to discuss and define >>behavior >> of the egress in terms of its role in BFD session: >> >packet encapsulation; >> >failure reporting; >> >path selection (discussed above). >> >And the issues of the encapsulation, reverse path selection are >>relevant for >> S-BFD scenario as well (I think that Prasad's suggestion to split=20 >>into two documents, BFD and S-BFD, is quite reasonable). >>=20 >> If all the above point has different methods for BFD and S-BFD then=20 >>of course we should spilt the draft in to two. >>=20 >> >section 6.1: >> >considering 5884clarification work, can multiple BFD session operate >> between IP1 and IP2 over the same tunnel? >>=20 >> I do not see a case where we need multiple BFD session between IP=20 >> pair when BFD session terminates at VTEP itself. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada=20 >>Prasad Govindan (venggovi) >> Sent: Friday, May 08, 2015 12:39 AM >> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for your prompt considerations of the comments submitted in=20 >>this thread. I request you to consider the following points for discussi= on: >> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context=20 >>for OAM layering in NVO3. Though, an individual draft at the moment,=20 >>I submit that we consider this for providing more context to the=20 >>discussion here. >> 2) Per my understanding of your proposal, the intent is to use BFD=20 >>for OAM at the NV edge layer. Please let me know if this=20 >>understanding is incorrect. >> 3) The clarifications requested earlier this thread concern about the=20 >>inner IP address (SIP in particular) of the BFD packet . Would they=20 >>be used from the overlay IP address space (belonging to the tenant). >>If this is the case, what would the difference between a BFD session=20 >>using the tenant IP (at the NV edge), a particular VNI, and that of a=20 >>service layer OAM session that can be run using single-hop BFD (RFC=20 >>5880). >> In other words, how can the OAM (BFD in this case) operating at the=20 >>NV Edge layer operate without using IP from the Tenant layer if the=20 >>packet is required to be VxLAN encapsulated? >> Thanks >> Prasad >>=20 >> -----Original Message----- >> From: Santosh P K [mailto:santoshpk@juniper.net] >> Sent: Wednesday, May 06, 2015 3:03 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Mallik, >> Thanks for your review comments. >>=20 >>=20 >> >1. It is not clear if this draft is addressing both VM to VM and=20 >> >VTEP >>to VTEP >> verification through BFD. I assume it is both. >>=20 >> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>aware) >> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware=20 >>of any tunnel. Draft talks about tunnel verification which terminates=20 >>at VTEP's. >>=20 >> >2. If the VMs are Layer 2 only, then what is the inner IP address=20 >> >(especially source IP)? I understand that outer IP is going to carry >>the VTEPs >> addresses. >>=20 >> As mentioned in the draft it would be outgoing interface IP sending=20 >>VTEP. >>=20 >> >3. Why is the inner IP destination address 127/8 or >>0:0:0:0:0:FFFF:7F00/104? >> I understand that it is to avoid the packet being routed but, how can=20 >>an IP packet addressed to a particular VTEP be consumed by any other=20 >>node in the network and then route the inner >payload? >>=20 >> The same argument holds true for MPLS as well right? The motivation=20 >> for using the address range 127/8 is the same as described in Section >> 2.1 of RFC4379. >>=20 >> >4. The service node's use case is not very clear. Mat be you can add=20 >> >a >>little >> bit of details here. >>=20 >> Yes, we can do that. >>=20 >> >5. I understand that VTEP knows that the packet is to be terminated=20 >> >at >>the >> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >> should be the TTL value here? Is it 255 or something different? It is >> hardcoded to "1" in the draft. >>=20 >> VM's will use normal Async BFD so will use TTL 255. >>=20 >> >6. Since we are using a destination UDP port of 3784, shouldn't the=20 >> >TTL be 255 to be consistent with the RFC 5880? >>=20 >> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas=20 >>UDP port number set to 3784. >>=20 >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >>=20 >> From: "Vengada Prasad Govindan (venggovi)" >> Date: Wednesday, 6 May 2015 9:39 am >> To: Santosh P K , "rtg-bfd@ietf.org" >bfd@ietf.org> >> Subject: RE: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Santosh/ Authors, >> Thanks for sharing the document, please find a few thoughts below. >> 1. The current document talks about both BFD and S-BFD - would it be=20 >>beneficial to make separate documents for BFD and SBFD to maintain=20 >>consistency with the current set of documents. >> 2. Motivation: It would be nice to state the requirements or=20 >>motivation that this draft addresses, i.e. what problems does this=20 >>draft address that cannot be solved using the existing BFD/ SBFD=20 >>protocol treating the VxLAN as a tunnel/ underlay transport=20 >>transparent to BFD. I would submit that BFD over VxLAN not be treated=20 >>along the same lines of BFD over MPLS or BFD for PW >> (VCCV) given the differences in the nature of the transport between=20 >>MPLS and VxLAN. >> 3. Inner Ethernet header: The document does not address the contents=20 >>of the Inner Ethernet header (present after the VxLAN header). This=20 >>needs to be specified. >> 4. Destination IP: The document mandates that this needs to be 127/8. >>What >> disadvantages do you observe if the DIP were to be the IP of the=20 >>destination VTEP? When using 127/8 as the DIP. one problem is that=20 >>there is no indication of the intended DIP of the BFD session by=20 >>using 127/8. What if the node at which the VxLAN tunnel is >>(prematurely) terminated happens to support BFD? It may be better to=20 >>use the IP address of the Destination VTEP as the DIP. >> 5. Inner TTL: For the same reasons discussed in (2), why does the=20 >>document mandate this to be set to 1? >> 6. It may be beneficial to run a spell-checker to fix typos in the=20 >>document. >> I request the authors/ WG to comment on the above aspects. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>P K >> Sent: Monday, May 04, 2015 10:55 PM >> To: rtg-bfd@ietf.org >> Subject: FW: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello All, >> A new BFD for VXLAN draft has been submitted. Please do review=20 >>and get back to us with any comments/feedback. >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, May 04, 2015 9:29 PM >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;=20 >>Basil Saji; Sudarsan Paragiri Mohan >> Subject: New Version Notification for=20 >>draft-spallagatti-bfd-vxlan-00.txt >> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >> has been successfully submitted by Santosh Pallagatti and posted to=20 >>the IETF repository. >> Name: draft-spallagatti-bfd-vxlan >> Revision: 00 >> Title: BFD for VXLAN >> Document date: 2015-05-04 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >> 00.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >> Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . Comments on this draft should be directed >> to nvo3@ietf.org. >> 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=20 >>tools.ietf.org. >> The IETF Secretariat >>=20 >>=20 >>=20 > From nobody Fri Jun 26 12:02:38 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56671B32BA; Thu, 25 Jun 2015 21:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TXzB7GOmd7Qq; Thu, 25 Jun 2015 21:37:10 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DC21AD0AF; Thu, 25 Jun 2015 21:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2680; q=dns/txt; s=iport; t=1435293431; x=1436503031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ovCbTELZVfeZUSwHPycLZ2L9wvmRPawZauQFT2VukQE=; b=gazgOe9ay/a6CusI38xyK8JyA9Q2VaEU0B14YphiRR6p3VZl9xNKGdIe qSwn7iZpc8/gPRfhv1JIXOgAIS7kLZHpTKVPbSNl6xnQaww9o+wPrA/Oz 486hCGsBshHvzKF5qevTQcTQvnZQmPg3F9oT9YVvKtmSpSwTvldm9Xrlz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BoBACP1YxV/4oNJK1bgxFUXwa9DgmBZoJEgzQCgTw4FAEBAQEBAQGBCoQjAQEEOj0CEAIBCA4KHhAyJQIEAQ0FiC8NzkkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpIgQKEGjkzB4QrAQSUBgGEV4Z6gTqTI4NcJoN6bwGBRYECAQEB X-IronPort-AV: E=Sophos;i="5.13,682,1427760000"; d="scan'208";a="162961285" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 26 Jun 2015 04:37:10 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q4b96g011052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 04:37:09 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 23:37:08 -0500 From: "Nitish Gupta (nitisgup)" To: Jeffrey Haas , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" , "maik.pfeil@gmail.com" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-00.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-00.txt Thread-Index: AQHQqaJ11FfksUpD2Ey75lsakVRjlJ25JuyAgAXJXIA= Date: Fri, 26 Jun 2015 04:37:08 +0000 Message-ID: References: <20150622174511.GB30137@pfrc.org> In-Reply-To: <20150622174511.GB30137@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.66.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2015 12:02:36 -0700 Cc: "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 04:37:11 -0000 Hi Jeff/Maik, Thanks a lot for your comments and suggestions on the draft. We have incorporated all the below comments and comments given by Maik in the latest version. URL:https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-01.txt Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-0= 1 =20 I am also including rtg-bfd@ietf.org as per your request. We are looking forward to hearing from you. Thanks, Nitish On 22/06/15 11:15 pm, "Jeffrey Haas" wrote: >Nitish, > >On Thu, Jun 18, 2015 at 08:40:42AM +0000, Nitish Gupta (nitisgup) wrote: >> Since VRRP might run in the control-plane like other routing protocols. >> It would be required that a faster failure mechanism (than its Protocol >> Hello messages) be used, and BFD serves the purpose very well. > >Depending on a router's implementation, BFD may also run in the control >plane. While not trying to be pedantic, I'd suggest that you need to >include in your use case that BFD in this proposal should NOT be >implemented >in the control plane. If both BFD and VRRP are implemented in software, >VRRP in a standalone fashion is likely more appropriate. > >> To automate this operation, this draft proposes a mechanism where the >>VRRP >> devices can learn about its peers. >> Once learnt the peers can form the BFD session automatically (point to >> point or Multipoint). > >It is a great tradition that BFD sessions can be bootstrapped through >other >protocols. This part is fine, whether it is single-hop or multipoint. > >Since BFD is capable of being dynamically boostrapped, it may be also >worth >pointing out that you can make this scale better by both provisioning >fewer >BFD sessions and also being less aggressive about your timers. > >For example, you could only bring up BFD sessions for the master and the >first likely backup for a given virtual router. The additional backups >need >not even be provisioned immediately. You could also provision the backup >to >use less aggressive timers until it becomes the master, after which you >may >have BFD adjust its interval to the more aggressive timestamp. Both of >these changes accommodates the common scaling considerations of BFD: >aggressiveness of the timers, and total number of sessions. > >> We will incorporate your points about multipoint BFD in next version of >> our draft. > >I'll look forward to it. I'd also suggest copying rtg-bfd@ietf.org for >further comment. > >-- Jeff From nobody Sat Jun 27 03:40:52 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB071B2E50 for ; Sat, 27 Jun 2015 03:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 NCD4_FopuWFM for ; Sat, 27 Jun 2015 03:40:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9773C1B2E4D for ; Sat, 27 Jun 2015 03:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17816; q=dns/txt; s=iport; t=1435401647; x=1436611247; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WArhBNNJ1k3HqfkkPsUrjn6ix6bXLTWuBsHbp4T/07Y=; b=gRGpOS5VA7SQvMH5/GFGgbsyblzHIsyYxysDZyTBzz2bXHnaEidyFU+K qmtlvwPTNd+jStyV4foZ8XD6TsPfOE/jLgFiB7oP8Gd2/c/pkkTIosybo HOa9m6H68vC/ch179IEYXReGKI7iDxYNtbw5BZKQvryBBk46cx7hBJ6bZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwBpfI5V/5NdJa1bgxFUXwa9IwmBZoV4AoEyOBQBAQEBAQEBgQqEIgEBAQMBOj0CBQcEAgEIEQMBAQEBChQJByERFAkIAgQBDQUIE4d/AwoIDchADYV0AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKgk2BbhoxBwaDEYEUAQSMEodyAYRYhRmDHUKDT4tVgz6DXSaCDByBUm+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,689,1427760000"; d="scan'208";a="163301891" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 27 Jun 2015 10:40:45 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5RAejZR027584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jun 2015 10:40:45 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sat, 27 Jun 2015 05:40:45 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "S. Davari" , Gregory Mirsky Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHag Date: Sat, 27 Jun 2015 10:40:45 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> In-Reply-To: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 10:40:51 -0000 Hello Shahram, I hope you agree to the viewpoint that BFD using the VxLAN tunnel provide= s more coverage of the datapath than just BFD of the IP tunnel without usin= g VxLAN headers. For example, the typical dataplane encapsulation and decap= sulation tables that are consulted in originating/ terminating a VxLAN pack= et are (typically) a superset of the ones used for IP datapath. Hence, ther= e is value in determining the connectivity between two VTEPs than just plai= n IP datapath connectivity. In terms of link connectivity monitoring, I agr= ee that BFD over VxLAN and BFD over IP provide the same coverage (between t= he two VTEPs), but BFD could detect more failures than the ones caused by l= ink. Agreed, that scale and the periodicity of the BFD sessions are aspects= that can be different between the two but they are different in scope as w= ell. Another point that may be of (later) interest is the interworking function = that can exist between the server and the client layers, but this may not i= mplications in the dataplane in my opinion. Thanks Prasad -----Original Message----- From: S. Davari [mailto:realestate.davari@gmail.com]=20 Sent: Saturday, June 27, 2015 1:46 AM To: Gregory Mirsky Cc: Shahram Davari; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Greg Could you please provide an example of VNI to VNI failure or degradation th= at can't be detected by the IP tunnel OAM.=20 Regards, Shahram > On Jun 26, 2015, at 11:57 AM, Gregory Mirsky wrote: >=20 > Hi Shahram, > unless monitoring of IP tunnel complemented by e2e Service-level OAM, whi= ch is even more questionable since VMs would have less HW support to OAM, a= bility to run VTEP-VTEP OAM at Service level seems as very strong requireme= nt. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Friday, June 26, 2015 11:46 AM > To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon);=20 > Santosh P K; Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Vengada, >=20 > Yes off course I differ. Please provide an example of a failure that can= only be detected by your draft and can't be detected by a BFD on the IP tu= nnel. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Friday, June 26, 2015 1:47 AM > To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory=20 > Mirsky > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hello Shahram/ BFD WG, > A few points to consider: > 1. From a layering perspective, I have the following observation to make: >> My suggestion is do BFD for the IP tunnel and you can achieve what you = want. > Equating IP connectivity between the two VTEPs purely in the underlay spa= ce may not be the same as having connectivity in the overlay space. In othe= r words, there is considerable merit in running a BFD session over the VxLA= N tunnel (using any subset of VNI(s) provisioned by the operator) than runn= ing multi-hop BFD between the VTEPs. Kindly clarify if you differ here. >=20 >=20 > 2. One more aspect that will need to be included in future versions of th= is draft (in my opinion) is the possibility of having multiple BFD sessions= between the two VTEPs. Clearly, the zero-discriminator demux followed by t= he single-hop approach may not work here, but a mechanism is needed to exer= cise the connectivity tracking of realizable ECMP paths may be very useful.= Needless to say, how these paths are discovered is outside the scope of th= e BFD specification. > Thanks > Prasad >=20 >=20 > -----Original Message----- > From: MALLIK MUDIGONDA (mmudigon) > Sent: Friday, June 26, 2015 1:02 PM > To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad=20 > Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: Re: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Shahram, >=20 > Agree that running a separate session for each VNI is not going to be sca= lable. But the current draft only allows implementations to provide such a = functionality. Implementations may choose to run a separate BFD session for= a select set of VNIs (prioritise a select few) and so we do not want to pr= eclude this possibility. We will leave it to implementations on which VNIs = require this. >=20 > May be we can rephrase the following in the draft under Section Deploymen= t to avoid confusion. >=20 > Replace this >=20 > Separate BFD sessions can be established between the VTEPs (IP1 and IP2) = for monitoring each of the VXLAN tunnels (VNI 100 and 200). >=20 >=20 > With >=20 > Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) = for monitoring each of the VXLAN tunnels (VNI 100 and 200). >=20 >=20 > Thanks >=20 > Regards > Mallik >=20 >> On 26/06/15 12:49, "Santosh P K" wrote: >>=20 >> Hello Shahram, >> Thanks a lot for your comments. Indeed "VXLAN tunnel" is=20 >> confusing, what we are trying to do here is address the requirement from= draft " >> https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement- >> 03 .tx t". Here we have a requirement for running proactive OAM=20 >> between NV edge to NV edge per VNI. This is an individual draft for=20 >> now. >>=20 >> Thanks >> Santosh P K >>=20 >>> -----Original Message----- >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Thursday, June 25, 2015 8:18 PM >>> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi);=20 >>> MALLIK MUDIGONDA (mmudigon) >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>>=20 >>> Hi Santosh, >>>=20 >>> I think you probably have misunderstood the use of OAM/BFD in general. >>> VXLAN is not a networking layer, rather it is a service=20 >>> demultiplexer (service identifier). I think the misunderstanding=20 >>> might be from the name "VXLAN tunnel". Since VXLAN is not a tunnel.=20 >>> The tunnel is actually an IP tunnel that has VXLAN as service identifi= er. >>>=20 >>> A single IP tunnel can carry many VXLANs. Not only doing BFD per=20 >>> VXLAN doesn't make sense, but it is also not scalable. My=20 >>> suggestion is do BFD for the IP tunnel and you can achieve what you wa= nt. >>>=20 >>> Thx >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>> P K >>> Sent: Monday, May 25, 2015 5:43 AM >>> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK=20 >>> MUDIGONDA (mmudigon) >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>>=20 >>> Greg, >>> Thanks a lot for your review comments. Please see my inline comments. >>>=20 >>>> you reference RFC 5880 but don't specify which of defined in BFD=20 >>>> base >>> document modes are in scope of this work. I assume that, like in RFC=20 >>> 5884, it is only Asynchronous mode and Section 7 excludes Echo BFD=20 >>> but Demand mode not mentioned. >Making >more explicit statement=20 >>> would be helpful. >>>=20 >>> Sure we can add text for Demand mode as well. >>>=20 >>>=20 >>>> section 2: >>>> I think that these three cases hardly apply to the proposed solution. >>> In >>> particular, BFD may very coarsely localize path failure as we should=20 >>> remember that path and remote peer failure are undistinguishable.=20 >>> Thus failure detected at one VM, with Tunnel >BFD session=20 >>> operational, cannot be interpreted as peer VM failure. >>>=20 >>> I am sorry I did not understand this, can you please elaborate more=20 >>> on this? >>>=20 >>>> section 3: >>>> what ensures that reverse direction of the BFD session between IP1 >>> (ingress) and IP2 (egress) , i.e. egress transmits BFD control=20 >>> packets toward the ingress, uses the same tunnel traversed by BFD=20 >>> control packets sent from ingress toward the egress? >Perhaps use=20 >>> of BFD Reverse Path TLV and BFD Discriminator TLV may be one solution? >>>=20 >>> In case of IP if reverse path has multiple paths to a destination=20 >>> then taking a particular path means IP header stacking? Correct me=20 >>> if I am wrong. >>>=20 >>>> Perhaps this section could be the right place to discuss and define >>> behavior >>> of the egress in terms of its role in BFD session: >>>> packet encapsulation; >>>> failure reporting; >>>> path selection (discussed above). >>>> And the issues of the encapsulation, reverse path selection are >>> relevant for >>> S-BFD scenario as well (I think that Prasad's suggestion to split=20 >>> into two documents, BFD and S-BFD, is quite reasonable). >>>=20 >>> If all the above point has different methods for BFD and S-BFD then=20 >>> of course we should spilt the draft in to two. >>>=20 >>>> section 6.1: >>>> considering 5884clarification work, can multiple BFD session=20 >>>> operate >>> between IP1 and IP2 over the same tunnel? >>>=20 >>> I do not see a case where we need multiple BFD session between IP=20 >>> pair when BFD session terminates at VTEP itself. >>>=20 >>>=20 >>> Thanks >>> Santosh P K >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada=20 >>> Prasad Govindan (venggovi) >>> Sent: Friday, May 08, 2015 12:39 AM >>> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>>=20 >>> Hello Santosh/ Authors, >>> Thanks for your prompt considerations of the comments submitted in=20 >>> this thread. I request you to consider the following points for discus= sion: >>> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context=20 >>> for OAM layering in NVO3. Though, an individual draft at the=20 >>> moment, I submit that we consider this for providing more context=20 >>> to the discussion here. >>> 2) Per my understanding of your proposal, the intent is to use BFD=20 >>> for OAM at the NV edge layer. Please let me know if this=20 >>> understanding is incorrect. >>> 3) The clarifications requested earlier this thread concern about=20 >>> the inner IP address (SIP in particular) of the BFD packet . Would=20 >>> they be used from the overlay IP address space (belonging to the tenan= t). >>> If this is the case, what would the difference between a BFD=20 >>> session using the tenant IP (at the NV edge), a particular VNI, and=20 >>> that of a service layer OAM session that can be run using=20 >>> single-hop BFD (RFC 5880). >>> In other words, how can the OAM (BFD in this case) operating at the=20 >>> NV Edge layer operate without using IP from the Tenant layer if the=20 >>> packet is required to be VxLAN encapsulated? >>> Thanks >>> Prasad >>>=20 >>> -----Original Message----- >>> From: Santosh P K [mailto:santoshpk@juniper.net] >>> Sent: Wednesday, May 06, 2015 3:03 PM >>> To: MALLIK MUDIGONDA (mmudigon) >>> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >>> Subject: RE: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>>=20 >>> Mallik, >>> Thanks for your review comments. >>>=20 >>>=20 >>>> 1. It is not clear if this draft is addressing both VM to VM and=20 >>>> VTEP >>> to VTEP >>> verification through BFD. I assume it is both. >>>=20 >>> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 >>> aware) >>> BFD as per RFC 5880/5881 should work as it is. VM's will not be=20 >>> aware of any tunnel. Draft talks about tunnel verification which=20 >>> terminates at VTEP's. >>>=20 >>>> 2. If the VMs are Layer 2 only, then what is the inner IP address=20 >>>> (especially source IP)? I understand that outer IP is going to=20 >>>> carry >>> the VTEPs >>> addresses. >>>=20 >>> As mentioned in the draft it would be outgoing interface IP sending=20 >>> VTEP. >>>=20 >>>> 3. Why is the inner IP destination address 127/8 or >>> 0:0:0:0:0:FFFF:7F00/104? >>> I understand that it is to avoid the packet being routed but, how=20 >>> can an IP packet addressed to a particular VTEP be consumed by any=20 >>> other node in the network and then route the inner >payload? >>>=20 >>> The same argument holds true for MPLS as well right? The motivation=20 >>> for using the address range 127/8 is the same as described in=20 >>> Section >>> 2.1 of RFC4379. >>>=20 >>>> 4. The service node's use case is not very clear. Mat be you can=20 >>>> add a >>> little >>> bit of details here. >>>=20 >>> Yes, we can do that. >>>=20 >>>> 5. I understand that VTEP knows that the packet is to be terminated=20 >>>> at >>> the >>> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >>> should be the TTL value here? Is it 255 or something different? It is >>> hardcoded to "1" in the draft. >>>=20 >>> VM's will use normal Async BFD so will use TTL 255. >>>=20 >>>> 6. Since we are using a destination UDP port of 3784, shouldn't the=20 >>>> TTL be 255 to be consistent with the RFC 5880? >>>=20 >>> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas=20 >>> UDP port number set to 3784. >>>=20 >>>=20 >>> Thanks >>> Santosh P K >>>=20 >>>=20 >>>=20 >>> From: "Vengada Prasad Govindan (venggovi)" >>> Date: Wednesday, 6 May 2015 9:39 am >>> To: Santosh P K , "rtg-bfd@ietf.org" >> bfd@ietf.org> >>> Subject: RE: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>>=20 >>> Hello Santosh/ Authors, >>> Thanks for sharing the document, please find a few thoughts below. >>> 1. The current document talks about both BFD and S-BFD - would it be=20 >>> beneficial to make separate documents for BFD and SBFD to maintain=20 >>> consistency with the current set of documents. >>> 2. Motivation: It would be nice to state the requirements or=20 >>> motivation that this draft addresses, i.e. what problems does this=20 >>> draft address that cannot be solved using the existing BFD/ SBFD=20 >>> protocol treating the VxLAN as a tunnel/ underlay transport=20 >>> transparent to BFD. I would submit that BFD over VxLAN not be=20 >>> treated along the same lines of BFD over MPLS or BFD for PW >>> (VCCV) given the differences in the nature of the transport between=20 >>> MPLS and VxLAN. >>> 3. Inner Ethernet header: The document does not address the contents=20 >>> of the Inner Ethernet header (present after the VxLAN header). This=20 >>> needs to be specified. >>> 4. Destination IP: The document mandates that this needs to be 127/8. >>> What >>> disadvantages do you observe if the DIP were to be the IP of the=20 >>> destination VTEP? When using 127/8 as the DIP. one problem is that=20 >>> there is no indication of the intended DIP of the BFD session by=20 >>> using 127/8. What if the node at which the VxLAN tunnel is >>> (prematurely) terminated happens to support BFD? It may be better=20 >>> to use the IP address of the Destination VTEP as the DIP. >>> 5. Inner TTL: For the same reasons discussed in (2), why does the=20 >>> document mandate this to be set to 1? >>> 6. It may be beneficial to run a spell-checker to fix typos in the=20 >>> document. >>> I request the authors/ WG to comment on the above aspects. >>> Thanks >>> Prasad >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >>> P K >>> Sent: Monday, May 04, 2015 10:55 PM >>> To: rtg-bfd@ietf.org >>> Subject: FW: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>>=20 >>> Hello All, >>> A new BFD for VXLAN draft has been submitted. Please do review=20 >>> and get back to us with any comments/feedback. >>>=20 >>> Thanks >>> Santosh P K >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, May 04, 2015 9:29 PM >>> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;=20 >>> Basil Saji; Sudarsan Paragiri Mohan >>> Subject: New Version Notification for=20 >>> draft-spallagatti-bfd-vxlan-00.txt >>> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >>> has been successfully submitted by Santosh Pallagatti and posted to=20 >>> the IETF repository. >>> Name: draft-spallagatti-bfd-vxlan >>> Revision: 00 >>> Title: BFD for VXLAN >>> Document date: 2015-05-04 >>> Group: Individual Submission >>> Pages: 9 >>> URL: =20 >>> https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >>> 00.txt >>> Status: =20 >>> https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >>> Htmlized: =20 >>> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >>> Abstract: >>> This document describes use of Bidirectional Forwarding Detection >>> (BFD) protocol for VXLAN . Comments on this draft should be directed >>> to nvo3@ietf.org. >>> 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=20 >>> tools.ietf.org. >>> The IETF Secretariat >=20 From nobody Sat Jun 27 06:59:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6A21A21C3 for ; Sat, 27 Jun 2015 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RnFYMFzJ5RZf for ; Sat, 27 Jun 2015 06:59:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6781A21C0 for ; Sat, 27 Jun 2015 06:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20235; q=dns/txt; s=iport; t=1435413547; x=1436623147; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s80HjdRNK38k3EDRr/46OzJiEGT/VU1oc3OF1kb3Vts=; b=af0LhsrYbbO+PxQkEZM5UGRexXhUFnW8uK+QEn1CrM6IxPl4kdij9O0y Q1HLcppXMRU4O4PjCKv9uQ/vFXbaYrhpflvGgd6XIJRleFo7Ofo/Do11Y 60i/m85zH461Dv6xaH46PCe4Lip1ADGKqSt0b/wFendozGxnFPSqXxtN7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwC4q45V/40NJK1bgxFUXwa9IwmBZoV4AoEqOBQBAQEBAQEBgQqEIgEBAQMBOj0CBQcEAgEIEQMBAQEBChQJByERFAkIAgQOBQgTh38DCggNyFYNhXQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qCTYFuGiwFBwaDEYEUAQSMEodyAYRYhRmDHUKDT4tVgz6DXSaCDByBUm+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,689,1427760000"; d="scan'208";a="163387777" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 27 Jun 2015 13:59:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5RDx50M018248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jun 2015 13:59:05 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 27 Jun 2015 08:59:05 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "S. Davari" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACBqID//7a8kA== Date: Sat, 27 Jun 2015 13:59:04 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 13:59:11 -0000 Hello Shahram, Please find a few replies inlined with GVP1>. Am glad to discuss this furth= er. Thanks Prasad -----Original Message----- From: S. Davari [mailto:realestate.davari@gmail.com]=20 Sent: Saturday, June 27, 2015 6:46 PM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; Shahram Davari; MALLIK MUDIGONDA (mmudigon); Santosh P = K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad , I don't see how you get more coverage having a VXLAN tag.=20 Since you are not testing the VXLAN based VFI/VRF forwarding. By that I mea= n you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding. GVP1> One of the aspects of the next version of the draft will have a valid= inner DIP instead of 127/8. This should help address your concern to an ex= tent. Also you are not testing the mapping from AC (Attachment Circuit) to a VXLA= N tag.=20 GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as well, = not using it as an excuse but I am just noting the precedent here. In my opinion all you are testing, is that at the other end of an IP Tunnel= a specific VXLAN exist or not. Which does not require running continuous B= FD. GVP1> There are specific use-cases (see note about Service Node reachabilit= y in Sec 2 of the draft) that require continuous monitoring of some special= -purpose VTEPs. In my opinion this is a very in efficient way of getting that information. = The controller should be able to get this information much more efficiently= .=20 It would be good if you can provide an example of what you think is more co= verage than BFD. Or at least what extra coverage do you exactly have in min= d, since this draft is not capable of more coverage than standard BFD over = the IP tunnel.=20 Regards, Shahram > On Jun 27, 2015, at 3:40 AM, Vengada Prasad Govindan (venggovi) wrote: >=20 > Hello Shahram, > I hope you agree to the viewpoint that BFD using the VxLAN tunnel provid= es more coverage of the datapath than just BFD of the IP tunnel without usi= ng VxLAN headers. For example, the typical dataplane encapsulation and deca= psulation tables that are consulted in originating/ terminating a VxLAN pac= ket are (typically) a superset of the ones used for IP datapath. Hence, the= re is value in determining the connectivity between two VTEPs than just pla= in IP datapath connectivity. In terms of link connectivity monitoring, I ag= ree that BFD over VxLAN and BFD over IP provide the same coverage (between = the two VTEPs), but BFD could detect more failures than the ones caused by = link. Agreed, that scale and the periodicity of the BFD sessions are aspect= s that can be different between the two but they are different in scope as = well. > Another point that may be of (later) interest is the interworking functio= n that can exist between the server and the client layers, but this may not= implications in the dataplane in my opinion. > Thanks > Prasad >=20 > -----Original Message----- > From: S. Davari [mailto:realestate.davari@gmail.com] > Sent: Saturday, June 27, 2015 1:46 AM > To: Gregory Mirsky > Cc: Shahram Davari; Vengada Prasad Govindan (venggovi); MALLIK=20 > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Greg >=20 > Could you please provide an example of VNI to VNI failure or degradation = that can't be detected by the IP tunnel OAM.=20 >=20 > Regards, > Shahram >=20 >=20 >> On Jun 26, 2015, at 11:57 AM, Gregory Mirsky wrote: >>=20 >> Hi Shahram, >> unless monitoring of IP tunnel complemented by e2e Service-level OAM, wh= ich is even more questionable since VMs would have less HW support to OAM, = ability to run VTEP-VTEP OAM at Service level seems as very strong requirem= ent. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, June 26, 2015 11:46 AM >> To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon);=20 >> Santosh P K; Gregory Mirsky >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >> draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Vengada, >>=20 >> Yes off course I differ. Please provide an example of a failure that ca= n only be detected by your draft and can't be detected by a BFD on the IP t= unnel. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] >> Sent: Friday, June 26, 2015 1:47 AM >> To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory=20 >> Mirsky >> Cc: rtg-bfd@ietf.org >> Subject: RE: New Version Notification for=20 >> draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hello Shahram/ BFD WG, >> A few points to consider: >> 1. From a layering perspective, I have the following observation to make= : >>> My suggestion is do BFD for the IP tunnel and you can achieve what you= want. >> Equating IP connectivity between the two VTEPs purely in the underlay sp= ace may not be the same as having connectivity in the overlay space. In oth= er words, there is considerable merit in running a BFD session over the VxL= AN tunnel (using any subset of VNI(s) provisioned by the operator) than run= ning multi-hop BFD between the VTEPs. Kindly clarify if you differ here. >>=20 >>=20 >> 2. One more aspect that will need to be included in future versions of t= his draft (in my opinion) is the possibility of having multiple BFD session= s between the two VTEPs. Clearly, the zero-discriminator demux followed by = the single-hop approach may not work here, but a mechanism is needed to exe= rcise the connectivity tracking of realizable ECMP paths may be very useful= . Needless to say, how these paths are discovered is outside the scope of t= he BFD specification. >> Thanks >> Prasad >>=20 >>=20 >> -----Original Message----- >> From: MALLIK MUDIGONDA (mmudigon) >> Sent: Friday, June 26, 2015 1:02 PM >> To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad=20 >> Govindan (venggovi) >> Cc: rtg-bfd@ietf.org >> Subject: Re: New Version Notification for=20 >> draft-spallagatti-bfd-vxlan-00.txt >>=20 >> Hi Shahram, >>=20 >> Agree that running a separate session for each VNI is not going to be sc= alable. But the current draft only allows implementations to provide such a= functionality. Implementations may choose to run a separate BFD session fo= r a select set of VNIs (prioritise a select few) and so we do not want to p= reclude this possibility. We will leave it to implementations on which VNIs= require this. >>=20 >> May be we can rephrase the following in the draft under Section Deployme= nt to avoid confusion. >>=20 >> Replace this >>=20 >> Separate BFD sessions can be established between the VTEPs (IP1 and IP2)= for monitoring each of the VXLAN tunnels (VNI 100 and 200). >>=20 >>=20 >> With >>=20 >> Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2)= for monitoring each of the VXLAN tunnels (VNI 100 and 200). >>=20 >>=20 >> Thanks >>=20 >> Regards >> Mallik >>=20 >>> On 26/06/15 12:49, "Santosh P K" wrote: >>>=20 >>> Hello Shahram, >>> Thanks a lot for your comments. Indeed "VXLAN tunnel" is=20 >>> confusing, what we are trying to do here is address the requirement fro= m draft " >>> https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement >>> - >>> 03 .tx t". Here we have a requirement for running proactive OAM=20 >>> between NV edge to NV edge per VNI. This is an individual draft for=20 >>> now. >>>=20 >>> Thanks >>> Santosh P K >>>=20 >>>> -----Original Message----- >>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>> Sent: Thursday, June 25, 2015 8:18 PM >>>> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan=20 >>>> (venggovi); MALLIK MUDIGONDA (mmudigon) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>>=20 >>>> Hi Santosh, >>>>=20 >>>> I think you probably have misunderstood the use of OAM/BFD in general. >>>> VXLAN is not a networking layer, rather it is a service=20 >>>> demultiplexer (service identifier). I think the misunderstanding=20 >>>> might be from the name "VXLAN tunnel". Since VXLAN is not a tunnel. >>>> The tunnel is actually an IP tunnel that has VXLAN as service identif= ier. >>>>=20 >>>> A single IP tunnel can carry many VXLANs. Not only doing BFD per=20 >>>> VXLAN doesn't make sense, but it is also not scalable. My=20 >>>> suggestion is do BFD for the IP tunnel and you can achieve what you w= ant. >>>>=20 >>>> Thx >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 >>>> Santosh P K >>>> Sent: Monday, May 25, 2015 5:43 AM >>>> To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK=20 >>>> MUDIGONDA (mmudigon) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>>=20 >>>> Greg, >>>> Thanks a lot for your review comments. Please see my inline comments. >>>>=20 >>>>> you reference RFC 5880 but don't specify which of defined in BFD=20 >>>>> base >>>> document modes are in scope of this work. I assume that, like in=20 >>>> RFC 5884, it is only Asynchronous mode and Section 7 excludes Echo=20 >>>> BFD but Demand mode not mentioned. >Making >more explicit=20 >>>> statement would be helpful. >>>>=20 >>>> Sure we can add text for Demand mode as well. >>>>=20 >>>>=20 >>>>> section 2: >>>>> I think that these three cases hardly apply to the proposed solution. >>>> In >>>> particular, BFD may very coarsely localize path failure as we=20 >>>> should remember that path and remote peer failure are undistinguishabl= e. >>>> Thus failure detected at one VM, with Tunnel >BFD session=20 >>>> operational, cannot be interpreted as peer VM failure. >>>>=20 >>>> I am sorry I did not understand this, can you please elaborate more=20 >>>> on this? >>>>=20 >>>>> section 3: >>>>> what ensures that reverse direction of the BFD session between IP1 >>>> (ingress) and IP2 (egress) , i.e. egress transmits BFD control=20 >>>> packets toward the ingress, uses the same tunnel traversed by BFD=20 >>>> control packets sent from ingress toward the egress? >Perhaps use=20 >>>> of BFD Reverse Path TLV and BFD Discriminator TLV may be one solution= ? >>>>=20 >>>> In case of IP if reverse path has multiple paths to a destination=20 >>>> then taking a particular path means IP header stacking? Correct me=20 >>>> if I am wrong. >>>>=20 >>>>> Perhaps this section could be the right place to discuss and=20 >>>>> define >>>> behavior >>>> of the egress in terms of its role in BFD session: >>>>> packet encapsulation; >>>>> failure reporting; >>>>> path selection (discussed above). >>>>> And the issues of the encapsulation, reverse path selection are >>>> relevant for >>>> S-BFD scenario as well (I think that Prasad's suggestion to split=20 >>>> into two documents, BFD and S-BFD, is quite reasonable). >>>>=20 >>>> If all the above point has different methods for BFD and S-BFD then=20 >>>> of course we should spilt the draft in to two. >>>>=20 >>>>> section 6.1: >>>>> considering 5884clarification work, can multiple BFD session=20 >>>>> operate >>>> between IP1 and IP2 over the same tunnel? >>>>=20 >>>> I do not see a case where we need multiple BFD session between IP=20 >>>> pair when BFD session terminates at VTEP itself. >>>>=20 >>>>=20 >>>> Thanks >>>> Santosh P K >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 >>>> Vengada Prasad Govindan (venggovi) >>>> Sent: Friday, May 08, 2015 12:39 AM >>>> To: Santosh P K; MALLIK MUDIGONDA (mmudigon) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>>=20 >>>> Hello Santosh/ Authors, >>>> Thanks for your prompt considerations of the comments submitted in=20 >>>> this thread. I request you to consider the following points for discu= ssion: >>>> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the=20 >>>> context for OAM layering in NVO3. Though, an individual draft at=20 >>>> the moment, I submit that we consider this for providing more=20 >>>> context to the discussion here. >>>> 2) Per my understanding of your proposal, the intent is to use BFD=20 >>>> for OAM at the NV edge layer. Please let me know if this=20 >>>> understanding is incorrect. >>>> 3) The clarifications requested earlier this thread concern about=20 >>>> the inner IP address (SIP in particular) of the BFD packet . Would=20 >>>> they be used from the overlay IP address space (belonging to the tena= nt). >>>> If this is the case, what would the difference between a BFD=20 >>>> session using the tenant IP (at the NV edge), a particular VNI,=20 >>>> and that of a service layer OAM session that can be run using=20 >>>> single-hop BFD (RFC 5880). >>>> In other words, how can the OAM (BFD in this case) operating at the=20 >>>> NV Edge layer operate without using IP from the Tenant layer if=20 >>>> the packet is required to be VxLAN encapsulated? >>>> Thanks >>>> Prasad >>>>=20 >>>> -----Original Message----- >>>> From: Santosh P K [mailto:santoshpk@juniper.net] >>>> Sent: Wednesday, May 06, 2015 3:03 PM >>>> To: MALLIK MUDIGONDA (mmudigon) >>>> Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org >>>> Subject: RE: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>>=20 >>>> Mallik, >>>> Thanks for your review comments. >>>>=20 >>>>=20 >>>>> 1. It is not clear if this draft is addressing both VM to VM and=20 >>>>> VTEP >>>> to VTEP >>>> verification through BFD. I assume it is both. >>>>=20 >>>> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is=20 >>>> L3 >>>> aware) >>>> BFD as per RFC 5880/5881 should work as it is. VM's will not be=20 >>>> aware of any tunnel. Draft talks about tunnel verification which=20 >>>> terminates at VTEP's. >>>>=20 >>>>> 2. If the VMs are Layer 2 only, then what is the inner IP address=20 >>>>> (especially source IP)? I understand that outer IP is going to=20 >>>>> carry >>>> the VTEPs >>>> addresses. >>>>=20 >>>> As mentioned in the draft it would be outgoing interface IP sending=20 >>>> VTEP. >>>>=20 >>>>> 3. Why is the inner IP destination address 127/8 or >>>> 0:0:0:0:0:FFFF:7F00/104? >>>> I understand that it is to avoid the packet being routed but, how=20 >>>> can an IP packet addressed to a particular VTEP be consumed by any=20 >>>> other node in the network and then route the inner >payload? >>>>=20 >>>> The same argument holds true for MPLS as well right? The motivation=20 >>>> for using the address range 127/8 is the same as described in=20 >>>> Section >>>> 2.1 of RFC4379. >>>>=20 >>>>> 4. The service node's use case is not very clear. Mat be you can=20 >>>>> add a >>>> little >>>> bit of details here. >>>>=20 >>>> Yes, we can do that. >>>>=20 >>>>> 5. I understand that VTEP knows that the packet is to be=20 >>>>> terminated at >>>> the >>>> VTEP based on TTL being 1. What about the case of VM to VM BFD? What >>>> should be the TTL value here? Is it 255 or something different? It i= s >>>> hardcoded to "1" in the draft. >>>>=20 >>>> VM's will use normal Async BFD so will use TTL 255. >>>>=20 >>>>> 6. Since we are using a destination UDP port of 3784, shouldn't=20 >>>>> the TTL be 255 to be consistent with the RFC 5880? >>>>=20 >>>> Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas=20 >>>> UDP port number set to 3784. >>>>=20 >>>>=20 >>>> Thanks >>>> Santosh P K >>>>=20 >>>>=20 >>>>=20 >>>> From: "Vengada Prasad Govindan (venggovi)" >>>> Date: Wednesday, 6 May 2015 9:39 am >>>> To: Santosh P K , "rtg-bfd@ietf.org" >>> bfd@ietf.org> >>>> Subject: RE: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>>=20 >>>> Hello Santosh/ Authors, >>>> Thanks for sharing the document, please find a few thoughts below. >>>> 1. The current document talks about both BFD and S-BFD - would it=20 >>>> be beneficial to make separate documents for BFD and SBFD to=20 >>>> maintain consistency with the current set of documents. >>>> 2. Motivation: It would be nice to state the requirements or=20 >>>> motivation that this draft addresses, i.e. what problems does this=20 >>>> draft address that cannot be solved using the existing BFD/ SBFD=20 >>>> protocol treating the VxLAN as a tunnel/ underlay transport=20 >>>> transparent to BFD. I would submit that BFD over VxLAN not be=20 >>>> treated along the same lines of BFD over MPLS or BFD for PW >>>> (VCCV) given the differences in the nature of the transport between=20 >>>> MPLS and VxLAN. >>>> 3. Inner Ethernet header: The document does not address the=20 >>>> contents of the Inner Ethernet header (present after the VxLAN=20 >>>> header). This needs to be specified. >>>> 4. Destination IP: The document mandates that this needs to be 127/8. >>>> What >>>> disadvantages do you observe if the DIP were to be the IP of the=20 >>>> destination VTEP? When using 127/8 as the DIP. one problem is that=20 >>>> there is no indication of the intended DIP of the BFD session by=20 >>>> using 127/8. What if the node at which the VxLAN tunnel is >>>> (prematurely) terminated happens to support BFD? It may be better=20 >>>> to use the IP address of the Destination VTEP as the DIP. >>>> 5. Inner TTL: For the same reasons discussed in (2), why does the=20 >>>> document mandate this to be set to 1? >>>> 6. It may be beneficial to run a spell-checker to fix typos in the=20 >>>> document. >>>> I request the authors/ WG to comment on the above aspects. >>>> Thanks >>>> Prasad >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 >>>> Santosh P K >>>> Sent: Monday, May 04, 2015 10:55 PM >>>> To: rtg-bfd@ietf.org >>>> Subject: FW: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>>=20 >>>> Hello All, >>>> A new BFD for VXLAN draft has been submitted. Please do review=20 >>>> and get back to us with any comments/feedback. >>>>=20 >>>> Thanks >>>> Santosh P K >>>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Monday, May 04, 2015 9:29 PM >>>> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;=20 >>>> Basil Saji; Sudarsan Paragiri Mohan >>>> Subject: New Version Notification for=20 >>>> draft-spallagatti-bfd-vxlan-00.txt >>>> A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt >>>> has been successfully submitted by Santosh Pallagatti and posted to=20 >>>> the IETF repository. >>>> Name: draft-spallagatti-bfd-vxlan >>>> Revision: 00 >>>> Title: BFD for VXLAN >>>> Document date: 2015-05-04 >>>> Group: Individual Submission >>>> Pages: 9 >>>> URL: =20 >>>> https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- >>>> 00.txt >>>> Status: =20 >>>> https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >>>> Htmlized: =20 >>>> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 >>>> Abstract: >>>> This document describes use of Bidirectional Forwarding Detection >>>> (BFD) protocol for VXLAN . Comments on this draft should be directed >>>> to nvo3@ietf.org. >>>> 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=20 >>>> tools.ietf.org. >>>> The IETF Secretariat >>=20 From nobody Sat Jun 27 07:53:50 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2EF1B29F3 for ; Sat, 27 Jun 2015 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 6sgEE8u52cLM for ; Sat, 27 Jun 2015 07:53:46 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id AD9B61B29F5 for ; Sat, 27 Jun 2015 07:53:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,689,1427785200"; d="scan'208";a="68681294" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 27 Jun 2015 08:51:57 -0700 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.235.1; Sat, 27 Jun 2015 07:53:46 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Sat, 27 Jun 2015 07:53:46 -0700 From: Shahram Davari To: Shahram Davari Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoA= Date: Sat, 27 Jun 2015 14:53:45 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> In-Reply-To: <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 14:53:48 -0000 Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 03:10:52 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2088A1A89B0 for ; Mon, 29 Jun 2015 03:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 rqHCH6RUOOqt for ; Mon, 29 Jun 2015 03:10:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967851A0382 for ; Mon, 29 Jun 2015 03:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1050; q=dns/txt; s=iport; t=1435572649; x=1436782249; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3PuS4Vb8p3/3VLY5KQhxQZu00YF9wfn8M7uPQozEehQ=; b=Ljg4aspMicRw7glHs/yGT98E62KusJ/JLDpo6who4VAjjzoR6uMYx0y7 7ToiPzynRPnitpZekHi/JJW5XDblERWayAZrN9d2hBRTQ4E8s7EH4NW07 me+IVSvugP3oKeI4e63PShNzqo40ST70mA0IWOI13GcpaiPsdA4/xchqG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CzAwBMGZFV/5xdJa1bgxGBMwa9GAmHXgKBLzgUAQEBAQEBAYEKhCIBAQEEOj0CDAQCAQgRBAEBCxQJBzIUCQgCBA4FCIgnxiUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qEVTEHBoMRgRQBBJQEAaQPJoN6b4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,698,1427760000"; d="scan'208";a="5482264" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jun 2015 10:10:48 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t5TAAmpF000801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 10:10:48 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 05:10:48 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Shahram Davari Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACBqID//7a8kIAAVzEAgAANToCAAn6eYA== Date: Mon, 29 Jun 2015 10:10:48 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 10:10:52 -0000 Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 06:48:59 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50951A92EF for ; Mon, 29 Jun 2015 06:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 A2Xtrjg-w9Dy for ; Mon, 29 Jun 2015 06:48:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 386051A92EE for ; Mon, 29 Jun 2015 06:48:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 55BA71E42C; Mon, 29 Jun 2015 09:50:23 -0400 (EDT) Date: Mon, 29 Jun 2015 09:50:23 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: List email etiquette and size warnings Message-ID: <20150629135023.GA8519@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 13:48:57 -0000 This is where I perilously begin to look like an old man shaking his cane at the crowd saying, "back in my day..." IETF mail runs on a fairly simple plain-text mail redirection service. Our expected content is the contents of the message. The mailer intentionally limits the size of messages. One side effect of this is that you should make sure to trim unnecessary context from your replies. I've gotten a number of these the last few days in my moderator queue: Reason: Message body is too big: 161807 bytes with a limit of 40 KB In this particular message, it was for a one-line question in the reply. Among other things, this also helps keep the list archives cleaner and easier to read. Thanks. -- Jeff From nobody Mon Jun 29 10:39:08 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80D11AD0C4 for ; Mon, 29 Jun 2015 10:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 x58W_V2-RMOk for ; Mon, 29 Jun 2015 10:39:05 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7231AD0C1 for ; Mon, 29 Jun 2015 10:39:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,371,1432623600"; d="scan'208";a="68786995" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 29 Jun 2015 11:38:23 -0700 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Jun 2015 10:39:04 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 29 Jun 2015 10:39:04 -0700 From: Shahram Davari To: "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDw Date: Mon, 29 Jun 2015 17:39:03 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 17:39:06 -0000 Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 13:51:22 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988C41B3426 for ; Mon, 29 Jun 2015 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gZ2J5CLKOX4b for ; Mon, 29 Jun 2015 13:51:08 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C468A1B3416 for ; Mon, 29 Jun 2015 13:51:08 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-2a-559154fec6c8 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E5.7B.12958.EF451955; Mon, 29 Jun 2015 16:23:58 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Mon, 29 Jun 2015 16:51:07 -0400 From: Gregory Mirsky To: Shahram Davari , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggABw5ICAAAv0AIAAAfoAgAANToCAAtWbAIAAfT2A///xLKA= Date: Mon, 29 Jun 2015 20:51:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPlO6/kImhBuc/6lus7/W0OPLqGLPF 5z/bGC2u3d3KbDHzwyZmB1aPWffPsnlM+b2R1WPJkp9MHtebrrIHsERx2aSk5mSWpRbp2yVw ZfTPeMReMEOs4szHuYwNjJ8Fuxg5OSQETCR+PX/NAmGLSVy4t56ti5GLQ0jgKKPEv3OTGCGc 5YwSi098ZwWpYhMwknixsYcdxBYRSJXY/beHFaSIWaCFUeLb+29A7RwcwgI+Ehtnc0DU+Erc frWEDcJOktjzZS6YzSKgKvGmrYkRxOYFqpm3eTYrxLKPzBIrVj4EO4lTIFzixblTYEWMQOd9 P7WGCcRmFhCXuPVkPhPE2QISS/acZ4awRSVePv7HCmErScx5fY0Zol5HYsHuT2wQtrbEsoWv mSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDYxAiPrmASb7g7GPS8t DzEKcDAq8fA++NsfKsSaWFZcmXuIUZqDRUmc1zEqL1RIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDo9RdjkU9W6r1cleeUHcWPLH19eKK/zOvFdUf3y6msfXY0vqp+ete2YUtu9i46In7ZLH7 +Qv2t2x/aXojIkPv7PO4oHMyMXbKmTZs03mTi93D/b+mbon67qW1dta/3o6MzGn8bes/vD5R c4lL+sDft56p6UZSn2pvsTa+XNvX+CPEt/TEUbOfV5RYijMSDbWYi4oTAQYSv4iNAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 20:51:12 -0000 Hi Shahram, thank you for your comments to this proposal that make the discussion so mu= ch alive. I think that processing of the VXLAN tag by VTEP before validating BFD is s= ufficient, in my view, level of verification. In VCCV BFD the PW label is n= ot used for BFD forwarding but we find it useful as Service OAM in addition= to RFC 5884, BFD over MPLS LSP. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 10:39 AM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 14:02:24 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C71B3436 for ; Mon, 29 Jun 2015 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 7nV6WQpxG859 for ; Mon, 29 Jun 2015 14:02:22 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id E150A1B341B for ; Mon, 29 Jun 2015 14:02:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,372,1432623600"; d="scan'208";a="68680982" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 29 Jun 2015 14:17:52 -0700 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.235.1; Mon, 29 Jun 2015 14:02:21 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 29 Jun 2015 14:02:21 -0700 From: Shahram Davari To: Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAA== Date: Mon, 29 Jun 2015 21:02:20 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 21:02:23 -0000 Hi Greg, You are welcome. Could you please clarify which one of the following is the= packet format: 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD Or 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? Also This is different from PW BFD, since in case of PW, there can be MS-PW= , where the LSP BFD is not end-to-end. But in this case we don't have MS-VX= LAN. So the span of the VXLAN and the IP tunnel is the same.=20 In other words you have to specify in which part of forwarding the BFD the = VXLAN Tag is used. If it is not used then it has no effect. Thx Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 1:51 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, thank you for your comments to this proposal that make the discussion so mu= ch alive. I think that processing of the VXLAN tag by VTEP before validating BFD is s= ufficient, in my view, level of verification. In VCCV BFD the PW label is n= ot used for BFD forwarding but we find it useful as Service OAM in addition= to RFC 5884, BFD over MPLS LSP. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 10:39 AM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 14:20:42 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0C1B34C4 for ; Mon, 29 Jun 2015 14:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ny6UyaZqSgm7 for ; Mon, 29 Jun 2015 14:20:35 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D221B34C7 for ; Mon, 29 Jun 2015 14:20:35 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-29-55915be4d368 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FE.3D.12958.4EB51955; Mon, 29 Jun 2015 16:53:25 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Mon, 29 Jun 2015 17:20:33 -0400 From: Gregory Mirsky To: Shahram Davari , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggABw5ICAAAv0AIAAAfoAgAANToCAAtWbAIAAfT2A///xLKCAAEegAP//wTFg Date: Mon, 29 Jun 2015 21:20:33 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPlO7T6ImhBjMWsVms7/W0OPLqGLPF 5z/bGC2u3d3KbDHzwyZmB1aPWffPsnlM+b2R1WPJkp9MHtebrrIHsERx2aSk5mSWpRbp2yVw ZVw+dZStoEu54u3/w8wNjCtkuhg5OSQETCQmn1zLCmGLSVy4t56ti5GLQ0jgKKPEjkV/WSCc 5YwSkz6tYgapYhMwknixsYcdxBYRSJXY/beHFaSIWaCFUeLb+29A7RwcwgI+Ehtnc0DU+Erc frWEDcLOk9j5YhUjiM0ioCpxYdNbMJsXqObZmx1Qy5pYJQ7cesoEkuAUCJc4uvs22HmMQOd9 P7UGLM4sIC5x68l8JoizBSSW7DnPDGGLSrx8/A/qHSWJj7/ns0PU60gs2P2JDcLWlli28DUz xGJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRUjR2lxalluupHBJkZgZB2TYNPdwbjnpeUh RgEORiUe3gd/+0OFWBPLiitzDzFKc7AoifM6RuWFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amAM3R22t7bvlv2sA5He7yPeZzxqfp541pPPViqGedFCowipvkNvrzpMfMvcWx/zrSflgGiZ 85XMWUKyIfHMfOmiD4X4aha1xcQ6votYp3u2wvNq1UsuVl41ngWsL2MVeW4eePH30LvMko/J P4qsv2/YaH+399MnRVHVZyUfz4YHKyw4k9CWdEeJpTgj0VCLuag4EQBtdEvBjQIAAA== Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 21:20:40 -0000 Hi Shahram, I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. True= , we have case of MS-PW where PW label used (that was discussed in MPLS-TP = in particular). But that doesn't mean that VCCV BFD has value only for MS-P= W and for SS-PW has no value. Would you agree? Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 2:02 PM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Greg, You are welcome. Could you please clarify which one of the following is the= packet format: 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD Or 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? Also This is different from PW BFD, since in case of PW, there can be MS-PW= , where the LSP BFD is not end-to-end. But in this case we don't have MS-VX= LAN. So the span of the VXLAN and the IP tunnel is the same.=20 In other words you have to specify in which part of forwarding the BFD the = VXLAN Tag is used. If it is not used then it has no effect. Thx Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 1:51 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, thank you for your comments to this proposal that make the discussion so mu= ch alive. I think that processing of the VXLAN tag by VTEP before validating BFD is s= ufficient, in my view, level of verification. In VCCV BFD the PW label is n= ot used for BFD forwarding but we find it useful as Service OAM in addition= to RFC 5884, BFD over MPLS LSP. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 10:39 AM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 16:15:03 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160041B2F8C for ; Mon, 29 Jun 2015 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 q0IWHe4nri5S for ; Mon, 29 Jun 2015 16:14:58 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 58C251B2F8A for ; Mon, 29 Jun 2015 16:14:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,373,1432623600"; d="scan'208";a="68814275" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 29 Jun 2015 17:14:22 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Jun 2015 16:14:55 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 29 Jun 2015 16:14:55 -0700 From: Shahram Davari To: Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAIAAfQ6A//+NGiA= Date: Mon, 29 Jun 2015 23:14:54 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 23:15:02 -0000 Hi Greg, I don't see much value in running BFD for SS-PW compared to running BFD ove= r the LSP.=20 Thx SD -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 2:21 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. True= , we have case of MS-PW where PW label used (that was discussed in MPLS-TP = in particular). But that doesn't mean that VCCV BFD has value only for MS-P= W and for SS-PW has no value. Would you agree? Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 2:02 PM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Greg, You are welcome. Could you please clarify which one of the following is the= packet format: 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD Or 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? Also This is different from PW BFD, since in case of PW, there can be MS-PW= , where the LSP BFD is not end-to-end. But in this case we don't have MS-VX= LAN. So the span of the VXLAN and the IP tunnel is the same.=20 In other words you have to specify in which part of forwarding the BFD the = VXLAN Tag is used. If it is not used then it has no effect. Thx Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 1:51 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, thank you for your comments to this proposal that make the discussion so mu= ch alive. I think that processing of the VXLAN tag by VTEP before validating BFD is s= ufficient, in my view, level of verification. In VCCV BFD the PW label is n= ot used for BFD forwarding but we find it useful as Service OAM in addition= to RFC 5884, BFD over MPLS LSP. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 10:39 AM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 16:32:57 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E011B35E1 for ; Mon, 29 Jun 2015 16:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 9Xno_miYEomf for ; Mon, 29 Jun 2015 16:32:53 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id CC4BB1B35BC for ; Mon, 29 Jun 2015 16:32:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,373,1432623600"; d="scan'208";a="68815069" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw1-out.broadcom.com with ESMTP; 29 Jun 2015 17:32:21 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Jun 2015 16:32:53 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 29 Jun 2015 16:32:53 -0700 From: Shahram Davari To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAIAAfQ6A//+NGiAAA9WOMA== Date: Mon, 29 Jun 2015 23:32:53 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 23:32:56 -0000 Hi, Another question I have is how do you forward these BFD packets from VTEP t= o VM? Since DIP =3D 127/8, I assume there is no way to forward such packets= past the VTEP. If you want to do VM to VM connectivity check then I suggest one of the fol= lowing: 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM betwee= n VMs 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over IP/UDP o= ver Ethernet over VXLAN 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: 3a) If VTEP and VMs are physically in the same CPU core then run= what you are proposing in this draft (1-hop BFD). Although it should give = you same result as running BFD over the outer IP tunnel 3b) If VTEP and VMs are physically separate (such as VTEP is in T= OR and VM is CPU core), then run something similar to what you are proposin= g but with Multi-hop DIP address so that BFD can be forwarded to VM from VT= EP. I think this draft covers just (3a) and in such case it is pretty much equi= valent of running BFD over the outer IP tunnel, since the span of both BFDs= are the same and VXLAN is not used for forwarding for BFD processing. Thx Shahram Thx Shahram -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Monday, June 29, 2015 4:15 PM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Greg, I don't see much value in running BFD for SS-PW compared to running BFD ove= r the LSP.=20 Thx SD -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 2:21 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. True= , we have case of MS-PW where PW label used (that was discussed in MPLS-TP = in particular). But that doesn't mean that VCCV BFD has value only for MS-P= W and for SS-PW has no value. Would you agree? Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 2:02 PM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Greg, You are welcome. Could you please clarify which one of the following is the= packet format: 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD Or 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? Also This is different from PW BFD, since in case of PW, there can be MS-PW= , where the LSP BFD is not end-to-end. But in this case we don't have MS-VX= LAN. So the span of the VXLAN and the IP tunnel is the same.=20 In other words you have to specify in which part of forwarding the BFD the = VXLAN Tag is used. If it is not used then it has no effect. Thx Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 1:51 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, thank you for your comments to this proposal that make the discussion so mu= ch alive. I think that processing of the VXLAN tag by VTEP before validating BFD is s= ufficient, in my view, level of verification. In VCCV BFD the PW label is n= ot used for BFD forwarding but we find it useful as Service OAM in addition= to RFC 5884, BFD over MPLS LSP. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 10:39 AM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From nobody Mon Jun 29 17:10:34 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0041B3685 for ; Mon, 29 Jun 2015 17:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FyOAuzMWeoLV for ; Mon, 29 Jun 2015 17:10:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7721B3645 for ; Mon, 29 Jun 2015 17:10:30 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-49-5591779167b3 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.71.07675.19771955; Mon, 29 Jun 2015 18:51:29 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Mon, 29 Jun 2015 20:10:28 -0400 From: Gregory Mirsky To: Shahram Davari , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggABw5ICAAAv0AIAAAfoAgAANToCAAtWbAIAAfT2A///xLKCAAEegAP//wTFggABj2QD//8vJUA== Date: Tue, 30 Jun 2015 00:10:28 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9F047E@eusaamb106.ericsson.se> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPuO7E8omhBj+emlis7/W0OPLqGLPF 5z/bGC2u3d3KbDHzwyZmB1aPWffPsnlM+b2R1WPJkp9MHtebrrIHsERx2aSk5mSWpRbp2yVw ZUy7spWpYKlWxasnHg2MC5W6GDk5JARMJOatfcoCYYtJXLi3nq2LkYtDSOAoo8S0Kx1MEM5y RonjBz+yg1SxCRhJvNjYA2aLCKRK7P7bwwpSxCzQwijx7f03oHYODmEBH4mNszkganwlbr9a wgZh10k8nNcN1ssioCqxvXUTK4jNC1Tz7uw7Fohlk9kk5u2+CVbEKRAu8fpjLxOIzQh03vdT a8BsZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIep1JBbs/sQGYWtLLFv4mhli saDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyipGjtDi1LDfdyHATIzCujkmwOe5gXPDJ8hCj AAejEg/vg7/9oUKsiWXFlbmHGKU5WJTEeaX98kKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MKrLOV+bdOWxnNkuo0eKC5sufVV8xRS44ZFH87awFXfe7uj6rhC2cI0I448chs332Qz4mE72 HZRsfpn+hcWZr2bJ9y+6fP/V14dtNXAXWcyW0ryCTUHhcFrjyY2n/rZ3nJrM/nFXU7WA4DH2 okPHDprNZTbvT5T+zMrvudNAzy6se0LWErPfrEosxRmJhlrMRcWJAA0eRIOMAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 00:10:33 -0000 Hi Shahram, that may or may not be the case for the proposal we're discussing. I think = that operators and time will tell us. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 4:15 PM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Greg, I don't see much value in running BFD for SS-PW compared to running BFD ove= r the LSP.=20 Thx SD -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 2:21 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. True= , we have case of MS-PW where PW label used (that was discussed in MPLS-TP = in particular). But that doesn't mean that VCCV BFD has value only for MS-P= W and for SS-PW has no value. Would you agree? Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 2:02 PM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Greg, You are welcome. Could you please clarify which one of the following is the= packet format: 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD Or 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? Also This is different from PW BFD, since in case of PW, there can be MS-PW= , where the LSP BFD is not end-to-end. But in this case we don't have MS-VX= LAN. So the span of the VXLAN and the IP tunnel is the same.=20 In other words you have to specify in which part of forwarding the BFD the = VXLAN Tag is used. If it is not used then it has no effect. Thx Shahram -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, June 29, 2015 1:51 PM To: Shahram Davari; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Shahram, thank you for your comments to this proposal that make the discussion so mu= ch alive. I think that processing of the VXLAN tag by VTEP before validating BFD is s= ufficient, in my view, level of verification. In VCCV BFD the PW label is n= ot used for BFD forwarding but we find it useful as Service OAM in addition= to RFC 5884, BFD over MPLS LSP. Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Monday, June 29, 2015 10:39 AM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad, Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since sta= ndard BFD processing does no care where the BFD came from it only looks at = "your discriminator" to update BFD state machine. Also I don't see how many VXLANs can be checked via a single BFD session. C= ould you please describe? Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should= not require BFD. Just use some query mechanism. Why do you need to run con= tinuous BFD. What you have to show me to convince me that your draft solves a real probl= em is to show that VXLAN tag is used for BFD forwarding. Otherwise BFD ov= er the outer or Inner IP should give you all coverage needed. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Monday, June 29, 2015 3:11 AM To: Shahram Davari Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.= org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hello Shahram, At the terminating VTEP, VxLAN information is used to consume the BFD pac= ket. In other words, a BFD session increases the confidence of the existenc= e of the VNI-Forwarding Domain mapping and the presence of valid VTEP termi= nation configuration at the terminating VTEP. At the originating VTEP, it i= s a matter of implementation of how many VxLAN tables are exercised in the = datapath (am aware of at least one implementation where it is being exercis= ed to a considerable extent). Thanks Prasad -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Saturday, June 27, 2015 8:24 PM To: Shahram Davari Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK MUDIGONDA (m= mudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi May be a better way to make this clear is to answer the following question: Where is the VXLAN tag information used in this BFD forwarding?=20 Thx Shahram=20 From realestate.davari@gmail.com Sun Jun 28 22:18:30 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC901B323C for ; Sun, 28 Jun 2015 22:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 sugnybr6J2Cb for ; Sun, 28 Jun 2015 22:18:29 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA7E1B3237 for ; Sun, 28 Jun 2015 22:18:29 -0700 (PDT) Received: by paceq1 with SMTP id eq1so99010536pac.3 for ; Sun, 28 Jun 2015 22:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:content-type:mime-version:subject :message-id:date:references:to:in-reply-to; bh=6HxmBIRph4WuFR1fY9YDnGHBhgPvRQEcEhVv82hgCWo=; b=xR6oGn4T2ekwoDt4RCxHtEUP9TCXXyrpSdj13JBnkyhOe1x4ABFyZPTNdMSQO2yuQk 0uif/ENKZ0I7CsHZhdh7NcBU3k7V2LlN29edpEYNRWSc3KytNRYMPlvgUsMzxXHjrJKy ygsJeLSx64vJKziEYnTaHWMBs5AFRfB3qBlHzILkDGQ8ToVlm5rJnEZjTbvQGE3yFAZV NXP+GMfSDw71NqadndSrPh/MFhgsP+gpBEQIdUdjnjmrNwrkvuwFMd3LQXRp0yWm6BG1 VZS3ELbkSI73TcZLKK16uCGiGFitUTEDibRpnceTZeQXa15//Z80/4IwWIxOYO5rwClS doQA== X-Received: by 10.68.203.197 with SMTP id ks5mr28160702pbc.51.1435555108880; Sun, 28 Jun 2015 22:18:28 -0700 (PDT) Received: from ?IPv6:2602:306:ccab:b70:6cfe:efab:6e1c:4daa? ([2602:306:ccab:b70:6cfe:efab:6e1c:4daa]) by mx.google.com with ESMTPSA id de2sm40740503pdb.15.2015.06.28.22.18.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jun 2015 22:18:27 -0700 (PDT) Content-Transfer-Encoding: 7bit From: "S. Davari" Content-Type: multipart/alternative; boundary=Apple-Mail-9B196796-0271-41CC-A160-FBE1EB560F4A Mime-Version: 1.0 (1.0) Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Message-Id: Date: Sun, 28 Jun 2015 22:18:25 -0700 References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> To: Shahram Davari , rtg-bfd@ietf.org In-Reply-To: <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> X-Mailer: iPhone Mail (12B440) Archived-At: X-Mailman-Approved-At: Mon, 29 Jun 2015 18:45:29 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 05:30:13 -0000 --Apple-Mail-9B196796-0271-41CC-A160-FBE1EB560F4A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi What is a service node? Thx Sd > Hi Prasad , >=20 > I don't see how you get more coverage having a VXLAN tag.=20 >=20 > Since you are not testing the VXLAN based VFI/VRF forwarding. By that I me= an you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding. > GVP1> One of the aspects of the next version of the draft will have a vali= d inner DIP instead of 127/8. This should help address your concern to an ex= tent. > Also you are not testing the mapping from AC (Attachment Circuit) to a VXL= AN tag.=20 > GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as well,= not using it as an excuse but I am just noting the precedent here. >=20 > In my opinion all you are testing, is that at the other end of an IP Tunne= l a specific VXLAN exist or not. Which does not require running continuous B= FD. > GVP1> There are specific use-cases (see note about Service Node reachabili= ty in Sec 2 of the draft) that require continuous monitoring of some special= -purpose VTEPs. >=20 > In my opinion this is a very in efficient way of getting that information.= The controller should be able to get this information much more efficiently= .=20 >=20 > It would be good if you can provide an example of what you think is more c= overage than BFD. Or at least what extra coverage do you exactly have in min= d, since this draft is not capable of more coverage than standard BFD over t= he IP tunnel.=20 >=20 > Regards, > Shahram Regards, Shahram > On Jun 27, 2015, at 7:06 AM, Shahram Davari wrote: >=20 > Hi Prasad , >=20 > I don't see how you get more coverage having a VXLAN tag.=20 >=20 > Since you are not testing the VXLAN based VFI/VRF forwarding. By that I me= an you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding. > GVP1> One of the aspects of the next version of the draft will have a vali= d inner DIP instead of 127/8. This should help address your concern to an ex= tent. > Also you are not testing the mapping from AC (Attachment Circuit) to a VXL= AN tag.=20 > GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as well,= not using it as an excuse but I am just noting the precedent here. >=20 > In my opinion all you are testing, is that at the other end of an IP Tunne= l a specific VXLAN exist or not. Which does not require running continuous B= FD. > GVP1> There are specific use-cases (see note about Service Node reachabili= ty in Sec 2 of the draft) that require continuous monitoring of some special= -purpose VTEPs. >=20 > In my opinion this is a very in efficient way of getting that information.= The controller should be able to get this information much more efficiently= .=20 >=20 > It would be good if you can provide an example of what you think is more c= overage than BFD. Or at least what extra coverage do you exactly have in min= d, since this draft is not capable of more coverage than standard BFD over t= he IP tunnel.=20 >=20 > Regards, > Shahram --Apple-Mail-9B196796-0271-41CC-A160-FBE1EB560F4A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi

What is a s= ervice node?

Thx

Sd
<= div>

Hi Prasad ,=

I don't see how you get more coverage having a VXLAN tag. 
<= br>Since you are not testing the VXLAN based VFI/VRF forwarding. By that I m= ean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding.
GVP1>= One of the aspects of the next version of the draft will have a valid inner= DIP instead of 127/8. This should help address your concern to an extent.Also you are not testing the mapping from AC (Attachment Circuit) to a VXL= AN tag. 
GVP1> Agreed, this aspect has not (yet) been addressed b= y RFC5884 as well, not using it as an excuse but I am just noting the preced= ent here.

In my opinion all you are testing, is that at the other end= of an IP Tunnel a specific VXLAN exist or not. Which does not require runni= ng continuous BFD.
GVP1> There are specific use-cases (see note about S= ervice Node reachability in Sec 2 of the draft) that require continuous moni= toring of some special-purpose VTEPs.

In my opinion this is a very in= efficient way of getting that information. The controller should be able to= get this information much more efficiently. 

It would be good i= f you can provide an example of what you think is more coverage than BFD. Or= at least what extra coverage do you exactly have in mind, since this draft i= s not capable of more coverage than standard BFD over the IP tunnel. 
Regards,
Shahram
Regards,
Shahram=


On Jun 27, 2015, at 7:06 AM, Shahram Dav= ari <davari@broadcom.com> w= rote:

Hi Prasad ,

I don't see how you get more coverage having a VXLAN tag.

Since you are not testing the VXLAN based VFI/VRF forwarding. By that I= mean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding. GVP1> One of the aspects of the next version of the draft will have= a valid inner DIP instead of 127/8. This should help address your concern t= o an extent.
Also you are not testing the mapping from AC (Attachment Circuit) to a= VXLAN tag.
GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 a= s well, not using it as an excuse but I am just noting the precedent here.

In my opinion all you are testing, is that at the other end of an IP T= unnel a specific VXLAN exist or not. Which does not require running continuo= us BFD.
GVP1> There are specific use-cases (see note about Service Node rea= chability in Sec 2 of the draft) that require continuous monitoring of some s= pecial-purpose VTEPs.

In my opinion this is a very in efficient way of getting that informat= ion. The controller should be able to get this information much more efficie= ntly.

It would be good if you can provide an example of what you think is mo= re coverage than BFD. Or at least what extra coverage do you exactly have in= mind, since this draft is not capable of more coverage than standard BFD ov= er the IP tunnel.

Regards,
Shahram
= --Apple-Mail-9B196796-0271-41CC-A160-FBE1EB560F4A-- From nobody Mon Jun 29 18:45:32 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081241A89B8 for ; Mon, 29 Jun 2015 03:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 neU53wXpoxtV for ; Mon, 29 Jun 2015 03:12:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F08E1A0382 for ; Mon, 29 Jun 2015 03:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=166390; q=dns/txt; s=iport; t=1435572719; x=1436782319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UP5Q+hRuAnbIb/vQjBrAWuM83K82wfmC0ho650kbvOc=; b=KIIQrkc6XGxaKTa/N+9bIzBSK+ZBQ4WpEpiZ18Bhx5s5WRr7Z6wlfMvG l4/de7V+0Ky4hLT2d9Ovk/wLTsN8sLNW6YNLNwHN18oPmqMkgGADzJPDu 18EE9zlYWxxmc1p+5pv5WRQisBnoDyI4Hix6WKubddxKoL2gKKW1kS8Mu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBwAgGZFV/51dJa1bgkVMVF8GvG4zgWaFeAKBLzkTAQEBAQEBAYEKhCIBAQEEGgESSgIMBAIBCBEDAQEBCxYBBgchERQJCAIEDgUIE4d/AxINwBcNhXQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qCTYFuGiAMAQQGAQYDgw6BFAWMEoUVgl0BhFiFGYMdQoNPi1WDPoNdERWCDByBUm+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,698,1427760000"; d="scan'208,217";a="163682666" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 29 Jun 2015 10:11:57 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5TABvwZ020822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 10:11:57 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 05:11:57 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Shahram Davari Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACBqID//7a8kIAAVzEAgAKPHtA= Date: Mon, 29 Jun 2015 10:11:57 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5457F748@xmb-rcd-x15.cisco.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> , <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> In-Reply-To: <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.217] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D5457F748xmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 29 Jun 2015 18:45:29 -0700 Cc: "rtg-bfd@ietf.org" , "S. Davari" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 10:12:07 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D5457F748xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By the definition of this draft, a service node is a VTEP designated to per= form certain special functionality e.g. handling BUM traffic. Thanks Prasad From: Shahram Davari [mailto:davari@broadcom.com] Sent: Saturday, June 27, 2015 7:36 PM To: Vengada Prasad Govindan (venggovi) Cc: S. Davari; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rt= g-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t What is a service node? Regards, Shahram On Jun 27, 2015, at 6:59 AM, Vengada Prasad Govindan (venggovi) > wrote: Hello Shahram, Please find a few replies inlined with GVP1>. Am glad to discuss this furth= er. Thanks Prasad -----Original Message----- From: S. Davari [mailto:realestate.davari@gmail.com] Sent: Saturday, June 27, 2015 6:46 PM To: Vengada Prasad Govindan (venggovi) Cc: Gregory Mirsky; Shahram Davari; MALLIK MUDIGONDA (mmudigon); Santosh P = K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Hi Prasad , I don't see how you get more coverage having a VXLAN tag. Since you are not testing the VXLAN based VFI/VRF forwarding. By that I mea= n you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding. GVP1> One of the aspects of the next version of the draft will have a valid= inner DIP instead of 127/8. This should help address your concern to an ex= tent. Also you are not testing the mapping from AC (Attachment Circuit) to a VXLA= N tag. GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as well, = not using it as an excuse but I am just noting the precedent here. In my opinion all you are testing, is that at the other end of an IP Tunnel= a specific VXLAN exist or not. Which does not require running continuous B= FD. GVP1> There are specific use-cases (see note about Service Node reachabilit= y in Sec 2 of the draft) that require continuous monitoring of some special= -purpose VTEPs. In my opinion this is a very in efficient way of getting that information. = The controller should be able to get this information much more efficiently= . It would be good if you can provide an example of what you think is more co= verage than BFD. Or at least what extra coverage do you exactly have in min= d, since this draft is not capable of more coverage than standard BFD over = the IP tunnel. Regards, Shahram On Jun 27, 2015, at 3:40 AM, Vengada Prasad Govindan (venggovi) > wrote: Hello Shahram, I hope you agree to the viewpoint that BFD using the VxLAN tunnel provides = more coverage of the datapath than just BFD of the IP tunnel without using = VxLAN headers. For example, the typical dataplane encapsulation and decapsu= lation tables that are consulted in originating/ terminating a VxLAN packet= are (typically) a superset of the ones used for IP datapath. Hence, there = is value in determining the connectivity between two VTEPs than just plain = IP datapath connectivity. In terms of link connectivity monitoring, I agree= that BFD over VxLAN and BFD over IP provide the same coverage (between the= two VTEPs), but BFD could detect more failures than the ones caused by lin= k. Agreed, that scale and the periodicity of the BFD sessions are aspects t= hat can be different between the two but they are different in scope as wel= l. Another point that may be of (later) interest is the interworking function = that can exist between the server and the client layers, but this may not i= mplications in the dataplane in my opinion. Thanks Prasad -----Original Message----- From: S. Davari [mailto:realestate.davari@gmail.com] Sent: Saturday, June 27, 2015 1:46 AM To: Gregory Mirsky Cc: Shahram Davari; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Greg Could you please provide an example of VNI to VNI failure or degradation th= at can't be detected by the IP tunnel OAM. Regards, Shahram On Jun 26, 2015, at 11:57 AM, Gregory Mirsky > wrote: Hi Shahram, unless monitoring of IP tunnel complemented by e2e Service-level OAM, which= is even more questionable since VMs would have less HW support to OAM, abi= lity to run VTEP-VTEP OAM at Service level seems as very strong requirement= . Regards, Greg -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, June 26, 2015 11:46 AM To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Santosh P K; Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hi Vengada, Yes off course I differ. Please provide an example of a failure that can o= nly be detected by your draft and can't be detected by a BFD on the IP tunn= el. Thx Shahram -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] Sent: Friday, June 26, 2015 1:47 AM To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hello Shahram/ BFD WG, A few points to consider: 1. From a layering perspective, I have the following observation to make: My suggestion is do BFD for the IP tunnel and you can achieve what you wan= t. Equating IP connectivity between the two VTEPs purely in the underlay space= may not be the same as having connectivity in the overlay space. In other = words, there is considerable merit in running a BFD session over the VxLAN = tunnel (using any subset of VNI(s) provisioned by the operator) than runnin= g multi-hop BFD between the VTEPs. Kindly clarify if you differ here. 2. One more aspect that will need to be included in future versions of this= draft (in my opinion) is the possibility of having multiple BFD sessions b= etween the two VTEPs. Clearly, the zero-discriminator demux followed by the= single-hop approach may not work here, but a mechanism is needed to exerci= se the connectivity tracking of realizable ECMP paths may be very useful. N= eedless to say, how these paths are discovered is outside the scope of the = BFD specification. Thanks Prasad -----Original Message----- From: MALLIK MUDIGONDA (mmudigon) Sent: Friday, June 26, 2015 1:02 PM To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hi Shahram, Agree that running a separate session for each VNI is not going to be scala= ble. But the current draft only allows implementations to provide such a fu= nctionality. Implementations may choose to run a separate BFD session for a= select set of VNIs (prioritise a select few) and so we do not want to prec= lude this possibility. We will leave it to implementations on which VNIs re= quire this. May be we can rephrase the following in the draft under Section Deployment = to avoid confusion. Replace this Separate BFD sessions can be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). With Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) fo= r monitoring each of the VXLAN tunnels (VNI 100 and 200). Thanks Regards Mallik On 26/06/15 12:49, "Santosh P K" > wrote: Hello Shahram, Thanks a lot for your comments. Indeed "VXLAN tunnel" is confusing, what we are trying to do here is address the requirement from dr= aft " https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement - 03 .tx t". Here we have a requirement for running proactive OAM between NV edge to NV edge per VNI. This is an individual draft for now. Thanks Santosh P K -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Thursday, June 25, 2015 8:18 PM To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hi Santosh, I think you probably have misunderstood the use of OAM/BFD in general. VXLAN is not a networking layer, rather it is a service demultiplexer (service identifier). I think the misunderstanding might be from the name "VXLAN tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP tunnel that has VXLAN as service identifier. A single IP tunnel can carry many VXLANs. Not only doing BFD per VXLAN doesn't make sense, but it is also not scalable. My suggestion is do BFD for the IP tunnel and you can achieve what you want. Thx Shahram -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, May 25, 2015 5:43 AM To: Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Greg, Thanks a lot for your review comments. Please see my inline comments. you reference RFC 5880 but don't specify which of defined in BFD base document modes are in scope of this work. I assume that, like in RFC 5884, it is only Asynchronous mode and Section 7 excludes Echo BFD but Demand mode not mentioned. >Making >more explicit statement would be helpful. Sure we can add text for Demand mode as well. section 2: I think that these three cases hardly apply to the proposed solution. In particular, BFD may very coarsely localize path failure as we should remember that path and remote peer failure are undistinguishable. Thus failure detected at one VM, with Tunnel >BFD session operational, cannot be interpreted as peer VM failure. I am sorry I did not understand this, can you please elaborate more on this? section 3: what ensures that reverse direction of the BFD session between IP1 (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets toward the ingress, uses the same tunnel traversed by BFD control packets sent from ingress toward the egress? >Perhaps use of BFD Reverse Path TLV and BFD Discriminator TLV may be one solution? In case of IP if reverse path has multiple paths to a destination then taking a particular path means IP header stacking? Correct me if I am wrong. Perhaps this section could be the right place to discuss and define behavior of the egress in terms of its role in BFD session: packet encapsulation; failure reporting; path selection (discussed above). And the issues of the encapsulation, reverse path selection are relevant for S-BFD scenario as well (I think that Prasad's suggestion to split into two documents, BFD and S-BFD, is quite reasonable). If all the above point has different methods for BFD and S-BFD then of course we should spilt the draft in to two. section 6.1: considering 5884clarification work, can multiple BFD session operate between IP1 and IP2 over the same tunnel? I do not see a case where we need multiple BFD session between IP pair when BFD session terminates at VTEP itself. Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada Prasad Govindan (venggovi) Sent: Friday, May 08, 2015 12:39 AM To: Santosh P K; MALLIK MUDIGONDA (mmudigon) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hello Santosh/ Authors, Thanks for your prompt considerations of the comments submitted in this thread. I request you to consider the following points for discussion= : 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for OAM layering in NVO3. Though, an individual draft at the moment, I submit that we consider this for providing more context to the discussion here. 2) Per my understanding of your proposal, the intent is to use BFD for OAM at the NV edge layer. Please let me know if this understanding is incorrect. 3) The clarifications requested earlier this thread concern about the inner IP address (SIP in particular) of the BFD packet . Would they be used from the overlay IP address space (belonging to the tenant). If this is the case, what would the difference between a BFD session using the tenant IP (at the NV edge), a particular VNI, and that of a service layer OAM session that can be run using single-hop BFD (RFC 5880). In other words, how can the OAM (BFD in this case) operating at the NV Edge layer operate without using IP from the Tenant layer if the packet is required to be VxLAN encapsulated? Thanks Prasad -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Wednesday, May 06, 2015 3:03 PM To: MALLIK MUDIGONDA (mmudigon) Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Mallik, Thanks for your review comments. 1. It is not clear if this draft is addressing both VM to VM and VTEP to VTEP verification through BFD. I assume it is both. Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 aware) BFD as per RFC 5880/5881 should work as it is. VM's will not be aware of any tunnel. Draft talks about tunnel verification which terminates at VTEP's. 2. If the VMs are Layer 2 only, then what is the inner IP address (especially source IP)? I understand that outer IP is going to carry the VTEPs addresses. As mentioned in the draft it would be outgoing interface IP sending VTEP. 3. Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/104? I understand that it is to avoid the packet being routed but, how can an IP packet addressed to a particular VTEP be consumed by any other node in the network and then route the inner >payload? The same argument holds true for MPLS as well right? The motivation for using the address range 127/8 is the same as described in Section 2.1 of RFC4379. 4. The service node's use case is not very clear. Mat be you can add a little bit of details here. Yes, we can do that. 5. I understand that VTEP knows that the packet is to be terminated at the VTEP based on TTL being 1. What about the case of VM to VM BFD? What should be the TTL value here? Is it 255 or something different? It is hardcoded to "1" in the draft. VM's will use normal Async BFD so will use TTL 255. 6. Since we are using a destination UDP port of 3784, shouldn't the TTL be 255 to be consistent with the RFC 5880? Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP port number set to 3784. Thanks Santosh P K From: "Vengada Prasad Govindan (venggovi)" > Date: Wednesday, 6 May 2015 9:39 am To: Santosh P K >, "rtg= -bfd@ietf.org" > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hello Santosh/ Authors, Thanks for sharing the document, please find a few thoughts below. 1. The current document talks about both BFD and S-BFD - would it be beneficial to make separate documents for BFD and SBFD to maintain consistency with the current set of documents. 2. Motivation: It would be nice to state the requirements or motivation that this draft addresses, i.e. what problems does this draft address that cannot be solved using the existing BFD/ SBFD protocol treating the VxLAN as a tunnel/ underlay transport transparent to BFD. I would submit that BFD over VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW (VCCV) given the differences in the nature of the transport between MPLS and VxLAN. 3. Inner Ethernet header: The document does not address the contents of the Inner Ethernet header (present after the VxLAN header). This needs to be specified. 4. Destination IP: The document mandates that this needs to be 127/8. What disadvantages do you observe if the DIP were to be the IP of the destination VTEP? When using 127/8 as the DIP. one problem is that there is no indication of the intended DIP of the BFD session by using 127/8. What if the node at which the VxLAN tunnel is (prematurely) terminated happens to support BFD? It may be better to use the IP address of the Destination VTEP as the DIP. 5. Inner TTL: For the same reasons discussed in (2), why does the document mandate this to be set to 1? 6. It may be beneficial to run a spell-checker to fix typos in the document. I request the authors/ WG to comment on the above aspects. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, May 04, 2015 10:55 PM To: rtg-bfd@ietf.org Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Hello All, A new BFD for VXLAN draft has been submitted. Please do review and get back to us with any comments/feedback. Thanks Santosh P K -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, May 04, 2015 9:29 PM To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; Basil Saji; Sudarsan Paragiri Mohan Subject: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt has been successfully submitted by Santosh Pallagatti and posted to the IETF repository. Name: draft-spallagatti-bfd-vxlan Revision: 00 Title: BFD for VXLAN Document date: 2015-05-04 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan- 00.txt Status: https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00 Abstract: This document describes use of Bidirectional Forwarding Detection (BFD) protocol for VXLAN . Comments on this draft should be directed to nvo3@ietf.org. 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. The IETF Secretariat --_000_315041E4211CB84E86EF7C25A2AB583D5457F748xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

By the definition of this draft, a se= rvice node is a VTEP designated to perform certain special functionality e.= g. handling BUM traffic.

Thanks
Prasad

 

From: Shahram Davari [mailto:davari@= broadcom.com]
Sent: Saturday, June 27, 2015 7:36 PM
To: Vengada Prasad Govindan (venggovi)
Cc: S. Davari; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh = P K; rtg-bfd@ietf.org
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxla= n-00.txt

 

What is a service node?


Regards,

Shahram

 

 

On Jun 27, 2015, at 6= :59 AM, Vengada Prasad Govindan (venggovi) <venggovi@cisco.com> wrote:

Hello Shahram,
Please find a few replies inlined with GVP1>. Am glad to discuss this fu= rther.
Thanks
Prasad

-----Original Message-----
From: S. Davari [mailto:real= estate.davari@gmail.com]
Sent: Saturday, June 27, 2015 6:46 PM
To: Vengada Prasad Govindan (venggovi)
Cc: Gregory Mirsky; Shahram Davari; MALLIK MUDIGONDA (mmudigon); Santosh P = K; rtg-bfd@ietf.org
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t

Hi Prasad ,

I don't see how you get more coverage having a VXLAN tag.

Since you are not testing the VXLAN based VFI/VRF forwarding. By that I mea= n you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding.
GVP1> One of the aspects of the next version of the draft will have a va= lid inner DIP instead of 127/8. This should help address your concern to an= extent.
Also you are not testing the mapping from AC (Attachment Circuit) to a VXLA= N tag.
GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as wel= l, not using it as an excuse but I am just noting the precedent here.

In my opinion all you are testing, is that at the other end of an IP Tunnel= a specific VXLAN exist or not. Which does not require running continuous B= FD.
GVP1> There are specific use-cases (see note about Service Node reachabi= lity in Sec 2 of the draft) that require continuous monitoring of some spec= ial-purpose VTEPs.

In my opinion this is a very in efficient way of getting that information. = The controller should be able to get this information much more efficiently= .

It would be good if you can provide an example of what you think is more co= verage than BFD. Or at least what extra coverage do you exactly have in min= d, since this draft is not capable of more coverage than standard BFD over = the IP tunnel.

Regards,
Shahram



On Jun 27, 2015, at 3:40 AM, Vengada Prasad Govindan= (venggovi) <venggovi@cisco.com> wrote:

 

Hello Shahram,

I hope you agree to the viewpoint that BFD using the= VxLAN tunnel provides more coverage of the datapath than just BFD of the I= P tunnel without using VxLAN headers. For example, the typical dataplane en= capsulation and decapsulation tables that are consulted in originating/ terminating a VxLAN packet are (typical= ly) a superset of the ones used for IP datapath. Hence, there is value in d= etermining the connectivity between two VTEPs than just plain IP datapath c= onnectivity. In terms of link connectivity monitoring, I agree that BFD over VxLAN and BFD over IP provide the same c= overage (between the two VTEPs), but BFD could detect more failures than th= e ones caused by link. Agreed, that scale and the periodicity of the BFD se= ssions are aspects that can be different between the two but they are different in scope as well.

Another point that may be of (later) interest is the= interworking function that can exist between the server and the client lay= ers, but this may not implications in the dataplane in my opinion.

Thanks

Prasad

 

-----Original Message-----

From: S. Davari [mailto:realestate.davari@gmail.com]

Sent: Saturday, June 27, 2015 1:46 AM

To: Gregory Mirsky

Cc: Shahram Davari; Vengada Prasad Govindan (venggov= i); MALLIK

MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org

Subject: Re: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Greg

 

Could you please provide an example of VNI to VNI fa= ilure or degradation that can't be detected by the IP tunnel OAM.

 

Regards,

Shahram

 

 

On Jun 26, 2015, at 11:57 AM, Gregory Mirsky <gregory.mirsky@ericsson.com= > wrote:

 

Hi Shahram,

unless monitoring of IP tunnel complemented by e2e S= ervice-level OAM, which is even more questionable since VMs would have less= HW support to OAM, ability to run VTEP-VTEP OAM at Service level seems as = very strong requirement.

 

 Regards,

     Greg

 

-----Original Message-----

From: Shahram Davari [mailto:davari@broadcom.com]

Sent: Friday, June 26, 2015 11:46 AM

To: Vengada Prasad Govindan (venggovi); MALLIK MUDIG= ONDA (mmudigon);

Santosh P K; Gregory Mirsky

Cc: rtg-bfd@ietf= .org

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hi Vengada,

 

Yes off course I differ.  Please provide an exa= mple of a failure that can only be detected by your draft and can't be dete= cted by a BFD on the IP tunnel.

 

Thx

Shahram

 

-----Original Message-----

From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]

Sent: Friday, June 26, 2015 1:47 AM

To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahra= m Davari; Gregory

Mirsky

Cc: rtg-bfd@ietf= .org

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hello Shahram/ BFD WG,

A few points to consider:

1. From a layering perspective, I have the following= observation to make:

My suggestion is do BFD for  the IP tunnel and = you can achieve what you want.

Equating IP connectivity between the two VTEPs purel= y in the underlay space may not be the same as having connectivity in the o= verlay space. In other words, there is considerable merit in running a BFD = session over the VxLAN tunnel (using any subset of VNI(s) provisioned by the operator) than running multi-hop B= FD between the VTEPs. Kindly clarify if you differ here.

 

 

2. One more aspect that will need to be included in = future versions of this draft (in my opinion) is the possibility of having = multiple BFD sessions between the two VTEPs. Clearly, the zero-discriminato= r demux followed by the single-hop approach may not work here, but a mechanism is needed to exercise the conn= ectivity tracking of realizable ECMP paths may be very useful. Needless to = say, how these paths are discovered is outside the scope of the BFD specifi= cation.

Thanks

Prasad

 

 

-----Original Message-----

From: MALLIK MUDIGONDA (mmudigon)

Sent: Friday, June 26, 2015 1:02 PM

To: Santosh P K; Shahram Davari; Gregory Mirsky; Ven= gada Prasad

Govindan (venggovi)

Cc: rtg-bfd@ietf= .org

Subject: Re: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hi Shahram,

 

Agree that running a separate session for each VNI i= s not going to be scalable. But the current draft only allows implementatio= ns to provide such a functionality. Implementations may choose to run a sep= arate BFD session for a select set of VNIs (prioritise a select few) and so we do not want to preclude this p= ossibility. We will leave it to implementations on which VNIs require this.=

 

May be we can rephrase the following in the draft un= der Section Deployment to avoid confusion.

 

Replace this

 

Separate BFD sessions can be established between the= VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and = 200).

 

 

With

 

Separate BFD sessions MAY be established between the= VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and = 200).

 

 

Thanks

 

Regards

Mallik

 

On 26/06/15 12:49, "Santosh P K" <santoshpk@juniper.net> wrote:

 

Hello Shahram,

Thanks a lot for your comments. Indeed "VXLAN t= unnel"  is

confusing, what we are trying to do here is address = the requirement from draft "

https://tools.ietf.org/id/draft-ashwood-nvo3-o= perational-requirement

-

03 .tx t". Here we have a requirement for runni= ng proactive OAM

between NV edge to NV edge per VNI. This is an indiv= idual draft for

now.

 

Thanks

Santosh P K

 

-----Original Message-----

From: Shahram Davari [mailto:davari@broadcom.com]

Sent: Thursday, June 25, 2015 8:18 PM

To: Santosh P K; Gregory Mirsky; Vengada Prasad Govi= ndan

(venggovi); MALLIK MUDIGONDA (mmudigon)

Cc: rtg-bfd@ietf= .org

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hi Santosh,

 

I think you probably have misunderstood the use of O= AM/BFD in general.

VXLAN is not a networking layer, rather it is a serv= ice

demultiplexer (service  identifier). I think th= e misunderstanding

might be from the name "VXLAN  tunnel"= ;. Since VXLAN is not a tunnel.

The tunnel is actually an IP tunnel that  has V= XLAN as service identifier.

 

A single IP tunnel can carry many VXLANs.  Not = only doing BFD per

VXLAN  doesn't make sense, but it is also not s= calable. My

suggestion is do BFD for  the IP tunnel and you= can achieve what you want.

 

Thx

Shahram

 

-----Original Message-----

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of

Santosh P K

Sent: Monday, May 25, 2015 5:43 AM

To: Gregory Mirsky; Vengada Prasad Govindan (venggov= i); MALLIK

MUDIGONDA (mmudigon)

Cc: rtg-bfd@ietf= .org

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Greg,

Thanks a lot for your review comments. Please see my= inline comments.

 

you reference RFC 5880 but don't specify which of de= fined in BFD

base

document modes are in scope of this work. I assume t= hat, like in

RFC 5884, it  is only Asynchronous mode and Sec= tion 7 excludes Echo

BFD but Demand  mode not mentioned. >Making = >more explicit

statement would be helpful.

 

Sure we can add text for Demand mode as well.

 

 

section 2:

I think that these three cases hardly apply to the p= roposed solution.

In

particular, BFD may very coarsely localize path fail= ure as we

should remember that path and remote peer failure ar= e undistinguishable.

Thus failure detected at one VM, with Tunnel >BFD= session

operational, cannot be  interpreted as peer VM = failure.

 

I am sorry I did not understand this, can you please= elaborate more

on this?

 

section 3:

what ensures that reverse direction of the BFD sessi= on between IP1

(ingress) and IP2 (egress) , i.e. egress transmits B= FD control

packets toward  the ingress, uses the same tunn= el traversed by BFD

control packets sent  from ingress toward the e= gress? >Perhaps use

of BFD Reverse Path TLV and  BFD Discriminator = TLV may be one solution?

 

In case of IP if reverse path has multiple paths to = a destination

then taking a  particular path means IP header = stacking? Correct me

if I am wrong.

 

Perhaps this section could be the right place to dis= cuss and

define

behavior

of the egress in terms of its role in BFD session:

packet encapsulation;

failure reporting;

path selection (discussed above).

And the issues of the encapsulation, reverse path se= lection are

relevant for

S-BFD scenario as well (I think that Prasad's sugges= tion to split

into two  documents, BFD and S-BFD, is quite re= asonable).

 

If all the above point has different methods for BFD= and S-BFD then

of course  we should spilt the draft in to two.=

 

section 6.1:

considering 5884clarification work, can multiple BFD= session

operate

between IP1 and IP2 over the same tunnel?=

 

I do not see a case where we need multiple BFD sessi= on between IP

pair when BFD session terminates at VTEP itself.

 

 

Thanks

Santosh P K

 

 

 

-----Original Message-----

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of

Vengada Prasad Govindan (venggovi)

Sent: Friday, May 08, 2015 12:39 AM

To: Santosh P K; MALLIK MUDIGONDA (mmudigon)

Cc: rtg-bfd@ietf= .org

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hello Santosh/ Authors,

Thanks for your prompt considerations of the comment= s submitted in

this  thread. I request you to consider the fol= lowing points for discussion:

1) Fig 3 of draft-ashwood-nvo3-oam-requirements prov= ides the

context for  OAM layering in NVO3. Though, an i= ndividual draft at

the moment, I submit  that we consider this for= providing more

context to the discussion here.

2) Per my understanding of your proposal, the intent= is to use BFD

for OAM  at the NV edge layer. Please let me kn= ow if this

understanding is incorrect.

3) The clarifications requested earlier this thread = concern about

the inner IP  address (SIP in particular) of th= e BFD packet . Would

they be used from the  overlay IP address space= (belonging to the tenant).

If this is the case, what  would the difference= between a BFD

session using the tenant IP (at the NV  edge), = a particular VNI,

and that of a service layer OAM session that can be =  run using

single-hop BFD (RFC 5880).

In other words, how can the OAM (BFD in this case) o= perating at the

NV Edge  layer operate without using IP from th= e Tenant layer if

the packet is required  to be VxLAN encapsulate= d?

Thanks

Prasad

 

-----Original Message-----

From: Santosh P K [mailto:santoshpk@juniper.net]

Sent: Wednesday, May 06, 2015 3:03 PM

To: MALLIK MUDIGONDA (mmudigon)

Cc: Vengada Prasad Govindan (venggovi); rtg-bfd@ietf.org

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Mallik,

Thanks for your review comments.

 

 

1. It is not clear if this draft is addressing both = VM to VM and

VTEP

to VTEP

verification through BFD. I assume it is both.<= /o:p>

 

Draft is applicable only for VTEP to VTEP, for VM to= VM (if VM is

L3

aware)

BFD as per RFC 5880/5881 should work as it is. VM's = will not be

aware of any  tunnel. Draft talks about tunnel = verification which

terminates at VTEP's.

 

2. If the VMs are Layer 2 only, then what is the inn= er IP address

(especially source IP)? I understand that outer IP i= s going to

carry

the VTEPs

addresses.

 

As mentioned in the draft it would be outgoing inter= face IP sending

VTEP.

 

3. Why is the inner IP destination address 127/8 or<= o:p>

0:0:0:0:0:FFFF:7F00/104?

I understand that it is to avoid the packet being ro= uted but, how

can an IP  packet addressed to a particular VTE= P be consumed by any

other node in the  network and then route the i= nner >payload?

 

The same argument holds true for MPLS as well right?= The motivation

for using the address range 127/8 is the same as des= cribed in

Section

2.1 of RFC4379.

 

4. The service node's use case is not very clear. Ma= t be you can

add a

little

bit of details here.

 

Yes, we can do that.

 

5. I understand that VTEP knows that the packet is t= o be

terminated at

the

VTEP based on TTL being 1. What about the case of VM= to VM BFD? What

should be the TTL value here?   Is it 255 = or something different? It is

hardcoded to "1" in the draft.<= /p>

 

VM's will use normal Async BFD so will use TTL 255.<= o:p>

 

6. Since we are using a destination UDP port of 3784= , shouldn't

the TTL be 255 to be consistent with the RFC 5880?

 

Section 7 of RFC 5884 also mentions use of IP TTL se= t to 1 whereas

UDP port  number set to 3784.

 

 

Thanks

Santosh P K

 

 

 

From: "Vengada Prasad Govindan (venggovi)"= <venggovi@cisco.com><= /o:p>

Date: Wednesday, 6 May 2015 9:39 am

To: Santosh P K <santoshpk@juniper.net>, "rtg-bfd@ietf.org" <rtg-

bfd@ietf.org>=

Subject: RE: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hello Santosh/ Authors,

Thanks for sharing the document, please find a few t= houghts below.

1. The current document talks about both BFD and S-B= FD - would it

be beneficial to make separate documents for BFD and= SBFD to

maintain consistency with the current set of documen= ts.

2. Motivation: It would be nice to state the require= ments or

motivation that  this draft addresses, i.e. wha= t problems does this

draft address that cannot  be solved using the = existing BFD/ SBFD

protocol treating the VxLAN as a  tunnel/ under= lay transport

transparent to BFD. I would submit that BFD over &nb= sp;VxLAN not be

treated along the same lines of BFD over MPLS or BFD= for PW

(VCCV) given the differences in the nature of the tr= ansport between

MPLS  and VxLAN.

3. Inner Ethernet header: The document does not addr= ess the

contents of  the Inner Ethernet header (present= after the VxLAN

header). This needs to  be specified.

4. Destination IP: The document mandates that this n= eeds to be 127/8.

What

disadvantages do you observe if the DIP were to be t= he IP of the

destination  VTEP? When using 127/8 as the DIP.= one problem is that

there is no indication  of the intended DIP of = the BFD session by

using 127/8. What if the node at  which the VxL= AN tunnel is

(prematurely) terminated happens to support  BF= D? It may be better

to use the IP address of the Destination VTEP as the=  DIP.

5. Inner TTL: For the same reasons discussed in (2),= why does the

document  mandate this to be set to 1?

6. It may be beneficial to run a spell-checker to fi= x typos in the

document.

I request the authors/ WG to comment on the above as= pects.

Thanks

Prasad

 

 

-----Original Message-----

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of

Santosh P K

Sent: Monday, May 04, 2015 10:55 PM

To: rtg-bfd@ietf= .org

Subject: FW: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

 

Hello All,

 A new BFD for VXLAN draft has been submitted. = Please do review

and get  back to us with any comments/feedback.=

 

Thanks

Santosh P K

 

-----Original Message-----

From: in= ternet-drafts@ietf.org [mai= lto:internet-drafts@ietf.org]

Sent: Monday, May 04, 2015 9:29 PM

To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan= ; Santosh P K;

Basil Saji;  Sudarsan Paragiri Mohan=

Subject: New Version Notification for

draft-spallagatti-bfd-vxlan-00.txt

A new version of I-D, draft-spallagatti-bfd-vxlan-00= .txt

has been successfully submitted by Santosh Pallagatt= i and posted to

the IETF  repository.

Name: draft-spallagatti-bfd-vxlan

Revision: 00

Title: BFD for VXLAN

Document date: 2015-05-04

Group: Individual Submission

Pages: 9

URL:         = ;   

https://www.ietf.org/internet-drafts/draft-spalla= gatti-bfd-vxlan-

00.txt

Status:        &n= bsp;

https://datatracker.ietf.org/doc/draft-spallagatti-bf= d-vxlan/

Htmlized:       <= /o:p>

https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-= 00

Abstract:

 This document describes use of Bidirectional F= orwarding Detection

 (BFD) protocol for VXLAN . Comments on this dr= aft should be directed

 to nvo3@ietf.= org.

Please note that it may take a couple of minutes fro= m the time of

submission  until the htmlized version and diff= are available at

tools.ietf.org= .

The IETF Secretariat

 

--_000_315041E4211CB84E86EF7C25A2AB583D5457F748xmbrcdx15ciscoc_-- From nobody Tue Jun 30 02:08:05 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC3B1A1EB7 for ; Tue, 30 Jun 2015 02:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f0prf2gZdNmb for ; Tue, 30 Jun 2015 02:08:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4681A1E0F for ; Tue, 30 Jun 2015 02:08:02 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 09:07:41 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 09:07:41 +0000 From: Santosh P K To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAANTYCAAtWcAIAAfT2AgAA1qQCAAAMjAIAAymwA Date: Tue, 30 Jun 2015 09:07:41 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadcom.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.13] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1760; 5:dK7E4kqqbbA22/7xxZOVeL2Ha5EHgatBRRVT2YG1YYY4Tlp8eTWKbAqMnLJpR81FcfpmUbJPJ4FVgn/rYvw2hX87BeQHrlrr2Mzkho9sS0OVBfN8OcpWR4yhBhLr57IBQsp4QUxJFOrSHGTioFE6Ww==; 24:ptS/teqopT8Ywe9zPcMydJAQlehiIbKx7MmzrQeQboDo1u+VkWNHj4WxGGj7aw7+YNSrTmu3GNi2GZsFg8ThR4RPsL7Vpwmx078n1+85lWQ=; 20:ZDFbYuHXuoeLyq2K+A8fMonoACpO8gvH5tDYm0At02cXFdrK3piGamBq/f1hb0DtA1gLbOQZzR/via9fTNacPA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1760; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1760; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(13464003)(33656002)(46102003)(561944003)(87936001)(76176999)(99286002)(189998001)(54356999)(5001960100002)(5002640100001)(106116001)(230783001)(2656002)(5001770100001)(19580405001)(19580395003)(50986999)(86362001)(74316001)(40100003)(122556002)(62966003)(2900100001)(93886004)(77096005)(2950100001)(77156002)(76576001)(5003600100002)(66066001)(92566002)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1760; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 09:07:41.8849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1760 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:08:04 -0000 Shahram, =20 >=20 > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD >=20 > Or >=20 > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD >=20 > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? >=20 It is 1) we have next version of this draft which address that part.=20 Thanks Santosh P K=20 >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 1:51 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > thank you for your comments to this proposal that make the discussion so > much alive. > I think that processing of the VXLAN tag by VTEP before validating BFD is > sufficient, in my view, level of verification. In VCCV BFD the PW label i= s not > used for BFD forwarding but we find it useful as Service OAM in addition = to > RFC 5884, BFD over MPLS LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 10:39 AM > To: Vengada Prasad Govindan (venggovi) > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Prasad, >=20 > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since > standard BFD processing does no care where the BFD came from it only look= s > at "your discriminator" to update BFD state machine. >=20 > Also I don't see how many VXLANs can be checked via a single BFD session. > Could you please describe? >=20 > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP shou= ld > not require BFD. Just use some query mechanism. Why do you need to run > continuous BFD. >=20 > What you have to show me to convince me that your draft solves a real > problem is to show that VXLAN tag is used for BFD forwarding. Otherwise > BFD over the outer or Inner IP should give you all coverage needed. >=20 >=20 > Thx > Shahram >=20 >=20 >=20 >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, June 29, 2015 3:11 AM > To: Shahram Davari > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Shahram, > At the terminating VTEP, VxLAN information is used to consume the BFD > packet. In other words, a BFD session increases the confidence of the > existence of the VNI-Forwarding Domain mapping and the presence of valid > VTEP termination configuration at the terminating VTEP. At the originatin= g > VTEP, it is a matter of implementation of how many VxLAN tables are > exercised in the datapath (am aware of at least one implementation where = it > is being exercised to a considerable extent). >=20 > Thanks > Prasad >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Saturday, June 27, 2015 8:24 PM > To: Shahram Davari > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi >=20 > May be a better way to make this clear is to answer the following questio= n: >=20 > Where is the VXLAN tag information used in this BFD forwarding? >=20 > Thx > Shahram From nobody Tue Jun 30 02:13:11 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AE51A1F16 for ; Tue, 30 Jun 2015 02:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ix2rUPKbDH3j for ; Tue, 30 Jun 2015 02:13:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE5E1A1EF2 for ; Tue, 30 Jun 2015 02:13:07 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 09:12:49 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 09:12:49 +0000 From: Santosh P K To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAANTYCAAtWcAIAAfT2AgAA1qQCAAAMjAIAABReAgAAf8wCAAAUGgIAAoKVA Date: Tue, 30 Jun 2015 09:12:48 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadcom.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.13] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1760; 5:rHB26WTyBY/HK1LPPFRElRQ8FsYAj4xr6KyO5HlPtfZFbZixKSpQ4KjSIln3u4Z6PUUcnLbxKTm18AolaY3tGMGoEWbNMJ6AGc+zQyxN2qCuJ7Iqwd5tWi1jxG0bQKxJx+ow4SlbJeG/s2nSW0N3Jg==; 24:C/6ivI3knbARIppROtiqViT1c4AgX2b1azVrMRRx8zSy3J7SDQLcgaYbzcIGvpFbkRlQ+7VZlqVILKKfRTY8xu4yR7on8E2uMLKoWyoiqNY=; 20:i2wYCFC+jLKYLpXW1dLhwCLM+I0Uq9Oyz22h0uv0HGFwh/RbsTrMVl9QI82tFeYObhRcQ5S+/jWMLPYFxO9IDw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1760; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1760; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(13464003)(33656002)(46102003)(561944003)(87936001)(76176999)(99286002)(189998001)(54356999)(5001960100002)(5002640100001)(106116001)(230783001)(2656002)(5001770100001)(19580405001)(19580395003)(50986999)(86362001)(74316001)(40100003)(122556002)(62966003)(2900100001)(93886004)(77096005)(2950100001)(77156002)(76576001)(5003600100002)(66066001)(92566002)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1760; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 09:12:48.8188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1760 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:13:10 -0000 =20 > Another question I have is how do you forward these BFD packets from VTEP > to VM? Since DIP =3D 127/8, I assume there is no way to forward such pack= ets > past the VTEP. We don't want to send it past VTEP as BFD will terminate at VTEP itself. Ri= ght now use of 127/8 is not really clear as inner IP address. We have again= added some text for inner IP address and its use.=20 >=20 > If you want to do VM to VM connectivity check then I suggest one of the > following: >=20 > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM > between VMs > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over IP/UDP > over Ethernet over VXLAN > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > 3a) If VTEP and VMs are physically in the same CPU core then r= un what > you are proposing in this draft (1-hop BFD). Although it should give you = same > result as running BFD over the outer IP tunnel > 3b) If VTEP and VMs are physically separate (such as VTEP is in= TOR and > VM is CPU core), then run something similar to what you are proposing but > with Multi-hop DIP address so that BFD can be forwarded to VM from VTEP. >=20 We are not trying to address VM to VM connectivity check as I believe that = does not really need any changes and BFD as it is should run. Proposal is f= rom VTEP to VTEP. Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > Davari > Sent: Monday, June 29, 2015 4:15 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Greg, >=20 > I don't see much value in running BFD for SS-PW compared to running BFD > over the LSP. >=20 > Thx > SD >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 2:21 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. Tr= ue, > we have case of MS-PW where PW label used (that was discussed in MPLS- > TP in particular). But that doesn't mean that VCCV BFD has value only for= MS- > PW and for SS-PW has no value. Would you agree? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 2:02 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Greg, >=20 > You are welcome. Could you please clarify which one of the following is t= he > packet format: >=20 > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD >=20 > Or >=20 > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD >=20 > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? >=20 > Also This is different from PW BFD, since in case of PW, there can be MS-= PW, > where the LSP BFD is not end-to-end. But in this case we don't have MS- > VXLAN. > So the span of the VXLAN and the IP tunnel is the same. >=20 > In other words you have to specify in which part of forwarding the BFD th= e > VXLAN Tag is used. If it is not used then it has no effect. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 1:51 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > thank you for your comments to this proposal that make the discussion so > much alive. > I think that processing of the VXLAN tag by VTEP before validating BFD is > sufficient, in my view, level of verification. In VCCV BFD the PW label i= s not > used for BFD forwarding but we find it useful as Service OAM in addition = to > RFC 5884, BFD over MPLS LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 10:39 AM > To: Vengada Prasad Govindan (venggovi) > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Prasad, >=20 > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since > standard BFD processing does no care where the BFD came from it only look= s > at "your discriminator" to update BFD state machine. >=20 > Also I don't see how many VXLANs can be checked via a single BFD session. > Could you please describe? >=20 > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP shou= ld > not require BFD. Just use some query mechanism. Why do you need to run > continuous BFD. >=20 > What you have to show me to convince me that your draft solves a real > problem is to show that VXLAN tag is used for BFD forwarding. Otherwise > BFD over the outer or Inner IP should give you all coverage needed. >=20 >=20 > Thx > Shahram >=20 >=20 >=20 >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, June 29, 2015 3:11 AM > To: Shahram Davari > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Shahram, > At the terminating VTEP, VxLAN information is used to consume the BFD > packet. In other words, a BFD session increases the confidence of the > existence of the VNI-Forwarding Domain mapping and the presence of valid > VTEP termination configuration at the terminating VTEP. At the originatin= g > VTEP, it is a matter of implementation of how many VxLAN tables are > exercised in the datapath (am aware of at least one implementation where = it > is being exercised to a considerable extent). >=20 > Thanks > Prasad >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Saturday, June 27, 2015 8:24 PM > To: Shahram Davari > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi >=20 > May be a better way to make this clear is to answer the following questio= n: >=20 > Where is the VXLAN tag information used in this BFD forwarding? >=20 > Thx > Shahram From nobody Tue Jun 30 02:14:16 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109AA1A1F16 for ; Tue, 30 Jun 2015 02:14:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 txke__fwi9MA for ; Tue, 30 Jun 2015 02:14:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB0E1A1EF2 for ; Tue, 30 Jun 2015 02:14:12 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 09:14:11 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 09:14:10 +0000 From: Santosh P K To: "S. Davari" , Shahram Davari , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAKROICAAdPPMA== Date: Tue, 30 Jun 2015 09:14:10 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.13] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1760; 5:fe2ZsASOB9mDLPGShfIlKj/dO0uzhGZxrcPH5cm74Y/WIhs4rPQKFfBuNevtaU7XI5XXN8EeJUROAP7QzbYSzhtAzWdCFo8yeAkgnWDCLiJyTdsh41rR0Gpddf0LP2U3CmaOYf+aNwnZWrjLNop0Rg==; 24:ovTvgYFBMoNgqqFrxkGdvjfF/eDsqQB43BcvPA+Jq1buLCZ/x/EFTaEpSD+Faa5GjpqXzEdMubKhUT6bdNqE4S2QqNa4nBc/HFyYr8ahrM8=; 20:oXmgi+7JVTJhb3/88PTHJTcHlzx3UJjnhj4O1DMkNbD3lSGYfWHTR8TOb9SSQPuM4TDYZjHmU5eLqqJs5O7MCA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1760; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1760; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(76104003)(33656002)(46102003)(19609705001)(16236675004)(19625215002)(87936001)(76176999)(99286002)(189998001)(54356999)(7110500001)(5001960100002)(5002640100001)(107886002)(106116001)(230783001)(2656002)(5001770100001)(19580405001)(19580395003)(50986999)(5890100001)(2501003)(86362001)(74316001)(40100003)(122556002)(15975445007)(62966003)(2900100001)(2420400003)(93886004)(77096005)(2950100001)(77156002)(76576001)(5003600100002)(66066001)(92566002)(19300405004)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1760; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB1760B93E86C09AAFBB1DAAF5B3A90SN1PR0501MB1760_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 09:14:10.8533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1760 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:14:15 -0000 --_000_SN1PR0501MB1760B93E86C09AAFBB1DAAF5B3A90SN1PR0501MB1760_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgY2FuIGJlIGZldyBWVEVQcyB3aG8gbWlnaHQgaGF2ZSBjYXBhYmlsaXRpZXMgdG8gbXVs dGljYXN0IHRoZSBwYWNrZXQuIEluIHN1Y2ggYSBzY2VuYXJpbyBWVEVQIHdpbGwgc2VuZCB0aGF0 IHBhY2tldCB0byBzZXJ2aWNlIG5vZGUgYW5kIHNlcnZpY2Ugbm9kZSB3aWxsIGRvIGEgbXVsdGlj YXN0IG9uIGl0cyBiZWhhbGYuDQoNCg0KVGhhbmtzDQpTYW50b3NoIFAgSw0KDQpGcm9tOiBSdGct YmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUy4gRGF2 YXJpDQpTZW50OiBNb25kYXksIEp1bmUgMjksIDIwMTUgMTA6NDggQU0NClRvOiBTaGFocmFtIERh dmFyaTsgcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAwLnR4dA0KDQpIaQ0KDQpXaGF0 IGlzIGEgc2VydmljZSBub2RlPw0KDQpUaHgNCg0KU2QNCg0KDQpIaSBQcmFzYWQgLA0KDQpJIGRv bid0IHNlZSBob3cgeW91IGdldCBtb3JlIGNvdmVyYWdlIGhhdmluZyBhIFZYTEFOIHRhZy4NCg0K U2luY2UgeW91IGFyZSBub3QgdGVzdGluZyB0aGUgVlhMQU4gYmFzZWQgVkZJL1ZSRiBmb3J3YXJk aW5nLiBCeSB0aGF0IEkgbWVhbiB5b3UgYXJlIG5vdCB0ZXN0aW5nIChEQSwgVlhMQU4gKSBvciAo RElQLCBWWExBTikgZm9yd2FyZGluZy4NCkdWUDE+IE9uZSBvZiB0aGUgYXNwZWN0cyBvZiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxsIGhhdmUgYSB2YWxpZCBpbm5lciBESVAgaW5z dGVhZCBvZiAxMjcvOC4gVGhpcyBzaG91bGQgaGVscCBhZGRyZXNzIHlvdXIgY29uY2VybiB0byBh biBleHRlbnQuDQpBbHNvIHlvdSBhcmUgbm90IHRlc3RpbmcgdGhlIG1hcHBpbmcgZnJvbSBBQyAo QXR0YWNobWVudCBDaXJjdWl0KSB0byBhIFZYTEFOIHRhZy4NCkdWUDE+IEFncmVlZCwgdGhpcyBh c3BlY3QgaGFzIG5vdCAoeWV0KSBiZWVuIGFkZHJlc3NlZCBieSBSRkM1ODg0IGFzIHdlbGwsIG5v dCB1c2luZyBpdCBhcyBhbiBleGN1c2UgYnV0IEkgYW0ganVzdCBub3RpbmcgdGhlIHByZWNlZGVu dCBoZXJlLg0KDQpJbiBteSBvcGluaW9uIGFsbCB5b3UgYXJlIHRlc3RpbmcsIGlzIHRoYXQgYXQg dGhlIG90aGVyIGVuZCBvZiBhbiBJUCBUdW5uZWwgYSBzcGVjaWZpYyBWWExBTiBleGlzdCBvciBu b3QuIFdoaWNoIGRvZXMgbm90IHJlcXVpcmUgcnVubmluZyBjb250aW51b3VzIEJGRC4NCkdWUDE+ IFRoZXJlIGFyZSBzcGVjaWZpYyB1c2UtY2FzZXMgKHNlZSBub3RlIGFib3V0IFNlcnZpY2UgTm9k ZSByZWFjaGFiaWxpdHkgaW4gU2VjIDIgb2YgdGhlIGRyYWZ0KSB0aGF0IHJlcXVpcmUgY29udGlu dW91cyBtb25pdG9yaW5nIG9mIHNvbWUgc3BlY2lhbC1wdXJwb3NlIFZURVBzLg0KDQpJbiBteSBv cGluaW9uIHRoaXMgaXMgYSB2ZXJ5IGluIGVmZmljaWVudCB3YXkgb2YgZ2V0dGluZyB0aGF0IGlu Zm9ybWF0aW9uLiBUaGUgY29udHJvbGxlciBzaG91bGQgYmUgYWJsZSB0byBnZXQgdGhpcyBpbmZv cm1hdGlvbiBtdWNoIG1vcmUgZWZmaWNpZW50bHkuDQoNCkl0IHdvdWxkIGJlIGdvb2QgaWYgeW91 IGNhbiBwcm92aWRlIGFuIGV4YW1wbGUgb2Ygd2hhdCB5b3UgdGhpbmsgaXMgbW9yZSBjb3ZlcmFn ZSB0aGFuIEJGRC4gT3IgYXQgbGVhc3Qgd2hhdCBleHRyYSBjb3ZlcmFnZSBkbyB5b3UgZXhhY3Rs eSBoYXZlIGluIG1pbmQsIHNpbmNlIHRoaXMgZHJhZnQgaXMgbm90IGNhcGFibGUgb2YgbW9yZSBj b3ZlcmFnZSB0aGFuIHN0YW5kYXJkIEJGRCBvdmVyIHRoZSBJUCB0dW5uZWwuDQoNClJlZ2FyZHMs DQpTaGFocmFtDQpSZWdhcmRzLA0KU2hhaHJhbQ0KDQoNCk9uIEp1biAyNywgMjAxNSwgYXQgNzow NiBBTSwgU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBi cm9hZGNvbS5jb20+PiB3cm90ZToNCkhpIFByYXNhZCAsDQoNCkkgZG9uJ3Qgc2VlIGhvdyB5b3Ug Z2V0IG1vcmUgY292ZXJhZ2UgaGF2aW5nIGEgVlhMQU4gdGFnLg0KDQpTaW5jZSB5b3UgYXJlIG5v dCB0ZXN0aW5nIHRoZSBWWExBTiBiYXNlZCBWRkkvVlJGIGZvcndhcmRpbmcuIEJ5IHRoYXQgSSBt ZWFuIHlvdSBhcmUgbm90IHRlc3RpbmcgKERBLCBWWExBTiApIG9yIChESVAsIFZYTEFOKSBmb3J3 YXJkaW5nLg0KR1ZQMT4gT25lIG9mIHRoZSBhc3BlY3RzIG9mIHRoZSBuZXh0IHZlcnNpb24gb2Yg dGhlIGRyYWZ0IHdpbGwgaGF2ZSBhIHZhbGlkIGlubmVyIERJUCBpbnN0ZWFkIG9mIDEyNy84LiBU aGlzIHNob3VsZCBoZWxwIGFkZHJlc3MgeW91ciBjb25jZXJuIHRvIGFuIGV4dGVudC4NCkFsc28g eW91IGFyZSBub3QgdGVzdGluZyB0aGUgbWFwcGluZyBmcm9tIEFDIChBdHRhY2htZW50IENpcmN1 aXQpIHRvIGEgVlhMQU4gdGFnLg0KR1ZQMT4gQWdyZWVkLCB0aGlzIGFzcGVjdCBoYXMgbm90ICh5 ZXQpIGJlZW4gYWRkcmVzc2VkIGJ5IFJGQzU4ODQgYXMgd2VsbCwgbm90IHVzaW5nIGl0IGFzIGFu IGV4Y3VzZSBidXQgSSBhbSBqdXN0IG5vdGluZyB0aGUgcHJlY2VkZW50IGhlcmUuDQoNCkluIG15 IG9waW5pb24gYWxsIHlvdSBhcmUgdGVzdGluZywgaXMgdGhhdCBhdCB0aGUgb3RoZXIgZW5kIG9m IGFuIElQIFR1bm5lbCBhIHNwZWNpZmljIFZYTEFOIGV4aXN0IG9yIG5vdC4gV2hpY2ggZG9lcyBu b3QgcmVxdWlyZSBydW5uaW5nIGNvbnRpbnVvdXMgQkZELg0KR1ZQMT4gVGhlcmUgYXJlIHNwZWNp ZmljIHVzZS1jYXNlcyAoc2VlIG5vdGUgYWJvdXQgU2VydmljZSBOb2RlIHJlYWNoYWJpbGl0eSBp biBTZWMgMiBvZiB0aGUgZHJhZnQpIHRoYXQgcmVxdWlyZSBjb250aW51b3VzIG1vbml0b3Jpbmcg b2Ygc29tZSBzcGVjaWFsLXB1cnBvc2UgVlRFUHMuDQoNCkluIG15IG9waW5pb24gdGhpcyBpcyBh IHZlcnkgaW4gZWZmaWNpZW50IHdheSBvZiBnZXR0aW5nIHRoYXQgaW5mb3JtYXRpb24uIFRoZSBj b250cm9sbGVyIHNob3VsZCBiZSBhYmxlIHRvIGdldCB0aGlzIGluZm9ybWF0aW9uIG11Y2ggbW9y ZSBlZmZpY2llbnRseS4NCg0KSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIHByb3ZpZGUgYW4g ZXhhbXBsZSBvZiB3aGF0IHlvdSB0aGluayBpcyBtb3JlIGNvdmVyYWdlIHRoYW4gQkZELiBPciBh dCBsZWFzdCB3aGF0IGV4dHJhIGNvdmVyYWdlIGRvIHlvdSBleGFjdGx5IGhhdmUgaW4gbWluZCwg c2luY2UgdGhpcyBkcmFmdCBpcyBub3QgY2FwYWJsZSBvZiBtb3JlIGNvdmVyYWdlIHRoYW4gc3Rh bmRhcmQgQkZEIG92ZXIgdGhlIElQIHR1bm5lbC4NCg0KUmVnYXJkcywNClNoYWhyYW0NCg== --_000_SN1PR0501MB1760B93E86C09AAFBB1DAAF5B3A90SN1PR0501MB1760_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhlcmUgY2FuIGJlIGZldyBWVEVQcyB3aG8gbWlnaHQgaGF2ZSBjYXBh YmlsaXRpZXMgdG8gbXVsdGljYXN0IHRoZSBwYWNrZXQuIEluIHN1Y2ggYSBzY2VuYXJpbyBWVEVQ IHdpbGwgc2VuZCB0aGF0IHBhY2tldCB0byBzZXJ2aWNlIG5vZGUgYW5kIHNlcnZpY2Ugbm9kZSB3 aWxsDQogZG8gYSBtdWx0aWNhc3Qgb24gaXRzIGJlaGFsZi4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlNhbnRvc2ggUCBLDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSdGctYmZkIFttYWlsdG86 cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TLiBEYXZhcmk8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI5LCAyMDE1IDEwOjQ4IEFNPGJyPg0KPGI+ VG86PC9iPiBTaGFocmFtIERhdmFyaTsgcnRnLWJmZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFsbGFnYXR0aS1i ZmQtdnhsYW4tMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldoYXQgaXMgYSBzZXJ2aWNlIG5vZGU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoeDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5IaSBQcmFzYWQgLDxicj4NCjxicj4NCkkgZG9uJ3Qgc2VlIGhvdyB5b3UgZ2V0IG1v cmUgY292ZXJhZ2UgaGF2aW5nIGEgVlhMQU4gdGFnLiZuYnNwOzxicj4NCjxicj4NClNpbmNlIHlv dSBhcmUgbm90IHRlc3RpbmcgdGhlIFZYTEFOIGJhc2VkIFZGSS9WUkYgZm9yd2FyZGluZy4gQnkg dGhhdCBJIG1lYW4geW91IGFyZSBub3QgdGVzdGluZyAoREEsIFZYTEFOICkgb3IgKERJUCwgVlhM QU4pIGZvcndhcmRpbmcuPGJyPg0KR1ZQMSZndDsgT25lIG9mIHRoZSBhc3BlY3RzIG9mIHRoZSBu ZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHdpbGwgaGF2ZSBhIHZhbGlkIGlubmVyIERJUCBpbnN0 ZWFkIG9mIDEyNy84LiBUaGlzIHNob3VsZCBoZWxwIGFkZHJlc3MgeW91ciBjb25jZXJuIHRvIGFu IGV4dGVudC48YnI+DQpBbHNvIHlvdSBhcmUgbm90IHRlc3RpbmcgdGhlIG1hcHBpbmcgZnJvbSBB QyAoQXR0YWNobWVudCBDaXJjdWl0KSB0byBhIFZYTEFOIHRhZy4mbmJzcDs8YnI+DQpHVlAxJmd0 OyBBZ3JlZWQsIHRoaXMgYXNwZWN0IGhhcyBub3QgKHlldCkgYmVlbiBhZGRyZXNzZWQgYnkgUkZD NTg4NCBhcyB3ZWxsLCBub3QgdXNpbmcgaXQgYXMgYW4gZXhjdXNlIGJ1dCBJIGFtIGp1c3Qgbm90 aW5nIHRoZSBwcmVjZWRlbnQgaGVyZS48YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uIGFsbCB5b3Ug YXJlIHRlc3RpbmcsIGlzIHRoYXQgYXQgdGhlIG90aGVyIGVuZCBvZiBhbiBJUCBUdW5uZWwgYSBz cGVjaWZpYyBWWExBTiBleGlzdCBvciBub3QuIFdoaWNoIGRvZXMgbm90IHJlcXVpcmUgcnVubmlu ZyBjb250aW51b3VzIEJGRC48YnI+DQpHVlAxJmd0OyBUaGVyZSBhcmUgc3BlY2lmaWMgdXNlLWNh c2VzIChzZWUgbm90ZSBhYm91dCBTZXJ2aWNlIE5vZGUgcmVhY2hhYmlsaXR5IGluIFNlYyAyIG9m IHRoZSBkcmFmdCkgdGhhdCByZXF1aXJlIGNvbnRpbnVvdXMgbW9uaXRvcmluZyBvZiBzb21lIHNw ZWNpYWwtcHVycG9zZSBWVEVQcy48YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uIHRoaXMgaXMgYSB2 ZXJ5IGluIGVmZmljaWVudCB3YXkgb2YgZ2V0dGluZyB0aGF0IGluZm9ybWF0aW9uLiBUaGUgY29u dHJvbGxlciBzaG91bGQgYmUgYWJsZSB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiBtdWNoIG1vcmUg ZWZmaWNpZW50bHkuJm5ic3A7PGJyPg0KPGJyPg0KSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2Fu IHByb3ZpZGUgYW4gZXhhbXBsZSBvZiB3aGF0IHlvdSB0aGluayBpcyBtb3JlIGNvdmVyYWdlIHRo YW4gQkZELiBPciBhdCBsZWFzdCB3aGF0IGV4dHJhIGNvdmVyYWdlIGRvIHlvdSBleGFjdGx5IGhh dmUgaW4gbWluZCwgc2luY2UgdGhpcyBkcmFmdCBpcyBub3QgY2FwYWJsZSBvZiBtb3JlIGNvdmVy YWdlIHRoYW4gc3RhbmRhcmQgQkZEIG92ZXIgdGhlIElQIHR1bm5lbC4mbmJzcDs8YnI+DQo8YnI+ DQpSZWdhcmRzLDxicj4NClNoYWhyYW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNoYWhyYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCk9uIEp1biAyNywgMjAxNSwgYXQgNzowNiBBTSwgU2hhaHJhbSBEYXZhcmkg Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tIj5kYXZhcmlAYnJvYWRjb20u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgUHJhc2FkICw8YnI+DQo8YnI+DQpJIGRvbid0IHNlZSBob3cgeW91IGdldCBt b3JlIGNvdmVyYWdlIGhhdmluZyBhIFZYTEFOIHRhZy4gPGJyPg0KPGJyPg0KU2luY2UgeW91IGFy ZSBub3QgdGVzdGluZyB0aGUgVlhMQU4gYmFzZWQgVkZJL1ZSRiBmb3J3YXJkaW5nLiBCeSB0aGF0 IEkgbWVhbiB5b3UgYXJlIG5vdCB0ZXN0aW5nIChEQSwgVlhMQU4gKSBvciAoRElQLCBWWExBTikg Zm9yd2FyZGluZy48YnI+DQpHVlAxJmd0OyBPbmUgb2YgdGhlIGFzcGVjdHMgb2YgdGhlIG5leHQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgd2lsbCBoYXZlIGEgdmFsaWQgaW5uZXIgRElQIGluc3RlYWQg b2YgMTI3LzguIFRoaXMgc2hvdWxkIGhlbHAgYWRkcmVzcyB5b3VyIGNvbmNlcm4gdG8gYW4gZXh0 ZW50Ljxicj4NCkFsc28geW91IGFyZSBub3QgdGVzdGluZyB0aGUgbWFwcGluZyBmcm9tIEFDIChB dHRhY2htZW50IENpcmN1aXQpIHRvIGEgVlhMQU4gdGFnLg0KPGJyPg0KR1ZQMSZndDsgQWdyZWVk LCB0aGlzIGFzcGVjdCBoYXMgbm90ICh5ZXQpIGJlZW4gYWRkcmVzc2VkIGJ5IFJGQzU4ODQgYXMg d2VsbCwgbm90IHVzaW5nIGl0IGFzIGFuIGV4Y3VzZSBidXQgSSBhbSBqdXN0IG5vdGluZyB0aGUg cHJlY2VkZW50IGhlcmUuPGJyPg0KPGJyPg0KSW4gbXkgb3BpbmlvbiBhbGwgeW91IGFyZSB0ZXN0 aW5nLCBpcyB0aGF0IGF0IHRoZSBvdGhlciBlbmQgb2YgYW4gSVAgVHVubmVsIGEgc3BlY2lmaWMg VlhMQU4gZXhpc3Qgb3Igbm90LiBXaGljaCBkb2VzIG5vdCByZXF1aXJlIHJ1bm5pbmcgY29udGlu dW91cyBCRkQuPGJyPg0KR1ZQMSZndDsgVGhlcmUgYXJlIHNwZWNpZmljIHVzZS1jYXNlcyAoc2Vl IG5vdGUgYWJvdXQgU2VydmljZSBOb2RlIHJlYWNoYWJpbGl0eSBpbiBTZWMgMiBvZiB0aGUgZHJh ZnQpIHRoYXQgcmVxdWlyZSBjb250aW51b3VzIG1vbml0b3Jpbmcgb2Ygc29tZSBzcGVjaWFsLXB1 cnBvc2UgVlRFUHMuPGJyPg0KPGJyPg0KSW4gbXkgb3BpbmlvbiB0aGlzIGlzIGEgdmVyeSBpbiBl ZmZpY2llbnQgd2F5IG9mIGdldHRpbmcgdGhhdCBpbmZvcm1hdGlvbi4gVGhlIGNvbnRyb2xsZXIg c2hvdWxkIGJlIGFibGUgdG8gZ2V0IHRoaXMgaW5mb3JtYXRpb24gbXVjaCBtb3JlIGVmZmljaWVu dGx5Lg0KPGJyPg0KPGJyPg0KSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIHByb3ZpZGUgYW4g ZXhhbXBsZSBvZiB3aGF0IHlvdSB0aGluayBpcyBtb3JlIGNvdmVyYWdlIHRoYW4gQkZELiBPciBh dCBsZWFzdCB3aGF0IGV4dHJhIGNvdmVyYWdlIGRvIHlvdSBleGFjdGx5IGhhdmUgaW4gbWluZCwg c2luY2UgdGhpcyBkcmFmdCBpcyBub3QgY2FwYWJsZSBvZiBtb3JlIGNvdmVyYWdlIHRoYW4gc3Rh bmRhcmQgQkZEIG92ZXIgdGhlIElQIHR1bm5lbC4NCjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0K U2hhaHJhbTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0501MB1760B93E86C09AAFBB1DAAF5B3A90SN1PR0501MB1760_-- From nobody Tue Jun 30 06:01:09 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6F1A90F3; Tue, 30 Jun 2015 06:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gpKPIdjnLdyG; Tue, 30 Jun 2015 06:01:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BD01ACED7; Tue, 30 Jun 2015 06:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2180; q=dns/txt; s=iport; t=1435669241; x=1436878841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=esrTSjoFlyktpF1gBDOtqMps4sDmkYpMck0GoYwaLuI=; b=OBxarCSZ1tp8rdywV/bVzyjhY8Vp5YgRiRHlhONV0wQVWIq1WsJN1Jmt XVo3YTqVnMN3FXVs4N2IJARCyb/22bHaUTjHA6cRZWUFOuV+CcMrxrCHI 6mUIOvKaoUNEQbExHNaV8Mp9y9BE5mlA6Z8ktlJNuMRsZaEIxLCfTtldt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C6AwCrkpJV/4sNJK1cgxFUXwa9OwmBZ4V4AoFFOBQBAQEBAQEBgQqEIgEBAQQ6PwwEAgEIEQQBAQsUCQchERQJCAEBBAENBQiIEgMSDb4sDYVhAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLSoJNgVYRASAxBwaDEYEUBYwUh3MBhFmFGoMdhBKLV4M9g10mY4MXbwGBCzqBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,377,1432598400"; d="scan'208";a="11479206" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jun 2015 13:00:30 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5UD0Twd011325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 13:00:29 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 08:00:29 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" , "pals@ietf.org" , "l2tpext@ietf.org" Subject: RE: Requesting comments on SBFD-VCCV drafts Thread-Topic: Requesting comments on SBFD-VCCV drafts Thread-Index: AdBcG8bbDt4lFsaSQwiuvYh/1U3PNAdqn65wDlt+sSA= Date: Tue, 30 Jun 2015 13:00:29 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D54583426@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D543E79BF@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D543E79BF@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 13:01:09 -0000 Hello all, We have uploaded the next revision of the document incorporating the comm= ents received thus far. Please let us know your comments on the updated doc= ument. Name: draft-gp-pals-seamless-vccv Revision: 01 Title: Seamless BFD for VCCV Document date: 2015-06-30 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-gp-pals-seamless= -vccv-01.txt Status: https://datatracker.ietf.org/doc/draft-gp-pals-seamless-vcc= v/ Htmlized: https://tools.ietf.org/html/draft-gp-pals-seamless-vccv-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-gp-pals-seamless-= vccv-01 Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vengada Prasad= Govindan (venggovi) Sent: Saturday, April 18, 2015 5:19 PM To: rtg-bfd@ietf.org; pals@ietf.org; l2tpext@ietf.org Cc: Carlos Pignataro (cpignata) Subject: RE: Requesting comments on SBFD-VCCV drafts Hello all, Including the L2TP list for comments from them on the two drafts describe= d in the email below. A gentle reminder to the pals and bfd WG lists. Pleas= e note that some discussion when these drafts were presented at PALS and BF= D WG at Dallas (IETF-92).=20 Thanks Prasad -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Vengada Prasad Govin= dan (venggovi) Sent: Wednesday, March 11, 2015 10:23 PM To: rtg-bfd@ietf.org; pals@ietf.org Cc: Jeffrey Haas (jhaas@pfrc.org); Carlos Pignataro (cpign= ata); agmalis@gmail.com; nobo.akiya.dev@gmail.com; Stewart Bryant (stbryant= ) Subject: [Pals] Requesting comments on SBFD-VCCV drafts Hello all, We have submitted two new drafts: a. draft-gp-pals-seamless-vccv: This draft defines the SBFD protocol operat= ion for VCCV. https://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ b. draft-gp-l2tpext-sbfd-discriminator: This draft defines AVPs for adverti= sement of SBFD discriminators in L2TP. We welcome comments/ feedback on these drafts. https://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ Thanks Prasad From nobody Tue Jun 30 09:10:26 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36A41ACD5B for ; Tue, 30 Jun 2015 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 EDGZTVGdEpoN for ; Tue, 30 Jun 2015 09:10:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BF21ACD50 for ; Tue, 30 Jun 2015 09:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7593; q=dns/txt; s=iport; t=1435680623; x=1436890223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+oTM6QdK1g9tiiiGf8zzn5x/DQVBXAAcCAAyZsdByC4=; b=WWTtNNpQ5nZZAJnlJ6kAYNdYD/M2JNCqBLPiVTx428ytk5THznRyTSx7 G8WmDJuBKkL8LWU3QB63CvdaozPfKxZsgXa8Fk2eqS/2Eo/kkKruzve8f RDKApXdlxWt5Dhaj6tShNsqA1+60Ln2oROLuWX/M6GIuDGN217RKl3Bqh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ClAwDIvpJV/49dJa1bgxGBMwa9PQmHYwKBTzgUAQEBAQEBAYEKhCIBAQEDATo9AgUHBAIBCBEEAQELFAkHMhQJCAIEAQ0FCIgfCMgYAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhFUxBwaDEYEUAQSUBwGNEIQSim6EJoNdJoN6b4EFJRyBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,378,1432598400"; d="scan'208";a="164237533" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 30 Jun 2015 16:10:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5UGAMWv017777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 16:10:22 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 11:10:22 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Santosh P K , Shahram Davari , Gregory Mirsky Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACBqID//7a8kIAAVzEAgAANToCAAn6eYIAA1DuAgAA1qACAAAMkAIAABReAgAAf8wCAAAUGgIAAogcAgAAgkgA= Date: Tue, 30 Jun 2015 16:10:22 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5458360F@xmb-rcd-x15.cisco.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@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: [10.65.56.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:10:26 -0000 Hello Shahram, As Santosh mentions below, a revision of this draft will be published sho= rtly mandating the use of a valid inner Destination IP address in the packe= t. Thanks Prasad -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Tuesday, June 30, 2015 2:43 PM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =20 > Another question I have is how do you forward these BFD packets from=20 > VTEP to VM? Since DIP =3D 127/8, I assume there is no way to forward=20 > such packets past the VTEP. We don't want to send it past VTEP as BFD will terminate at VTEP itself. Ri= ght now use of 127/8 is not really clear as inner IP address. We have again= added some text for inner IP address and its use.=20 >=20 > If you want to do VM to VM connectivity check then I suggest one of=20 > the > following: >=20 > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM=20 > between VMs > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over=20 > IP/UDP over Ethernet over VXLAN > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > 3a) If VTEP and VMs are physically in the same CPU core=20 > then run what you are proposing in this draft (1-hop BFD). Although it=20 > should give you same result as running BFD over the outer IP tunnel > 3b) If VTEP and VMs are physically separate (such as VTEP is=20 > in TOR and VM is CPU core), then run something similar to what you are=20 > proposing but with Multi-hop DIP address so that BFD can be forwarded to = VM from VTEP. >=20 We are not trying to address VM to VM connectivity check as I believe that = does not really need any changes and BFD as it is should run. Proposal is f= rom VTEP to VTEP. Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram=20 > Davari > Sent: Monday, June 29, 2015 4:15 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Greg, >=20 > I don't see much value in running BFD for SS-PW compared to running=20 > BFD over the LSP. >=20 > Thx > SD >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 2:21 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Shahram, > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW.=20 > True, we have case of MS-PW where PW label used (that was discussed in=20 > MPLS- TP in particular). But that doesn't mean that VCCV BFD has value=20 > only for MS- PW and for SS-PW has no value. Would you agree? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 2:02 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Greg, >=20 > You are welcome. Could you please clarify which one of the following=20 > is the packet format: >=20 > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD >=20 > Or >=20 > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD >=20 > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? >=20 > Also This is different from PW BFD, since in case of PW, there can be=20 > MS-PW, where the LSP BFD is not end-to-end. But in this case we don't=20 > have MS- VXLAN. > So the span of the VXLAN and the IP tunnel is the same. >=20 > In other words you have to specify in which part of forwarding the BFD=20 > the VXLAN Tag is used. If it is not used then it has no effect. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 1:51 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Shahram, > thank you for your comments to this proposal that make the discussion=20 > so much alive. > I think that processing of the VXLAN tag by VTEP before validating BFD=20 > is sufficient, in my view, level of verification. In VCCV BFD the PW=20 > label is not used for BFD forwarding but we find it useful as Service=20 > OAM in addition to RFC 5884, BFD over MPLS LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 10:39 AM > To: Vengada Prasad Govindan (venggovi) > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-=20 > bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi Prasad, >=20 > Is this a special type of BFD or standard BFD RFC 5880 and 5881)?=20 > Since standard BFD processing does no care where the BFD came from it=20 > only looks at "your discriminator" to update BFD state machine. >=20 > Also I don't see how many VXLANs can be checked via a single BFD session. > Could you please describe? >=20 > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP=20 > should not require BFD. Just use some query mechanism. Why do you need=20 > to run continuous BFD. >=20 > What you have to show me to convince me that your draft solves a real=20 > problem is to show that VXLAN tag is used for BFD forwarding.=20 > Otherwise BFD over the outer or Inner IP should give you all coverage nee= ded. >=20 >=20 > Thx > Shahram >=20 >=20 >=20 >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, June 29, 2015 3:11 AM > To: Shahram Davari > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-=20 > bfd@ietf.org > Subject: RE: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hello Shahram, > At the terminating VTEP, VxLAN information is used to consume the=20 > BFD packet. In other words, a BFD session increases the confidence of=20 > the existence of the VNI-Forwarding Domain mapping and the presence of=20 > valid VTEP termination configuration at the terminating VTEP. At the=20 > originating VTEP, it is a matter of implementation of how many VxLAN=20 > tables are exercised in the datapath (am aware of at least one=20 > implementation where it is being exercised to a considerable extent). >=20 > Thanks > Prasad >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Saturday, June 27, 2015 8:24 PM > To: Shahram Davari > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK=20 > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for=20 > draft-spallagatti-bfd-vxlan-00.txt >=20 > Hi >=20 > May be a better way to make this clear is to answer the following questio= n: >=20 > Where is the VXLAN tag information used in this BFD forwarding? >=20 > Thx > Shahram From nobody Tue Jun 30 09:22:45 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916491B2DED for ; Tue, 30 Jun 2015 09:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 fMk7dSp1GdSi for ; Tue, 30 Jun 2015 09:22:36 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 656FD1ACDD6 for ; Tue, 30 Jun 2015 09:22:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,378,1432623600"; d="scan'208";a="68875410" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 30 Jun 2015 10:22:25 -0700 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.235.1; Tue, 30 Jun 2015 09:22:35 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 09:22:35 -0700 From: Shahram Davari To: Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAIAAfQ6A//+NGiAAA9WOMAAjZ0AAAAA+bWA= Date: Tue, 30 Jun 2015 16:22:34 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@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: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:22:42 -0000 Santosh, But your draft says: " BFD session can be used to run between VM's for VM's connectivity check:" So, which one is it? VTEP-to-VTEP or VM- to-VM? Also what is the MAC-DA of inner Ethernet header? Thx Shahram -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Tuesday, June 30, 2015 2:13 AM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =20 > Another question I have is how do you forward these BFD packets from VTEP > to VM? Since DIP =3D 127/8, I assume there is no way to forward such pack= ets > past the VTEP. We don't want to send it past VTEP as BFD will terminate at VTEP itself. Ri= ght now use of 127/8 is not really clear as inner IP address. We have again= added some text for inner IP address and its use.=20 >=20 > If you want to do VM to VM connectivity check then I suggest one of the > following: >=20 > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM > between VMs > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over IP/UDP > over Ethernet over VXLAN > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > 3a) If VTEP and VMs are physically in the same CPU core then r= un what > you are proposing in this draft (1-hop BFD). Although it should give you = same > result as running BFD over the outer IP tunnel > 3b) If VTEP and VMs are physically separate (such as VTEP is in= TOR and > VM is CPU core), then run something similar to what you are proposing but > with Multi-hop DIP address so that BFD can be forwarded to VM from VTEP. >=20 We are not trying to address VM to VM connectivity check as I believe that = does not really need any changes and BFD as it is should run. Proposal is f= rom VTEP to VTEP. Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > Davari > Sent: Monday, June 29, 2015 4:15 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Greg, >=20 > I don't see much value in running BFD for SS-PW compared to running BFD > over the LSP. >=20 > Thx > SD >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 2:21 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. Tr= ue, > we have case of MS-PW where PW label used (that was discussed in MPLS- > TP in particular). But that doesn't mean that VCCV BFD has value only for= MS- > PW and for SS-PW has no value. Would you agree? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 2:02 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Greg, >=20 > You are welcome. Could you please clarify which one of the following is t= he > packet format: >=20 > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD >=20 > Or >=20 > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD >=20 > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? >=20 > Also This is different from PW BFD, since in case of PW, there can be MS-= PW, > where the LSP BFD is not end-to-end. But in this case we don't have MS- > VXLAN. > So the span of the VXLAN and the IP tunnel is the same. >=20 > In other words you have to specify in which part of forwarding the BFD th= e > VXLAN Tag is used. If it is not used then it has no effect. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 1:51 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > thank you for your comments to this proposal that make the discussion so > much alive. > I think that processing of the VXLAN tag by VTEP before validating BFD is > sufficient, in my view, level of verification. In VCCV BFD the PW label i= s not > used for BFD forwarding but we find it useful as Service OAM in addition = to > RFC 5884, BFD over MPLS LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 10:39 AM > To: Vengada Prasad Govindan (venggovi) > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Prasad, >=20 > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since > standard BFD processing does no care where the BFD came from it only look= s > at "your discriminator" to update BFD state machine. >=20 > Also I don't see how many VXLANs can be checked via a single BFD session. > Could you please describe? >=20 > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP shou= ld > not require BFD. Just use some query mechanism. Why do you need to run > continuous BFD. >=20 > What you have to show me to convince me that your draft solves a real > problem is to show that VXLAN tag is used for BFD forwarding. Otherwise > BFD over the outer or Inner IP should give you all coverage needed. >=20 >=20 > Thx > Shahram >=20 >=20 >=20 >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, June 29, 2015 3:11 AM > To: Shahram Davari > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Shahram, > At the terminating VTEP, VxLAN information is used to consume the BFD > packet. In other words, a BFD session increases the confidence of the > existence of the VNI-Forwarding Domain mapping and the presence of valid > VTEP termination configuration at the terminating VTEP. At the originatin= g > VTEP, it is a matter of implementation of how many VxLAN tables are > exercised in the datapath (am aware of at least one implementation where = it > is being exercised to a considerable extent). >=20 > Thanks > Prasad >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Saturday, June 27, 2015 8:24 PM > To: Shahram Davari > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi >=20 > May be a better way to make this clear is to answer the following questio= n: >=20 > Where is the VXLAN tag information used in this BFD forwarding? >=20 > Thx > Shahram From nobody Tue Jun 30 09:31:15 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DC31B2DD1 for ; Tue, 30 Jun 2015 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 n-DWH-JSEgCm for ; Tue, 30 Jun 2015 09:31:05 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB191ACE56 for ; Tue, 30 Jun 2015 09:31:02 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.15,379,1432623600"; d="scan'208,217"; a="68607676" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 30 Jun 2015 09:45:29 -0700 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.235.1; Tue, 30 Jun 2015 09:31:00 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 09:31:00 -0700 From: Shahram Davari To: Santosh P K , "S. Davari" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagAMGkYCAAdQzAIAAAodw Date: Tue, 30 Jun 2015 16:30:59 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F48743@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> 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_4A6CE49E6084B141B15C0713B8993F2831F48743SJEXCHMB12corpa_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:31:10 -0000 --_000_4A6CE49E6084B141B15C0713B8993F2831F48743SJEXCHMB12corpa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBraW5kIG9mIGxvb2t1cCBoYXBwZW5zIGluIHRoZXNlIHNlcnZpY2Ugbm9kZXM/IERvIHlv dSBkbyAoaW5uZXIgREEsIFZYTEFOL1ZOSSkgbG9va3VwPyBEbyB5b3Uga2VlcCB0aGUgVlhMQU4g b3IgZG8geW91IGNoYW5nZSBpdCB0byBuZXcgVlhMQU4/IFdoZXJlIGlzIHRoaXMgc2VydmljZSBu b2RlIG9wZXJhdGlvbiBzcGVjaWZpZWQ/DQoNClRoeA0KU0QNCg0KRnJvbTogU2FudG9zaCBQIEsg W21haWx0bzpzYW50b3NocGtAanVuaXBlci5uZXRdDQpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAy MDE1IDI6MTQgQU0NClRvOiBTLiBEYXZhcmk7IFNoYWhyYW0gRGF2YXJpOyBydGctYmZkQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFs bGFnYXR0aS1iZmQtdnhsYW4tMDAudHh0DQoNClRoZXJlIGNhbiBiZSBmZXcgVlRFUHMgd2hvIG1p Z2h0IGhhdmUgY2FwYWJpbGl0aWVzIHRvIG11bHRpY2FzdCB0aGUgcGFja2V0LiBJbiBzdWNoIGEg c2NlbmFyaW8gVlRFUCB3aWxsIHNlbmQgdGhhdCBwYWNrZXQgdG8gc2VydmljZSBub2RlIGFuZCBz ZXJ2aWNlIG5vZGUgd2lsbCBkbyBhIG11bHRpY2FzdCBvbiBpdHMgYmVoYWxmLg0KDQoNClRoYW5r cw0KU2FudG9zaCBQIEsNCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFMuIERhdmFyaQ0KU2VudDogTW9uZGF5LCBKdW5lIDI5LCAy MDE1IDEwOjQ4IEFNDQpUbzogU2hhaHJhbSBEYXZhcmk7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDAudHh0DQoNCkhpDQoNCldoYXQgaXMg YSBzZXJ2aWNlIG5vZGU/DQoNClRoeA0KDQpTZA0KDQoNCkhpIFByYXNhZCAsDQoNCkkgZG9uJ3Qg c2VlIGhvdyB5b3UgZ2V0IG1vcmUgY292ZXJhZ2UgaGF2aW5nIGEgVlhMQU4gdGFnLg0KDQpTaW5j ZSB5b3UgYXJlIG5vdCB0ZXN0aW5nIHRoZSBWWExBTiBiYXNlZCBWRkkvVlJGIGZvcndhcmRpbmcu IEJ5IHRoYXQgSSBtZWFuIHlvdSBhcmUgbm90IHRlc3RpbmcgKERBLCBWWExBTiApIG9yIChESVAs IFZYTEFOKSBmb3J3YXJkaW5nLg0KR1ZQMT4gT25lIG9mIHRoZSBhc3BlY3RzIG9mIHRoZSBuZXh0 IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHdpbGwgaGF2ZSBhIHZhbGlkIGlubmVyIERJUCBpbnN0ZWFk IG9mIDEyNy84LiBUaGlzIHNob3VsZCBoZWxwIGFkZHJlc3MgeW91ciBjb25jZXJuIHRvIGFuIGV4 dGVudC4NCkFsc28geW91IGFyZSBub3QgdGVzdGluZyB0aGUgbWFwcGluZyBmcm9tIEFDIChBdHRh Y2htZW50IENpcmN1aXQpIHRvIGEgVlhMQU4gdGFnLg0KR1ZQMT4gQWdyZWVkLCB0aGlzIGFzcGVj dCBoYXMgbm90ICh5ZXQpIGJlZW4gYWRkcmVzc2VkIGJ5IFJGQzU4ODQgYXMgd2VsbCwgbm90IHVz aW5nIGl0IGFzIGFuIGV4Y3VzZSBidXQgSSBhbSBqdXN0IG5vdGluZyB0aGUgcHJlY2VkZW50IGhl cmUuDQoNCkluIG15IG9waW5pb24gYWxsIHlvdSBhcmUgdGVzdGluZywgaXMgdGhhdCBhdCB0aGUg b3RoZXIgZW5kIG9mIGFuIElQIFR1bm5lbCBhIHNwZWNpZmljIFZYTEFOIGV4aXN0IG9yIG5vdC4g V2hpY2ggZG9lcyBub3QgcmVxdWlyZSBydW5uaW5nIGNvbnRpbnVvdXMgQkZELg0KR1ZQMT4gVGhl cmUgYXJlIHNwZWNpZmljIHVzZS1jYXNlcyAoc2VlIG5vdGUgYWJvdXQgU2VydmljZSBOb2RlIHJl YWNoYWJpbGl0eSBpbiBTZWMgMiBvZiB0aGUgZHJhZnQpIHRoYXQgcmVxdWlyZSBjb250aW51b3Vz IG1vbml0b3Jpbmcgb2Ygc29tZSBzcGVjaWFsLXB1cnBvc2UgVlRFUHMuDQoNCkluIG15IG9waW5p b24gdGhpcyBpcyBhIHZlcnkgaW4gZWZmaWNpZW50IHdheSBvZiBnZXR0aW5nIHRoYXQgaW5mb3Jt YXRpb24uIFRoZSBjb250cm9sbGVyIHNob3VsZCBiZSBhYmxlIHRvIGdldCB0aGlzIGluZm9ybWF0 aW9uIG11Y2ggbW9yZSBlZmZpY2llbnRseS4NCg0KSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2Fu IHByb3ZpZGUgYW4gZXhhbXBsZSBvZiB3aGF0IHlvdSB0aGluayBpcyBtb3JlIGNvdmVyYWdlIHRo YW4gQkZELiBPciBhdCBsZWFzdCB3aGF0IGV4dHJhIGNvdmVyYWdlIGRvIHlvdSBleGFjdGx5IGhh dmUgaW4gbWluZCwgc2luY2UgdGhpcyBkcmFmdCBpcyBub3QgY2FwYWJsZSBvZiBtb3JlIGNvdmVy YWdlIHRoYW4gc3RhbmRhcmQgQkZEIG92ZXIgdGhlIElQIHR1bm5lbC4NCg0KUmVnYXJkcywNClNo YWhyYW0NClJlZ2FyZHMsDQpTaGFocmFtDQoNCg0KT24gSnVuIDI3LCAyMDE1LCBhdCA3OjA2IEFN LCBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2Fk Y29tLmNvbT4+IHdyb3RlOg0KSGkgUHJhc2FkICwNCg0KSSBkb24ndCBzZWUgaG93IHlvdSBnZXQg bW9yZSBjb3ZlcmFnZSBoYXZpbmcgYSBWWExBTiB0YWcuDQoNClNpbmNlIHlvdSBhcmUgbm90IHRl c3RpbmcgdGhlIFZYTEFOIGJhc2VkIFZGSS9WUkYgZm9yd2FyZGluZy4gQnkgdGhhdCBJIG1lYW4g eW91IGFyZSBub3QgdGVzdGluZyAoREEsIFZYTEFOICkgb3IgKERJUCwgVlhMQU4pIGZvcndhcmRp bmcuDQpHVlAxPiBPbmUgb2YgdGhlIGFzcGVjdHMgb2YgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUg ZHJhZnQgd2lsbCBoYXZlIGEgdmFsaWQgaW5uZXIgRElQIGluc3RlYWQgb2YgMTI3LzguIFRoaXMg c2hvdWxkIGhlbHAgYWRkcmVzcyB5b3VyIGNvbmNlcm4gdG8gYW4gZXh0ZW50Lg0KQWxzbyB5b3Ug YXJlIG5vdCB0ZXN0aW5nIHRoZSBtYXBwaW5nIGZyb20gQUMgKEF0dGFjaG1lbnQgQ2lyY3VpdCkg dG8gYSBWWExBTiB0YWcuDQpHVlAxPiBBZ3JlZWQsIHRoaXMgYXNwZWN0IGhhcyBub3QgKHlldCkg YmVlbiBhZGRyZXNzZWQgYnkgUkZDNTg4NCBhcyB3ZWxsLCBub3QgdXNpbmcgaXQgYXMgYW4gZXhj dXNlIGJ1dCBJIGFtIGp1c3Qgbm90aW5nIHRoZSBwcmVjZWRlbnQgaGVyZS4NCg0KSW4gbXkgb3Bp bmlvbiBhbGwgeW91IGFyZSB0ZXN0aW5nLCBpcyB0aGF0IGF0IHRoZSBvdGhlciBlbmQgb2YgYW4g SVAgVHVubmVsIGEgc3BlY2lmaWMgVlhMQU4gZXhpc3Qgb3Igbm90LiBXaGljaCBkb2VzIG5vdCBy ZXF1aXJlIHJ1bm5pbmcgY29udGludW91cyBCRkQuDQpHVlAxPiBUaGVyZSBhcmUgc3BlY2lmaWMg dXNlLWNhc2VzIChzZWUgbm90ZSBhYm91dCBTZXJ2aWNlIE5vZGUgcmVhY2hhYmlsaXR5IGluIFNl YyAyIG9mIHRoZSBkcmFmdCkgdGhhdCByZXF1aXJlIGNvbnRpbnVvdXMgbW9uaXRvcmluZyBvZiBz b21lIHNwZWNpYWwtcHVycG9zZSBWVEVQcy4NCg0KSW4gbXkgb3BpbmlvbiB0aGlzIGlzIGEgdmVy eSBpbiBlZmZpY2llbnQgd2F5IG9mIGdldHRpbmcgdGhhdCBpbmZvcm1hdGlvbi4gVGhlIGNvbnRy b2xsZXIgc2hvdWxkIGJlIGFibGUgdG8gZ2V0IHRoaXMgaW5mb3JtYXRpb24gbXVjaCBtb3JlIGVm ZmljaWVudGx5Lg0KDQpJdCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjYW4gcHJvdmlkZSBhbiBleGFt cGxlIG9mIHdoYXQgeW91IHRoaW5rIGlzIG1vcmUgY292ZXJhZ2UgdGhhbiBCRkQuIE9yIGF0IGxl YXN0IHdoYXQgZXh0cmEgY292ZXJhZ2UgZG8geW91IGV4YWN0bHkgaGF2ZSBpbiBtaW5kLCBzaW5j ZSB0aGlzIGRyYWZ0IGlzIG5vdCBjYXBhYmxlIG9mIG1vcmUgY292ZXJhZ2UgdGhhbiBzdGFuZGFy ZCBCRkQgb3ZlciB0aGUgSVAgdHVubmVsLg0KDQpSZWdhcmRzLA0KU2hhaHJhbQ0K --_000_4A6CE49E6084B141B15C0713B8993F2831F48743SJEXCHMB12corpa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hhdCBraW5kIG9mIGxvb2t1cCBoYXBw ZW5zIGluIHRoZXNlIHNlcnZpY2Ugbm9kZXM/IERvIHlvdSBkbyAoaW5uZXIgREEsIFZYTEFOL1ZO SSkgbG9va3VwPyBEbyB5b3Uga2VlcCB0aGUgVlhMQU4gb3IgZG8geW91IGNoYW5nZSBpdCB0byBu ZXcgVlhMQU4/IFdoZXJlIGlzDQogdGhpcyBzZXJ2aWNlIG5vZGUgb3BlcmF0aW9uIHNwZWNpZmll ZD8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaHg8YnI+DQpTRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNhbnRvc2ggUCBL IFttYWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIEp1bmUgMzAsIDIwMTUgMjoxNCBBTTxicj4NCjxiPlRvOjwvYj4gUy4gRGF2YXJpOyBTaGFo cmFtIERhdmFyaTsgcnRnLWJmZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDAu dHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGNhbiBiZSBmZXcgVlRF UHMgd2hvIG1pZ2h0IGhhdmUgY2FwYWJpbGl0aWVzIHRvIG11bHRpY2FzdCB0aGUgcGFja2V0LiBJ biBzdWNoIGEgc2NlbmFyaW8gVlRFUCB3aWxsIHNlbmQgdGhhdCBwYWNrZXQgdG8gc2VydmljZSBu b2RlIGFuZCBzZXJ2aWNlIG5vZGUgd2lsbA0KIGRvIGEgbXVsdGljYXN0IG9uIGl0cyBiZWhhbGYu IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TYW50b3NoIFAgSw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLWJmZCBbPGEgaHJlZj0ibWFpbHRv OnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlMuIERhdmFyaTxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIEp1bmUgMjksIDIwMTUgMTA6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IFNoYWhyYW0gRGF2 YXJpOyA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGlzIGEgc2VydmljZSBub2RlPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaHg8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Q8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgUHJhc2FkICw8YnI+DQo8YnI+DQpJIGRvbid0 IHNlZSBob3cgeW91IGdldCBtb3JlIGNvdmVyYWdlIGhhdmluZyBhIFZYTEFOIHRhZy4mbmJzcDs8 YnI+DQo8YnI+DQpTaW5jZSB5b3UgYXJlIG5vdCB0ZXN0aW5nIHRoZSBWWExBTiBiYXNlZCBWRkkv VlJGIGZvcndhcmRpbmcuIEJ5IHRoYXQgSSBtZWFuIHlvdSBhcmUgbm90IHRlc3RpbmcgKERBLCBW WExBTiApIG9yIChESVAsIFZYTEFOKSBmb3J3YXJkaW5nLjxicj4NCkdWUDEmZ3Q7IE9uZSBvZiB0 aGUgYXNwZWN0cyBvZiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxsIGhhdmUgYSB2 YWxpZCBpbm5lciBESVAgaW5zdGVhZCBvZiAxMjcvOC4gVGhpcyBzaG91bGQgaGVscCBhZGRyZXNz IHlvdXIgY29uY2VybiB0byBhbiBleHRlbnQuPGJyPg0KQWxzbyB5b3UgYXJlIG5vdCB0ZXN0aW5n IHRoZSBtYXBwaW5nIGZyb20gQUMgKEF0dGFjaG1lbnQgQ2lyY3VpdCkgdG8gYSBWWExBTiB0YWcu Jm5ic3A7PGJyPg0KR1ZQMSZndDsgQWdyZWVkLCB0aGlzIGFzcGVjdCBoYXMgbm90ICh5ZXQpIGJl ZW4gYWRkcmVzc2VkIGJ5IFJGQzU4ODQgYXMgd2VsbCwgbm90IHVzaW5nIGl0IGFzIGFuIGV4Y3Vz ZSBidXQgSSBhbSBqdXN0IG5vdGluZyB0aGUgcHJlY2VkZW50IGhlcmUuPGJyPg0KPGJyPg0KSW4g bXkgb3BpbmlvbiBhbGwgeW91IGFyZSB0ZXN0aW5nLCBpcyB0aGF0IGF0IHRoZSBvdGhlciBlbmQg b2YgYW4gSVAgVHVubmVsIGEgc3BlY2lmaWMgVlhMQU4gZXhpc3Qgb3Igbm90LiBXaGljaCBkb2Vz IG5vdCByZXF1aXJlIHJ1bm5pbmcgY29udGludW91cyBCRkQuPGJyPg0KR1ZQMSZndDsgVGhlcmUg YXJlIHNwZWNpZmljIHVzZS1jYXNlcyAoc2VlIG5vdGUgYWJvdXQgU2VydmljZSBOb2RlIHJlYWNo YWJpbGl0eSBpbiBTZWMgMiBvZiB0aGUgZHJhZnQpIHRoYXQgcmVxdWlyZSBjb250aW51b3VzIG1v bml0b3Jpbmcgb2Ygc29tZSBzcGVjaWFsLXB1cnBvc2UgVlRFUHMuPGJyPg0KPGJyPg0KSW4gbXkg b3BpbmlvbiB0aGlzIGlzIGEgdmVyeSBpbiBlZmZpY2llbnQgd2F5IG9mIGdldHRpbmcgdGhhdCBp bmZvcm1hdGlvbi4gVGhlIGNvbnRyb2xsZXIgc2hvdWxkIGJlIGFibGUgdG8gZ2V0IHRoaXMgaW5m b3JtYXRpb24gbXVjaCBtb3JlIGVmZmljaWVudGx5LiZuYnNwOzxicj4NCjxicj4NCkl0IHdvdWxk IGJlIGdvb2QgaWYgeW91IGNhbiBwcm92aWRlIGFuIGV4YW1wbGUgb2Ygd2hhdCB5b3UgdGhpbmsg aXMgbW9yZSBjb3ZlcmFnZSB0aGFuIEJGRC4gT3IgYXQgbGVhc3Qgd2hhdCBleHRyYSBjb3ZlcmFn ZSBkbyB5b3UgZXhhY3RseSBoYXZlIGluIG1pbmQsIHNpbmNlIHRoaXMgZHJhZnQgaXMgbm90IGNh cGFibGUgb2YgbW9yZSBjb3ZlcmFnZSB0aGFuIHN0YW5kYXJkIEJGRCBvdmVyIHRoZSBJUCB0dW5u ZWwuJm5ic3A7PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpTaGFocmFtPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaGFocmFtPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4gMjcsIDIwMTUsIGF0IDc6MDYg QU0sIFNoYWhyYW0gRGF2YXJpICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNv bSI+ZGF2YXJpQGJyb2FkY29tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFByYXNhZCAsPGJyPg0KPGJyPg0KSSBkb24n dCBzZWUgaG93IHlvdSBnZXQgbW9yZSBjb3ZlcmFnZSBoYXZpbmcgYSBWWExBTiB0YWcuIDxicj4N Cjxicj4NClNpbmNlIHlvdSBhcmUgbm90IHRlc3RpbmcgdGhlIFZYTEFOIGJhc2VkIFZGSS9WUkYg Zm9yd2FyZGluZy4gQnkgdGhhdCBJIG1lYW4geW91IGFyZSBub3QgdGVzdGluZyAoREEsIFZYTEFO ICkgb3IgKERJUCwgVlhMQU4pIGZvcndhcmRpbmcuPGJyPg0KR1ZQMSZndDsgT25lIG9mIHRoZSBh c3BlY3RzIG9mIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHdpbGwgaGF2ZSBhIHZhbGlk IGlubmVyIERJUCBpbnN0ZWFkIG9mIDEyNy84LiBUaGlzIHNob3VsZCBoZWxwIGFkZHJlc3MgeW91 ciBjb25jZXJuIHRvIGFuIGV4dGVudC48YnI+DQpBbHNvIHlvdSBhcmUgbm90IHRlc3RpbmcgdGhl IG1hcHBpbmcgZnJvbSBBQyAoQXR0YWNobWVudCBDaXJjdWl0KSB0byBhIFZYTEFOIHRhZy4NCjxi cj4NCkdWUDEmZ3Q7IEFncmVlZCwgdGhpcyBhc3BlY3QgaGFzIG5vdCAoeWV0KSBiZWVuIGFkZHJl c3NlZCBieSBSRkM1ODg0IGFzIHdlbGwsIG5vdCB1c2luZyBpdCBhcyBhbiBleGN1c2UgYnV0IEkg YW0ganVzdCBub3RpbmcgdGhlIHByZWNlZGVudCBoZXJlLjxicj4NCjxicj4NCkluIG15IG9waW5p b24gYWxsIHlvdSBhcmUgdGVzdGluZywgaXMgdGhhdCBhdCB0aGUgb3RoZXIgZW5kIG9mIGFuIElQ IFR1bm5lbCBhIHNwZWNpZmljIFZYTEFOIGV4aXN0IG9yIG5vdC4gV2hpY2ggZG9lcyBub3QgcmVx dWlyZSBydW5uaW5nIGNvbnRpbnVvdXMgQkZELjxicj4NCkdWUDEmZ3Q7IFRoZXJlIGFyZSBzcGVj aWZpYyB1c2UtY2FzZXMgKHNlZSBub3RlIGFib3V0IFNlcnZpY2UgTm9kZSByZWFjaGFiaWxpdHkg aW4gU2VjIDIgb2YgdGhlIGRyYWZ0KSB0aGF0IHJlcXVpcmUgY29udGludW91cyBtb25pdG9yaW5n IG9mIHNvbWUgc3BlY2lhbC1wdXJwb3NlIFZURVBzLjxicj4NCjxicj4NCkluIG15IG9waW5pb24g dGhpcyBpcyBhIHZlcnkgaW4gZWZmaWNpZW50IHdheSBvZiBnZXR0aW5nIHRoYXQgaW5mb3JtYXRp b24uIFRoZSBjb250cm9sbGVyIHNob3VsZCBiZSBhYmxlIHRvIGdldCB0aGlzIGluZm9ybWF0aW9u IG11Y2ggbW9yZSBlZmZpY2llbnRseS4NCjxicj4NCjxicj4NCkl0IHdvdWxkIGJlIGdvb2QgaWYg eW91IGNhbiBwcm92aWRlIGFuIGV4YW1wbGUgb2Ygd2hhdCB5b3UgdGhpbmsgaXMgbW9yZSBjb3Zl cmFnZSB0aGFuIEJGRC4gT3IgYXQgbGVhc3Qgd2hhdCBleHRyYSBjb3ZlcmFnZSBkbyB5b3UgZXhh Y3RseSBoYXZlIGluIG1pbmQsIHNpbmNlIHRoaXMgZHJhZnQgaXMgbm90IGNhcGFibGUgb2YgbW9y ZSBjb3ZlcmFnZSB0aGFuIHN0YW5kYXJkIEJGRCBvdmVyIHRoZSBJUCB0dW5uZWwuDQo8YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NClNoYWhyYW08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A6CE49E6084B141B15C0713B8993F2831F48743SJEXCHMB12corpa_-- From nobody Tue Jun 30 09:34:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E731B2E6C for ; Tue, 30 Jun 2015 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 ssqfaXEmRdaW for ; Tue, 30 Jun 2015 09:34:35 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 18AE51ACE42 for ; Tue, 30 Jun 2015 09:34:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,379,1432623600"; d="scan'208";a="68753649" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 30 Jun 2015 09:50:12 -0700 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.235.1; Tue, 30 Jun 2015 09:34:34 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 09:34:34 -0700 From: Shahram Davari To: Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAIABQqCAgAAHMAA= Date: Tue, 30 Jun 2015 16:34:33 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F487A1@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@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: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:34:36 -0000 Hi, You can do (1) today. Why do you need a standard? Thx Shahram -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Tuesday, June 30, 2015 2:08 AM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Shahram, =20 >=20 > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD >=20 > Or >=20 > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD >=20 > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? >=20 It is 1) we have next version of this draft which address that part.=20 Thanks Santosh P K=20 >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 1:51 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > thank you for your comments to this proposal that make the discussion so > much alive. > I think that processing of the VXLAN tag by VTEP before validating BFD is > sufficient, in my view, level of verification. In VCCV BFD the PW label i= s not > used for BFD forwarding but we find it useful as Service OAM in addition = to > RFC 5884, BFD over MPLS LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 10:39 AM > To: Vengada Prasad Govindan (venggovi) > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Prasad, >=20 > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since > standard BFD processing does no care where the BFD came from it only look= s > at "your discriminator" to update BFD state machine. >=20 > Also I don't see how many VXLANs can be checked via a single BFD session. > Could you please describe? >=20 > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP shou= ld > not require BFD. Just use some query mechanism. Why do you need to run > continuous BFD. >=20 > What you have to show me to convince me that your draft solves a real > problem is to show that VXLAN tag is used for BFD forwarding. Otherwise > BFD over the outer or Inner IP should give you all coverage needed. >=20 >=20 > Thx > Shahram >=20 >=20 >=20 >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, June 29, 2015 3:11 AM > To: Shahram Davari > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Shahram, > At the terminating VTEP, VxLAN information is used to consume the BFD > packet. In other words, a BFD session increases the confidence of the > existence of the VNI-Forwarding Domain mapping and the presence of valid > VTEP termination configuration at the terminating VTEP. At the originatin= g > VTEP, it is a matter of implementation of how many VxLAN tables are > exercised in the datapath (am aware of at least one implementation where = it > is being exercised to a considerable extent). >=20 > Thanks > Prasad >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Saturday, June 27, 2015 8:24 PM > To: Shahram Davari > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi >=20 > May be a better way to make this clear is to answer the following questio= n: >=20 > Where is the VXLAN tag information used in this BFD forwarding? >=20 > Thx > Shahram From nobody Tue Jun 30 09:56:23 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CCF1ACE5F for ; Tue, 30 Jun 2015 09:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 0KBQm4CVuPRY for ; Tue, 30 Jun 2015 09:56:20 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 007DB1A8A68 for ; Tue, 30 Jun 2015 09:56:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,379,1432623600"; d="scan'208";a="68756366" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 30 Jun 2015 10:11:57 -0700 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.235.1; Tue, 30 Jun 2015 09:56:19 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 09:56:19 -0700 From: Shahram Davari To: Shahram Davari , Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAIAAfQ6A//+NGiAAA9WOMAAjZ0AAAAA+bWAAAPjFkA== Date: Tue, 30 Jun 2015 16:56:18 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F4886A@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:56:22 -0000 Hi, Assuming you want to do VTEP-to-VTEP connectivity, The only way that I thin= k this draft can provide extra information compared to running BFD over the= outer IP tunnel, is when the Inner MAC-DA is the MAC-DA of the VTEP port t= hat connects to the VM. In such case the packet will exercise the VXLAN/VNI= forwarding (DA, VXLAN/VNI) and then the inner L2 is terminated at the VTEP= port connecting VTEP to VM and BFD is extracted and processed. Basically s= ome kind of UP-MEP on the VTEP. This can be extended to VM-to-VM connectivity by setting he DA of inner L2 = to the MAC address of the VM.=20 In both these cases I don't think any standard is needed. It is just runnin= g 1-hop BFD over L2, which happens to be carried over VXLAN. Thx SD -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Tuesday, June 30, 2015 9:23 AM To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Santosh, But your draft says: " BFD session can be used to run between VM's for VM's connectivity check:" So, which one is it? VTEP-to-VTEP or VM- to-VM? Also what is the MAC-DA of inner Ethernet header? Thx Shahram -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Tuesday, June 30, 2015 2:13 AM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t =20 > Another question I have is how do you forward these BFD packets from VTEP > to VM? Since DIP =3D 127/8, I assume there is no way to forward such pack= ets > past the VTEP. We don't want to send it past VTEP as BFD will terminate at VTEP itself. Ri= ght now use of 127/8 is not really clear as inner IP address. We have again= added some text for inner IP address and its use.=20 >=20 > If you want to do VM to VM connectivity check then I suggest one of the > following: >=20 > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM > between VMs > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over IP/UDP > over Ethernet over VXLAN > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > 3a) If VTEP and VMs are physically in the same CPU core then r= un what > you are proposing in this draft (1-hop BFD). Although it should give you = same > result as running BFD over the outer IP tunnel > 3b) If VTEP and VMs are physically separate (such as VTEP is in= TOR and > VM is CPU core), then run something similar to what you are proposing but > with Multi-hop DIP address so that BFD can be forwarded to VM from VTEP. >=20 We are not trying to address VM to VM connectivity check as I believe that = does not really need any changes and BFD as it is should run. Proposal is f= rom VTEP to VTEP. Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > Davari > Sent: Monday, June 29, 2015 4:15 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Greg, >=20 > I don't see much value in running BFD for SS-PW compared to running BFD > over the LSP. >=20 > Thx > SD >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 2:21 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. Tr= ue, > we have case of MS-PW where PW label used (that was discussed in MPLS- > TP in particular). But that doesn't mean that VCCV BFD has value only for= MS- > PW and for SS-PW has no value. Would you agree? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 2:02 PM > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Greg, >=20 > You are welcome. Could you please clarify which one of the following is t= he > packet format: >=20 > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD >=20 > Or >=20 > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD >=20 > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? >=20 > Also This is different from PW BFD, since in case of PW, there can be MS-= PW, > where the LSP BFD is not end-to-end. But in this case we don't have MS- > VXLAN. > So the span of the VXLAN and the IP tunnel is the same. >=20 > In other words you have to specify in which part of forwarding the BFD th= e > VXLAN Tag is used. If it is not used then it has no effect. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, June 29, 2015 1:51 PM > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Shahram, > thank you for your comments to this proposal that make the discussion so > much alive. > I think that processing of the VXLAN tag by VTEP before validating BFD is > sufficient, in my view, level of verification. In VCCV BFD the PW label i= s not > used for BFD forwarding but we find it useful as Service OAM in addition = to > RFC 5884, BFD over MPLS LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 29, 2015 10:39 AM > To: Vengada Prasad Govindan (venggovi) > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi Prasad, >=20 > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since > standard BFD processing does no care where the BFD came from it only look= s > at "your discriminator" to update BFD state machine. >=20 > Also I don't see how many VXLANs can be checked via a single BFD session. > Could you please describe? >=20 > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP shou= ld > not require BFD. Just use some query mechanism. Why do you need to run > continuous BFD. >=20 > What you have to show me to convince me that your draft solves a real > problem is to show that VXLAN tag is used for BFD forwarding. Otherwise > BFD over the outer or Inner IP should give you all coverage needed. >=20 >=20 > Thx > Shahram >=20 >=20 >=20 >=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, June 29, 2015 3:11 AM > To: Shahram Davari > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hello Shahram, > At the terminating VTEP, VxLAN information is used to consume the BFD > packet. In other words, a BFD session increases the confidence of the > existence of the VNI-Forwarding Domain mapping and the presence of valid > VTEP termination configuration at the terminating VTEP. At the originatin= g > VTEP, it is a matter of implementation of how many VxLAN tables are > exercised in the datapath (am aware of at least one implementation where = it > is being exercised to a considerable extent). >=20 > Thanks > Prasad >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Saturday, June 27, 2015 8:24 PM > To: Shahram Davari > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Hi >=20 > May be a better way to make this clear is to answer the following questio= n: >=20 > Where is the VXLAN tag information used in this BFD forwarding? >=20 > Thx > Shahram From nobody Tue Jun 30 10:19:54 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758141B2A02 for ; Tue, 30 Jun 2015 10:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bKUccGimp6Fi for ; Tue, 30 Jun 2015 10:19:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260401B29C5 for ; Tue, 30 Jun 2015 10:19:39 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 17:19:32 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 17:19:32 +0000 From: Santosh P K To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAANTYCAAtWcAIAAfT2AgAA1qQCAAAMjAIAABReAgAAf8wCAAAUGgIAAoKVAgAB5dgCAAA9UMA== Date: Tue, 30 Jun 2015 17:19:31 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1760; 5:y4GOMu3UXCRvXtTS1KvNulMyAvLcfAa4kkKkGYgPXQ97gz+lQGixYYGBs21ygklvITVBk5+Qk3Kf1HQyQg92x9dtaU8GmXamEoAzthvZCCglQW8VFaNfBopVxT1c40ONE2oWu+wmPh4OtCEzLE0dxg==; 24:LCXighh1tBbT8A+OeqSV8EaKn/RLk1U1EEf28sBckLErxPMWyXtA/XPFQMCQXItIv1+zTwrF82N3X0+jqw0cH2d9ykMQ9xikh50dmoPxylM=; 20:/Ou49p20pyba7Jmh4mjcgsiG0dly9ZX+mR+8ighb1oLKck+EXVcIFlFmlL7iNpQlrQzpYOYVk0aXbzSfHodvDg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1760; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1760; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1760; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51444003)(51704005)(13464003)(377454003)(74316001)(122556002)(40100003)(50986999)(19580395003)(97736004)(86362001)(92566002)(76576001)(5003600100002)(66066001)(68736005)(102836002)(2900100001)(62966003)(2950100001)(77096005)(77156002)(93886004)(106356001)(561944003)(46102003)(33656002)(5002640100001)(5001960100002)(5001770100001)(2656002)(19580405001)(230783001)(106116001)(99286002)(76176999)(189998001)(87936001)(54356999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1760; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 17:19:31.6118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1760 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:19:43 -0000 Shahram, Thanks for your comments. > But your draft says: >=20 > " BFD session can be used to run between VM's for VM's connectivity check= :" >=20 > So, which one is it? VTEP-to-VTEP or VM- to-VM? >=20 There had been confusion on how the use case was written in first version o= f the draft. This has been corrected in next revision and intent is made cl= ear that BFD session in this draft suggests to run only between VTEP to VTE= P.=20 > Also what is the MAC-DA of inner Ethernet header? This was missed in our previous version which is again addressed. MAC-DA wo= uld be MAC of the destination VTEP or dedicated MAC address.=20 Thanks Santosh P K=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Tuesday, June 30, 2015 2:13 AM > To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 >=20 > > Another question I have is how do you forward these BFD packets from > > VTEP to VM? Since DIP =3D 127/8, I assume there is no way to forward > > such packets past the VTEP. >=20 > We don't want to send it past VTEP as BFD will terminate at VTEP itself. = Right > now use of 127/8 is not really clear as inner IP address. We have again a= dded > some text for inner IP address and its use. >=20 >=20 > > > > If you want to do VM to VM connectivity check then I suggest one of > > the > > following: > > > > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM > > between VMs > > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over > > IP/UDP over Ethernet over VXLAN > > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > > 3a) If VTEP and VMs are physically in the same CPU core > > then run what you are proposing in this draft (1-hop BFD). Although it > > should give you same result as running BFD over the outer IP tunnel > > 3b) If VTEP and VMs are physically separate (such as VTEP is > > in TOR and VM is CPU core), then run something similar to what you are > > proposing but with Multi-hop DIP address so that BFD can be forwarded t= o > VM from VTEP. > > >=20 > We are not trying to address VM to VM connectivity check as I believe tha= t > does not really need any changes and BFD as it is should run. Proposal is= from > VTEP to VTEP. >=20 >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > > Davari > > Sent: Monday, June 29, 2015 4:15 PM > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > > Cc: rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Greg, > > > > I don't see much value in running BFD for SS-PW compared to running > > BFD over the LSP. > > > > Thx > > SD > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 2:21 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. > > True, we have case of MS-PW where PW label used (that was discussed in > > MPLS- TP in particular). But that doesn't mean that VCCV BFD has value > > only for MS- PW and for SS-PW has no value. Would you agree? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 2:02 PM > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Greg, > > > > You are welcome. Could you please clarify which one of the following > > is the packet format: > > > > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD > > > > Or > > > > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD > > > > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? > > > > Also This is different from PW BFD, since in case of PW, there can be > > MS-PW, where the LSP BFD is not end-to-end. But in this case we don't > > have MS- VXLAN. > > So the span of the VXLAN and the IP tunnel is the same. > > > > In other words you have to specify in which part of forwarding the BFD > > the VXLAN Tag is used. If it is not used then it has no effect. > > > > Thx > > Shahram > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 1:51 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > thank you for your comments to this proposal that make the discussion > > so much alive. > > I think that processing of the VXLAN tag by VTEP before validating BFD > > is sufficient, in my view, level of verification. In VCCV BFD the PW > > label is not used for BFD forwarding but we find it useful as Service > > OAM in addition to RFC 5884, BFD over MPLS LSP. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 10:39 AM > > To: Vengada Prasad Govindan (venggovi) > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Prasad, > > > > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? > > Since standard BFD processing does no care where the BFD came from it > > only looks at "your discriminator" to update BFD state machine. > > > > Also I don't see how many VXLANs can be checked via a single BFD sessio= n. > > Could you please describe? > > > > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP > > should not require BFD. Just use some query mechanism. Why do you > need > > to run continuous BFD. > > > > What you have to show me to convince me that your draft solves a real > > problem is to show that VXLAN tag is used for BFD forwarding. > > Otherwise BFD over the outer or Inner IP should give you all coverage > needed. > > > > > > Thx > > Shahram > > > > > > > > > > -----Original Message----- > > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > > Sent: Monday, June 29, 2015 3:11 AM > > To: Shahram Davari > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hello Shahram, > > At the terminating VTEP, VxLAN information is used to consume the > > BFD packet. In other words, a BFD session increases the confidence of > > the existence of the VNI-Forwarding Domain mapping and the presence of > > valid VTEP termination configuration at the terminating VTEP. At the > > originating VTEP, it is a matter of implementation of how many VxLAN > > tables are exercised in the datapath (am aware of at least one > > implementation where it is being exercised to a considerable extent). > > > > Thanks > > Prasad > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Saturday, June 27, 2015 8:24 PM > > To: Shahram Davari > > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: Re: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi > > > > May be a better way to make this clear is to answer the following quest= ion: > > > > Where is the VXLAN tag information used in this BFD forwarding? > > > > Thx > > Shahram From nobody Tue Jun 30 10:22:04 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19701ACD17 for ; Tue, 30 Jun 2015 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z45NvmlB1x0R for ; Tue, 30 Jun 2015 10:22:01 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACB11AD063 for ; Tue, 30 Jun 2015 10:21:49 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1759.namprd05.prod.outlook.com (10.163.130.26) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 17:21:44 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 17:21:44 +0000 From: Santosh P K To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAANTYCAAtWcAIAAfT2AgAA1qQCAAAMjAIAAymwAgAB9GICAAAyvMA== Date: Tue, 30 Jun 2015 17:21:44 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F487A1@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F487A1@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadcom.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1759; 5:s2kpbVTUO0kK3aqkLm3at3kBG06yQbfaf1rjNwQOlGotwkZYRfZOh3WkQEKzNbRvD6mfyuC3Q86cC1+rC6F8XnQX8e2GDWwO0jC+I15N21kUy8v+1rjaQJ6PKMIcTjb9/PCFF4BA4xngNA96Kidv0A==; 24:1Vg70gSgCM8uLAXwOnL2uHAn9nsU5Iu2ZM7VUS9uCIEEY4Ts8iD0M4JRicQ1vw00RtjN3BpYeDd9f70QY+gc04ZokK41lK7weiQilnP6QEU=; 20:PLA+z9fxRWSMip5ruu8TDb8mFr9O2Wb4SUZRz+NfJPeVNcIpKlZgHktY1uAY4gN8raTvZSlB7wfuyNbz5D3QLA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1759; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1759; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51704005)(33656002)(561944003)(122556002)(2656002)(5002640100001)(102836002)(77156002)(2950100001)(99286002)(50986999)(54356999)(106116001)(87936001)(19580395003)(62966003)(2900100001)(66066001)(230783001)(76576001)(5001960100002)(5001920100001)(5001770100001)(86362001)(189998001)(92566002)(74316001)(76176999)(77096005)(5003600100002)(46102003)(40100003)(19580405001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1759; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 17:21:44.6326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1759 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:22:03 -0000 Shahram, > You can do (1) today. Why do you need a standard? >=20 1) with BFD terminating on VTEP needs changes. For example how a BFD is dem= uxed when it comes with your_disc =3D 0. What should be inner MAC-DA, inner= dst-IP changes. So we need to specify in document.=20 Thanks Santosh P K >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Tuesday, June 30, 2015 2:08 AM > To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Shahram, >=20 > > > > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD > > > > Or > > > > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD > > > > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? > > >=20 > It is 1) we have next version of this draft which address that part. >=20 >=20 > Thanks > Santosh P K >=20 >=20 > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 1:51 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > thank you for your comments to this proposal that make the discussion > > so much alive. > > I think that processing of the VXLAN tag by VTEP before validating BFD > > is sufficient, in my view, level of verification. In VCCV BFD the PW > > label is not used for BFD forwarding but we find it useful as Service > > OAM in addition to RFC 5884, BFD over MPLS LSP. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 10:39 AM > > To: Vengada Prasad Govindan (venggovi) > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Prasad, > > > > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? > > Since standard BFD processing does no care where the BFD came from it > > only looks at "your discriminator" to update BFD state machine. > > > > Also I don't see how many VXLANs can be checked via a single BFD sessio= n. > > Could you please describe? > > > > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP > > should not require BFD. Just use some query mechanism. Why do you > need > > to run continuous BFD. > > > > What you have to show me to convince me that your draft solves a real > > problem is to show that VXLAN tag is used for BFD forwarding. > > Otherwise BFD over the outer or Inner IP should give you all coverage > needed. > > > > > > Thx > > Shahram > > > > > > > > > > -----Original Message----- > > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > > Sent: Monday, June 29, 2015 3:11 AM > > To: Shahram Davari > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hello Shahram, > > At the terminating VTEP, VxLAN information is used to consume the > > BFD packet. In other words, a BFD session increases the confidence of > > the existence of the VNI-Forwarding Domain mapping and the presence of > > valid VTEP termination configuration at the terminating VTEP. At the > > originating VTEP, it is a matter of implementation of how many VxLAN > > tables are exercised in the datapath (am aware of at least one > > implementation where it is being exercised to a considerable extent). > > > > Thanks > > Prasad > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Saturday, June 27, 2015 8:24 PM > > To: Shahram Davari > > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: Re: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi > > > > May be a better way to make this clear is to answer the following quest= ion: > > > > Where is the VXLAN tag information used in this BFD forwarding? > > > > Thx > > Shahram From nobody Tue Jun 30 10:27:43 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DB21A9117 for ; Tue, 30 Jun 2015 10:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gHpc6md9UgVt for ; Tue, 30 Jun 2015 10:27:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45421A90A6 for ; Tue, 30 Jun 2015 10:27:38 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1757.namprd05.prod.outlook.com (10.163.130.24) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 17:27:21 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 17:27:21 +0000 From: Santosh P K To: Shahram Davari , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAANTYCAAtWcAIAAfT2AgAA1qQCAAAMjAIAABReAgAAf8wCAAAUGgIAAoKVAgAB5dgCAAAlsAIAAB1gA Date: Tue, 30 Jun 2015 17:27:21 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F4886A@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F4886A@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadcom.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1757; 5:mrdKJTnZo820OGhlBxE7x6L0TWMTs256oBI7QR70XB9+33wMNDVdlPoags017Fe+XDDcwTly7MzIMcKT7Fy7aoXtMWZ9nzq+fSN88TFElnzATXYAEgVkqnCO/q1J0UjPzXSqYqahMFTHv6fSa1Dxaw==; 24:YxYTDuxF0s6MNAiyDHGkJnLAGwMmnyiu+uZb+GhtW0iocjx75uVTHiI6UdL3AlD1bJ4Jd1uWiPzskWfHWewUR+gt8xHdCJJSbA0Pi2ssGE0=; 20:m87eDOZt0CYAXhamt9hyelKg3bHv0rpbEUByvGrAz/yywCN28x9jTibfbJW8Yz4UeZA2htcPSbs6liaKHS9oXA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1757; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0501MB1757; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1757; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(106116001)(99286002)(87936001)(86362001)(46102003)(230783001)(33656002)(5002640100001)(561944003)(66066001)(5001770100001)(2656002)(76576001)(76176999)(92566002)(102836002)(50986999)(54356999)(189998001)(5001960100002)(77096005)(2900100001)(2950100001)(122556002)(62966003)(77156002)(5003600100002)(93886004)(40100003)(19580405001)(74316001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1757; H:SN1PR0501MB1760.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 17:27:21.2552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1757 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:27:42 -0000 Shahram, > Assuming you want to do VTEP-to-VTEP connectivity, The only way that I > think this draft can provide extra information compared to running BFD ov= er > the outer IP tunnel, is when the Inner MAC-DA is the MAC-DA of the VTEP > port that connects to the VM. In such case the packet will exercise the > VXLAN/VNI forwarding (DA, VXLAN/VNI) and then the inner L2 is terminated > at the VTEP port connecting VTEP to VM and BFD is extracted and processed= . > Basically some kind of UP-MEP on the VTEP. When you say that inner DA-MAC should be that of the MAC connecting to VM, = you mean the other side of the interface and not the receiving interface on= VTEP right? When we are verifying VTEP to VTEP connectivity packet has to= be absorbed by VTEP itself and when it does it needs to demux BFD packet w= ith some key and that would be VNI in the VXLAN header. This is what we are= talking about in the draft, maybe we are much more clear in the next vers= ion of the draft which will be published soon.=20 Thanks Santosh P K =20 >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > Davari > Sent: Tuesday, June 30, 2015 9:23 AM > To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Santosh, >=20 > But your draft says: >=20 > " BFD session can be used to run between VM's for VM's connectivity check= :" >=20 > So, which one is it? VTEP-to-VTEP or VM- to-VM? >=20 > Also what is the MAC-DA of inner Ethernet header? >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Tuesday, June 30, 2015 2:13 AM > To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 >=20 > > Another question I have is how do you forward these BFD packets from > > VTEP to VM? Since DIP =3D 127/8, I assume there is no way to forward > > such packets past the VTEP. >=20 > We don't want to send it past VTEP as BFD will terminate at VTEP itself. = Right > now use of 127/8 is not really clear as inner IP address. We have again a= dded > some text for inner IP address and its use. >=20 >=20 > > > > If you want to do VM to VM connectivity check then I suggest one of > > the > > following: > > > > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM > > between VMs > > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over > > IP/UDP over Ethernet over VXLAN > > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > > 3a) If VTEP and VMs are physically in the same CPU core > > then run what you are proposing in this draft (1-hop BFD). Although it > > should give you same result as running BFD over the outer IP tunnel > > 3b) If VTEP and VMs are physically separate (such as VTEP is > > in TOR and VM is CPU core), then run something similar to what you are > > proposing but with Multi-hop DIP address so that BFD can be forwarded t= o > VM from VTEP. > > >=20 > We are not trying to address VM to VM connectivity check as I believe tha= t > does not really need any changes and BFD as it is should run. Proposal is= from > VTEP to VTEP. >=20 >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > > Davari > > Sent: Monday, June 29, 2015 4:15 PM > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > > Cc: rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Greg, > > > > I don't see much value in running BFD for SS-PW compared to running > > BFD over the LSP. > > > > Thx > > SD > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 2:21 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. > > True, we have case of MS-PW where PW label used (that was discussed in > > MPLS- TP in particular). But that doesn't mean that VCCV BFD has value > > only for MS- PW and for SS-PW has no value. Would you agree? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 2:02 PM > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Greg, > > > > You are welcome. Could you please clarify which one of the following > > is the packet format: > > > > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD > > > > Or > > > > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD > > > > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? > > > > Also This is different from PW BFD, since in case of PW, there can be > > MS-PW, where the LSP BFD is not end-to-end. But in this case we don't > > have MS- VXLAN. > > So the span of the VXLAN and the IP tunnel is the same. > > > > In other words you have to specify in which part of forwarding the BFD > > the VXLAN Tag is used. If it is not used then it has no effect. > > > > Thx > > Shahram > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 1:51 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > thank you for your comments to this proposal that make the discussion > > so much alive. > > I think that processing of the VXLAN tag by VTEP before validating BFD > > is sufficient, in my view, level of verification. In VCCV BFD the PW > > label is not used for BFD forwarding but we find it useful as Service > > OAM in addition to RFC 5884, BFD over MPLS LSP. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 10:39 AM > > To: Vengada Prasad Govindan (venggovi) > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Prasad, > > > > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? > > Since standard BFD processing does no care where the BFD came from it > > only looks at "your discriminator" to update BFD state machine. > > > > Also I don't see how many VXLANs can be checked via a single BFD sessio= n. > > Could you please describe? > > > > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP > > should not require BFD. Just use some query mechanism. Why do you > need > > to run continuous BFD. > > > > What you have to show me to convince me that your draft solves a real > > problem is to show that VXLAN tag is used for BFD forwarding. > > Otherwise BFD over the outer or Inner IP should give you all coverage > needed. > > > > > > Thx > > Shahram > > > > > > > > > > -----Original Message----- > > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > > Sent: Monday, June 29, 2015 3:11 AM > > To: Shahram Davari > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hello Shahram, > > At the terminating VTEP, VxLAN information is used to consume the > > BFD packet. In other words, a BFD session increases the confidence of > > the existence of the VNI-Forwarding Domain mapping and the presence of > > valid VTEP termination configuration at the terminating VTEP. At the > > originating VTEP, it is a matter of implementation of how many VxLAN > > tables are exercised in the datapath (am aware of at least one > > implementation where it is being exercised to a considerable extent). > > > > Thanks > > Prasad > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Saturday, June 27, 2015 8:24 PM > > To: Shahram Davari > > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: Re: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi > > > > May be a better way to make this clear is to answer the following quest= ion: > > > > Where is the VXLAN tag information used in this BFD forwarding? > > > > Thx > > Shahram From nobody Tue Jun 30 10:53:32 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF5C1B29CE for ; Tue, 30 Jun 2015 10:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 DuFF8YA0ri-Q for ; Tue, 30 Jun 2015 10:53:28 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4621B2A38 for ; Tue, 30 Jun 2015 10:53:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,379,1432623600"; d="scan'208";a="68616350" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 30 Jun 2015 11:07:55 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 30 Jun 2015 10:53:25 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 10:53:25 -0700 From: Shahram Davari To: Santosh P K , Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagACCpoCAAtWcAIAABkDwgACspQD//4stAIAAfQ6A//+NGiAAA9WOMAAjZ0AAAAA+bWAAAPjFkAAQDm2AAA5ox7A= Date: Tue, 30 Jun 2015 17:53:25 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F48AD2@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <315041E4211CB84E86EF7C25A2AB583D5457F735@xmb-rcd-x15.cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F446F1@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F01E0@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F45E39@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF1121B9F021C@eusaamb106.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831F46420@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F464FB@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F486A1@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F4886A@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: [10.16.203.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:53:31 -0000 Santosh, -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Tuesday, June 30, 2015 10:27 AM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.tx= t Shahram, > Assuming you want to do VTEP-to-VTEP connectivity, The only way that I > think this draft can provide extra information compared to running BFD ov= er > the outer IP tunnel, is when the Inner MAC-DA is the MAC-DA of the VTEP > port that connects to the VM. In such case the packet will exercise the > VXLAN/VNI forwarding (DA, VXLAN/VNI) and then the inner L2 is terminated > at the VTEP port connecting VTEP to VM and BFD is extracted and processed= . > Basically some kind of UP-MEP on the VTEP. When you say that inner DA-MAC should be that of the MAC connecting to VM, = you mean the other side of the interface and not the receiving interface on= VTEP right? =20 SD>Correct. Doing so ensures VXLAN/VNI is exercised. Otherwise the VXLAN is= just a meta-data and it can be carried inside BFD packet (such as adding a= TLV). In fact you can create a BFD TLV and add many VXLANs to it and then = a single BFD session can test multiple VXLANs that start and terminate on s= ame VTEPs. SD> Assume there are 10 VXLAN/VNI between VTEP1 and VTEP2. Based on your dr= aft you want to run 1xBFD per VXLAN/VNI. So you have 10xBFD sessions in eac= h direction. My question is how are these BFD sessions different from each= other? In other words is there a case that some of these BFDs show connect= ivity and some don't? SD> Instead, why don't you run just 1 BFD session and list all VNI/VXLANs i= nside the BFD as a list. Basically aggregate. Since you are not using VNI/V= XLAN for any forwarding. You are just using it for demultipexing. When we are verifying VTEP to VTEP connectivity packet has to be absorbed b= y VTEP itself and when it does it needs to demux BFD packet with some key a= nd that would be VNI in the VXLAN header. This is what we are talking about= in the draft, maybe we are much more clear in the next version of the dra= ft which will be published soon.=20 SD> RFC 5881 supports what you need. This RFC applies to any Tunnel: "=20 This application of BFD can be used by any pair of systems communicating via IPv4 and/or IPv6 across a single IP hop that is associated with an incoming interface. This includes, but is not limited to, physical media, virtual circuits, and tunnels" Thx Shahram Thanks Santosh P K =20 >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > Davari > Sent: Tuesday, June 30, 2015 9:23 AM > To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 > Santosh, >=20 > But your draft says: >=20 > " BFD session can be used to run between VM's for VM's connectivity check= :" >=20 > So, which one is it? VTEP-to-VTEP or VM- to-VM? >=20 > Also what is the MAC-DA of inner Ethernet header? >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Tuesday, June 30, 2015 2:13 AM > To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi) > Cc: rtg-bfd@ietf.org > Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.= txt >=20 >=20 > > Another question I have is how do you forward these BFD packets from > > VTEP to VM? Since DIP =3D 127/8, I assume there is no way to forward > > such packets past the VTEP. >=20 > We don't want to send it past VTEP as BFD will terminate at VTEP itself. = Right > now use of 127/8 is not really clear as inner IP address. We have again a= dded > some text for inner IP address and its use. >=20 >=20 > > > > If you want to do VM to VM connectivity check then I suggest one of > > the > > following: > > > > 1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM > > between VMs > > 2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over > > IP/UDP over Ethernet over VXLAN > > 3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases: > > 3a) If VTEP and VMs are physically in the same CPU core > > then run what you are proposing in this draft (1-hop BFD). Although it > > should give you same result as running BFD over the outer IP tunnel > > 3b) If VTEP and VMs are physically separate (such as VTEP is > > in TOR and VM is CPU core), then run something similar to what you are > > proposing but with Multi-hop DIP address so that BFD can be forwarded t= o > VM from VTEP. > > >=20 > We are not trying to address VM to VM connectivity check as I believe tha= t > does not really need any changes and BFD as it is should run. Proposal is= from > VTEP to VTEP. >=20 >=20 > Thanks > Santosh P K >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram > > Davari > > Sent: Monday, June 29, 2015 4:15 PM > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > > Cc: rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Greg, > > > > I don't see much value in running BFD for SS-PW compared to running > > BFD over the LSP. > > > > Thx > > SD > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 2:21 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. > > True, we have case of MS-PW where PW label used (that was discussed in > > MPLS- TP in particular). But that doesn't mean that VCCV BFD has value > > only for MS- PW and for SS-PW has no value. Would you agree? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 2:02 PM > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Greg, > > > > You are welcome. Could you please clarify which one of the following > > is the packet format: > > > > 1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD > > > > Or > > > > 2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD > > > > If (2) hen how do you specify the VXLAN payload in IP and not Ethernet? > > > > Also This is different from PW BFD, since in case of PW, there can be > > MS-PW, where the LSP BFD is not end-to-end. But in this case we don't > > have MS- VXLAN. > > So the span of the VXLAN and the IP tunnel is the same. > > > > In other words you have to specify in which part of forwarding the BFD > > the VXLAN Tag is used. If it is not used then it has no effect. > > > > Thx > > Shahram > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, June 29, 2015 1:51 PM > > To: Shahram Davari; Vengada Prasad Govindan (venggovi) > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Shahram, > > thank you for your comments to this proposal that make the discussion > > so much alive. > > I think that processing of the VXLAN tag by VTEP before validating BFD > > is sufficient, in my view, level of verification. In VCCV BFD the PW > > label is not used for BFD forwarding but we find it useful as Service > > OAM in addition to RFC 5884, BFD over MPLS LSP. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Monday, June 29, 2015 10:39 AM > > To: Vengada Prasad Govindan (venggovi) > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi Prasad, > > > > Is this a special type of BFD or standard BFD RFC 5880 and 5881)? > > Since standard BFD processing does no care where the BFD came from it > > only looks at "your discriminator" to update BFD state machine. > > > > Also I don't see how many VXLANs can be checked via a single BFD sessio= n. > > Could you please describe? > > > > Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP > > should not require BFD. Just use some query mechanism. Why do you > need > > to run continuous BFD. > > > > What you have to show me to convince me that your draft solves a real > > problem is to show that VXLAN tag is used for BFD forwarding. > > Otherwise BFD over the outer or Inner IP should give you all coverage > needed. > > > > > > Thx > > Shahram > > > > > > > > > > -----Original Message----- > > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > > Sent: Monday, June 29, 2015 3:11 AM > > To: Shahram Davari > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg- > > bfd@ietf.org > > Subject: RE: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hello Shahram, > > At the terminating VTEP, VxLAN information is used to consume the > > BFD packet. In other words, a BFD session increases the confidence of > > the existence of the VNI-Forwarding Domain mapping and the presence of > > valid VTEP termination configuration at the terminating VTEP. At the > > originating VTEP, it is a matter of implementation of how many VxLAN > > tables are exercised in the datapath (am aware of at least one > > implementation where it is being exercised to a considerable extent). > > > > Thanks > > Prasad > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Saturday, June 27, 2015 8:24 PM > > To: Shahram Davari > > Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK > > MUDIGONDA (mmudigon); Santosh P K; rtg-bfd@ietf.org > > Subject: Re: New Version Notification for > > draft-spallagatti-bfd-vxlan-00.txt > > > > Hi > > > > May be a better way to make this clear is to answer the following quest= ion: > > > > Where is the VXLAN tag information used in this BFD forwarding? > > > > Thx > > Shahram From nobody Tue Jun 30 18:24:52 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC6E1A0210 for ; Tue, 30 Jun 2015 18:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 DvezXaB3QrY2 for ; Tue, 30 Jun 2015 18:24:48 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 736111A01FA for ; Tue, 30 Jun 2015 18:24:48 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.15,381,1432623600"; d="scan'208,217"; a="68797832" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 30 Jun 2015 18:40:29 -0700 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.235.1; Tue, 30 Jun 2015 18:24:48 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 18:24:48 -0700 From: Shahram Davari To: Santosh P K , "S. Davari" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggACjL4CAAAv0AP//jKHagAMGkYCAAdQzAIAAmPTA Date: Wed, 1 Jul 2015 01:24:47 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F4941F@SJEXCHMB12.corp.ad.broadcom.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> 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_4A6CE49E6084B141B15C0713B8993F2831F4941FSJEXCHMB12corpa_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 01:24:51 -0000 --_000_4A6CE49E6084B141B15C0713B8993F2831F4941FSJEXCHMB12corpa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FudG9zaCwNCg0KSXMgdGhlIEJGRCB5b3UgIGFyZSBkZXNjcmliaW5nIGluIHlvdXIgZHJhZnQg dW5pY2FzdCBvciBtdWx0aWNhc3Q/IElmIHVuaWNhc3QgdGhlbiBzZXJ2aWNlIG5vZGVzIHdvdWxk IG5vdCBhcHBseS4NCg0KQWxzbyBpZiB0aGVyZSBpcyBhIHNlcnZpY2Ugbm9kZSB0aGVuIG9uZSBj YW4gcnVuIEJGRCBvbiB0aGUgSVAgdHVubmVsIGJldHdlZW4gc291cmNlIFZURVAgYW5kIHNlcnZp Y2Ugbm9kZSBhbmQgYmV0d2VlbiBzZXJ2aWNlIG5vZGUgYW5kIHRoZSBkZXN0aW5hdGlvbiBWVEVQ LiBUaGlzIGlzIG11Y2ggbW9yZSBzY2FsYWJsZSB0aGFuIHJ1bm5pbmcgZW5kLXRvLWVuZCBCRkQg YmV0d2VlbiBWVEVQcyBwZXIgVk5JLiBZb3UgY291bGQgZXZlbiB1c2Ugc3VjaCBCRkQgdG8gc3dp dGNoIHRvIGEgYmFja3VwIHNlcnZpY2Ugbm9kZSBpZiB0aGVyZSBpcyBmYWlsdXJlIHRvIHRoZSBt YWluIHNlcnZpY2Ugbm9kZS4NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IFNhbnRvc2ggUCBLIFtt YWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0XQ0KU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAx NSAyOjE0IEFNDQpUbzogUy4gRGF2YXJpOyBTaGFocmFtIERhdmFyaTsgcnRnLWJmZEBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxh Z2F0dGktYmZkLXZ4bGFuLTAwLnR4dA0KDQpUaGVyZSBjYW4gYmUgZmV3IFZURVBzIHdobyBtaWdo dCBoYXZlIGNhcGFiaWxpdGllcyB0byBtdWx0aWNhc3QgdGhlIHBhY2tldC4gSW4gc3VjaCBhIHNj ZW5hcmlvIFZURVAgd2lsbCBzZW5kIHRoYXQgcGFja2V0IHRvIHNlcnZpY2Ugbm9kZSBhbmQgc2Vy dmljZSBub2RlIHdpbGwgZG8gYSBtdWx0aWNhc3Qgb24gaXRzIGJlaGFsZi4NCg0KDQpUaGFua3MN ClNhbnRvc2ggUCBLDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTLiBEYXZhcmkNClNlbnQ6IE1vbmRheSwgSnVuZSAyOSwgMjAx NSAxMDo0OCBBTQ0KVG86IFNoYWhyYW0gRGF2YXJpOyBydGctYmZkQGlldGYub3JnPG1haWx0bzpy dGctYmZkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAwLnR4dA0KDQpIaQ0KDQpXaGF0IGlzIGEg c2VydmljZSBub2RlPw0KDQpUaHgNCg0KU2QNCg0KDQpIaSBQcmFzYWQgLA0KDQpJIGRvbid0IHNl ZSBob3cgeW91IGdldCBtb3JlIGNvdmVyYWdlIGhhdmluZyBhIFZYTEFOIHRhZy4NCg0KU2luY2Ug eW91IGFyZSBub3QgdGVzdGluZyB0aGUgVlhMQU4gYmFzZWQgVkZJL1ZSRiBmb3J3YXJkaW5nLiBC eSB0aGF0IEkgbWVhbiB5b3UgYXJlIG5vdCB0ZXN0aW5nIChEQSwgVlhMQU4gKSBvciAoRElQLCBW WExBTikgZm9yd2FyZGluZy4NCkdWUDE+IE9uZSBvZiB0aGUgYXNwZWN0cyBvZiB0aGUgbmV4dCB2 ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxsIGhhdmUgYSB2YWxpZCBpbm5lciBESVAgaW5zdGVhZCBv ZiAxMjcvOC4gVGhpcyBzaG91bGQgaGVscCBhZGRyZXNzIHlvdXIgY29uY2VybiB0byBhbiBleHRl bnQuDQpBbHNvIHlvdSBhcmUgbm90IHRlc3RpbmcgdGhlIG1hcHBpbmcgZnJvbSBBQyAoQXR0YWNo bWVudCBDaXJjdWl0KSB0byBhIFZYTEFOIHRhZy4NCkdWUDE+IEFncmVlZCwgdGhpcyBhc3BlY3Qg aGFzIG5vdCAoeWV0KSBiZWVuIGFkZHJlc3NlZCBieSBSRkM1ODg0IGFzIHdlbGwsIG5vdCB1c2lu ZyBpdCBhcyBhbiBleGN1c2UgYnV0IEkgYW0ganVzdCBub3RpbmcgdGhlIHByZWNlZGVudCBoZXJl Lg0KDQpJbiBteSBvcGluaW9uIGFsbCB5b3UgYXJlIHRlc3RpbmcsIGlzIHRoYXQgYXQgdGhlIG90 aGVyIGVuZCBvZiBhbiBJUCBUdW5uZWwgYSBzcGVjaWZpYyBWWExBTiBleGlzdCBvciBub3QuIFdo aWNoIGRvZXMgbm90IHJlcXVpcmUgcnVubmluZyBjb250aW51b3VzIEJGRC4NCkdWUDE+IFRoZXJl IGFyZSBzcGVjaWZpYyB1c2UtY2FzZXMgKHNlZSBub3RlIGFib3V0IFNlcnZpY2UgTm9kZSByZWFj aGFiaWxpdHkgaW4gU2VjIDIgb2YgdGhlIGRyYWZ0KSB0aGF0IHJlcXVpcmUgY29udGludW91cyBt b25pdG9yaW5nIG9mIHNvbWUgc3BlY2lhbC1wdXJwb3NlIFZURVBzLg0KDQpJbiBteSBvcGluaW9u IHRoaXMgaXMgYSB2ZXJ5IGluIGVmZmljaWVudCB3YXkgb2YgZ2V0dGluZyB0aGF0IGluZm9ybWF0 aW9uLiBUaGUgY29udHJvbGxlciBzaG91bGQgYmUgYWJsZSB0byBnZXQgdGhpcyBpbmZvcm1hdGlv biBtdWNoIG1vcmUgZWZmaWNpZW50bHkuDQoNCkl0IHdvdWxkIGJlIGdvb2QgaWYgeW91IGNhbiBw cm92aWRlIGFuIGV4YW1wbGUgb2Ygd2hhdCB5b3UgdGhpbmsgaXMgbW9yZSBjb3ZlcmFnZSB0aGFu IEJGRC4gT3IgYXQgbGVhc3Qgd2hhdCBleHRyYSBjb3ZlcmFnZSBkbyB5b3UgZXhhY3RseSBoYXZl IGluIG1pbmQsIHNpbmNlIHRoaXMgZHJhZnQgaXMgbm90IGNhcGFibGUgb2YgbW9yZSBjb3ZlcmFn ZSB0aGFuIHN0YW5kYXJkIEJGRCBvdmVyIHRoZSBJUCB0dW5uZWwuDQoNClJlZ2FyZHMsDQpTaGFo cmFtDQpSZWdhcmRzLA0KU2hhaHJhbQ0KDQoNCk9uIEp1biAyNywgMjAxNSwgYXQgNzowNiBBTSwg U2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNv bS5jb20+PiB3cm90ZToNCkhpIFByYXNhZCAsDQoNCkkgZG9uJ3Qgc2VlIGhvdyB5b3UgZ2V0IG1v cmUgY292ZXJhZ2UgaGF2aW5nIGEgVlhMQU4gdGFnLg0KDQpTaW5jZSB5b3UgYXJlIG5vdCB0ZXN0 aW5nIHRoZSBWWExBTiBiYXNlZCBWRkkvVlJGIGZvcndhcmRpbmcuIEJ5IHRoYXQgSSBtZWFuIHlv dSBhcmUgbm90IHRlc3RpbmcgKERBLCBWWExBTiApIG9yIChESVAsIFZYTEFOKSBmb3J3YXJkaW5n Lg0KR1ZQMT4gT25lIG9mIHRoZSBhc3BlY3RzIG9mIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRy YWZ0IHdpbGwgaGF2ZSBhIHZhbGlkIGlubmVyIERJUCBpbnN0ZWFkIG9mIDEyNy84LiBUaGlzIHNo b3VsZCBoZWxwIGFkZHJlc3MgeW91ciBjb25jZXJuIHRvIGFuIGV4dGVudC4NCkFsc28geW91IGFy ZSBub3QgdGVzdGluZyB0aGUgbWFwcGluZyBmcm9tIEFDIChBdHRhY2htZW50IENpcmN1aXQpIHRv IGEgVlhMQU4gdGFnLg0KR1ZQMT4gQWdyZWVkLCB0aGlzIGFzcGVjdCBoYXMgbm90ICh5ZXQpIGJl ZW4gYWRkcmVzc2VkIGJ5IFJGQzU4ODQgYXMgd2VsbCwgbm90IHVzaW5nIGl0IGFzIGFuIGV4Y3Vz ZSBidXQgSSBhbSBqdXN0IG5vdGluZyB0aGUgcHJlY2VkZW50IGhlcmUuDQoNCkluIG15IG9waW5p b24gYWxsIHlvdSBhcmUgdGVzdGluZywgaXMgdGhhdCBhdCB0aGUgb3RoZXIgZW5kIG9mIGFuIElQ IFR1bm5lbCBhIHNwZWNpZmljIFZYTEFOIGV4aXN0IG9yIG5vdC4gV2hpY2ggZG9lcyBub3QgcmVx dWlyZSBydW5uaW5nIGNvbnRpbnVvdXMgQkZELg0KR1ZQMT4gVGhlcmUgYXJlIHNwZWNpZmljIHVz ZS1jYXNlcyAoc2VlIG5vdGUgYWJvdXQgU2VydmljZSBOb2RlIHJlYWNoYWJpbGl0eSBpbiBTZWMg MiBvZiB0aGUgZHJhZnQpIHRoYXQgcmVxdWlyZSBjb250aW51b3VzIG1vbml0b3Jpbmcgb2Ygc29t ZSBzcGVjaWFsLXB1cnBvc2UgVlRFUHMuDQoNCkluIG15IG9waW5pb24gdGhpcyBpcyBhIHZlcnkg aW4gZWZmaWNpZW50IHdheSBvZiBnZXR0aW5nIHRoYXQgaW5mb3JtYXRpb24uIFRoZSBjb250cm9s bGVyIHNob3VsZCBiZSBhYmxlIHRvIGdldCB0aGlzIGluZm9ybWF0aW9uIG11Y2ggbW9yZSBlZmZp Y2llbnRseS4NCg0KSXQgd291bGQgYmUgZ29vZCBpZiB5b3UgY2FuIHByb3ZpZGUgYW4gZXhhbXBs ZSBvZiB3aGF0IHlvdSB0aGluayBpcyBtb3JlIGNvdmVyYWdlIHRoYW4gQkZELiBPciBhdCBsZWFz dCB3aGF0IGV4dHJhIGNvdmVyYWdlIGRvIHlvdSBleGFjdGx5IGhhdmUgaW4gbWluZCwgc2luY2Ug dGhpcyBkcmFmdCBpcyBub3QgY2FwYWJsZSBvZiBtb3JlIGNvdmVyYWdlIHRoYW4gc3RhbmRhcmQg QkZEIG92ZXIgdGhlIElQIHR1bm5lbC4NCg0KUmVnYXJkcywNClNoYWhyYW0NCg== --_000_4A6CE49E6084B141B15C0713B8993F2831F4941FSJEXCHMB12corpa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2FudG9zaCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRo ZSBCRkQgeW91Jm5ic3A7IGFyZSBkZXNjcmliaW5nIGluIHlvdXIgZHJhZnQgdW5pY2FzdCBvciBt dWx0aWNhc3Q/IElmIHVuaWNhc3QgdGhlbiBzZXJ2aWNlIG5vZGVzIHdvdWxkIG5vdCBhcHBseS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QWxzbyBpZiB0aGVyZSBpcyBhIHNlcnZpY2Ugbm9kZSB0aGVuIG9uZSBjYW4g cnVuIEJGRCBvbiB0aGUgSVAgdHVubmVsIGJldHdlZW4gc291cmNlIFZURVAgYW5kIHNlcnZpY2Ug bm9kZSBhbmQgYmV0d2VlbiBzZXJ2aWNlIG5vZGUgYW5kIHRoZSBkZXN0aW5hdGlvbiBWVEVQLg0K IFRoaXMgaXMgbXVjaCBtb3JlIHNjYWxhYmxlIHRoYW4gcnVubmluZyBlbmQtdG8tZW5kIEJGRCBi ZXR3ZWVuIFZURVBzIHBlciBWTkkuIFlvdSBjb3VsZCBldmVuIHVzZSBzdWNoIEJGRCB0byBzd2l0 Y2ggdG8gYSBiYWNrdXAgc2VydmljZSBub2RlIGlmIHRoZXJlIGlzIGZhaWx1cmUgdG8gdGhlIG1h aW4gc2VydmljZSBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGh4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlNoYWhyYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTYW50b3NoIFAgSyBbbWFpbHRvOnNhbnRv c2hwa0BqdW5pcGVyLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDMwLCAy MDE1IDI6MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IFMuIERhdmFyaTsgU2hhaHJhbSBEYXZhcmk7IHJ0 Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAwLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBjYW4gYmUgZmV3IFZURVBzIHdobyBtaWdodCBo YXZlIGNhcGFiaWxpdGllcyB0byBtdWx0aWNhc3QgdGhlIHBhY2tldC4gSW4gc3VjaCBhIHNjZW5h cmlvIFZURVAgd2lsbCBzZW5kIHRoYXQgcGFja2V0IHRvIHNlcnZpY2Ugbm9kZSBhbmQgc2Vydmlj ZSBub2RlIHdpbGwNCiBkbyBhIG11bHRpY2FzdCBvbiBpdHMgYmVoYWxmLiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U2FudG9zaCBQIEsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5TLiBEYXZhcmk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI5 LCAyMDE1IDEwOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBTaGFocmFtIERhdmFyaTsgPGEgaHJlZj0i bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYWxsYWdh dHRpLWJmZC12eGxhbi0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpcyBhIHNlcnZpY2Ugbm9kZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGh4PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNkPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkhpIFByYXNhZCAsPGJyPg0KPGJyPg0KSSBkb24ndCBzZWUgaG93IHlvdSBn ZXQgbW9yZSBjb3ZlcmFnZSBoYXZpbmcgYSBWWExBTiB0YWcuJm5ic3A7PGJyPg0KPGJyPg0KU2lu Y2UgeW91IGFyZSBub3QgdGVzdGluZyB0aGUgVlhMQU4gYmFzZWQgVkZJL1ZSRiBmb3J3YXJkaW5n LiBCeSB0aGF0IEkgbWVhbiB5b3UgYXJlIG5vdCB0ZXN0aW5nIChEQSwgVlhMQU4gKSBvciAoRElQ LCBWWExBTikgZm9yd2FyZGluZy48YnI+DQpHVlAxJmd0OyBPbmUgb2YgdGhlIGFzcGVjdHMgb2Yg dGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgd2lsbCBoYXZlIGEgdmFsaWQgaW5uZXIgRElQ IGluc3RlYWQgb2YgMTI3LzguIFRoaXMgc2hvdWxkIGhlbHAgYWRkcmVzcyB5b3VyIGNvbmNlcm4g dG8gYW4gZXh0ZW50Ljxicj4NCkFsc28geW91IGFyZSBub3QgdGVzdGluZyB0aGUgbWFwcGluZyBm cm9tIEFDIChBdHRhY2htZW50IENpcmN1aXQpIHRvIGEgVlhMQU4gdGFnLiZuYnNwOzxicj4NCkdW UDEmZ3Q7IEFncmVlZCwgdGhpcyBhc3BlY3QgaGFzIG5vdCAoeWV0KSBiZWVuIGFkZHJlc3NlZCBi eSBSRkM1ODg0IGFzIHdlbGwsIG5vdCB1c2luZyBpdCBhcyBhbiBleGN1c2UgYnV0IEkgYW0ganVz dCBub3RpbmcgdGhlIHByZWNlZGVudCBoZXJlLjxicj4NCjxicj4NCkluIG15IG9waW5pb24gYWxs IHlvdSBhcmUgdGVzdGluZywgaXMgdGhhdCBhdCB0aGUgb3RoZXIgZW5kIG9mIGFuIElQIFR1bm5l bCBhIHNwZWNpZmljIFZYTEFOIGV4aXN0IG9yIG5vdC4gV2hpY2ggZG9lcyBub3QgcmVxdWlyZSBy dW5uaW5nIGNvbnRpbnVvdXMgQkZELjxicj4NCkdWUDEmZ3Q7IFRoZXJlIGFyZSBzcGVjaWZpYyB1 c2UtY2FzZXMgKHNlZSBub3RlIGFib3V0IFNlcnZpY2UgTm9kZSByZWFjaGFiaWxpdHkgaW4gU2Vj IDIgb2YgdGhlIGRyYWZ0KSB0aGF0IHJlcXVpcmUgY29udGludW91cyBtb25pdG9yaW5nIG9mIHNv bWUgc3BlY2lhbC1wdXJwb3NlIFZURVBzLjxicj4NCjxicj4NCkluIG15IG9waW5pb24gdGhpcyBp cyBhIHZlcnkgaW4gZWZmaWNpZW50IHdheSBvZiBnZXR0aW5nIHRoYXQgaW5mb3JtYXRpb24uIFRo ZSBjb250cm9sbGVyIHNob3VsZCBiZSBhYmxlIHRvIGdldCB0aGlzIGluZm9ybWF0aW9uIG11Y2gg bW9yZSBlZmZpY2llbnRseS4mbmJzcDs8YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBnb29kIGlmIHlv dSBjYW4gcHJvdmlkZSBhbiBleGFtcGxlIG9mIHdoYXQgeW91IHRoaW5rIGlzIG1vcmUgY292ZXJh Z2UgdGhhbiBCRkQuIE9yIGF0IGxlYXN0IHdoYXQgZXh0cmEgY292ZXJhZ2UgZG8geW91IGV4YWN0 bHkgaGF2ZSBpbiBtaW5kLCBzaW5jZSB0aGlzIGRyYWZ0IGlzIG5vdCBjYXBhYmxlIG9mIG1vcmUg Y292ZXJhZ2UgdGhhbiBzdGFuZGFyZCBCRkQgb3ZlciB0aGUgSVAgdHVubmVsLiZuYnNwOzxicj4N Cjxicj4NClJlZ2FyZHMsPGJyPg0KU2hhaHJhbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hhaHJhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVuIDI3LCAyMDE1LCBhdCA3OjA2IEFNLCBTaGFocmFtIERh dmFyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20iPmRhdmFyaUBicm9h ZGNvbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBQcmFzYWQgLDxicj4NCjxicj4NCkkgZG9uJ3Qgc2VlIGhvdyB5b3Ug Z2V0IG1vcmUgY292ZXJhZ2UgaGF2aW5nIGEgVlhMQU4gdGFnLiA8YnI+DQo8YnI+DQpTaW5jZSB5 b3UgYXJlIG5vdCB0ZXN0aW5nIHRoZSBWWExBTiBiYXNlZCBWRkkvVlJGIGZvcndhcmRpbmcuIEJ5 IHRoYXQgSSBtZWFuIHlvdSBhcmUgbm90IHRlc3RpbmcgKERBLCBWWExBTiApIG9yIChESVAsIFZY TEFOKSBmb3J3YXJkaW5nLjxicj4NCkdWUDEmZ3Q7IE9uZSBvZiB0aGUgYXNwZWN0cyBvZiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxsIGhhdmUgYSB2YWxpZCBpbm5lciBESVAgaW5z dGVhZCBvZiAxMjcvOC4gVGhpcyBzaG91bGQgaGVscCBhZGRyZXNzIHlvdXIgY29uY2VybiB0byBh biBleHRlbnQuPGJyPg0KQWxzbyB5b3UgYXJlIG5vdCB0ZXN0aW5nIHRoZSBtYXBwaW5nIGZyb20g QUMgKEF0dGFjaG1lbnQgQ2lyY3VpdCkgdG8gYSBWWExBTiB0YWcuDQo8YnI+DQpHVlAxJmd0OyBB Z3JlZWQsIHRoaXMgYXNwZWN0IGhhcyBub3QgKHlldCkgYmVlbiBhZGRyZXNzZWQgYnkgUkZDNTg4 NCBhcyB3ZWxsLCBub3QgdXNpbmcgaXQgYXMgYW4gZXhjdXNlIGJ1dCBJIGFtIGp1c3Qgbm90aW5n IHRoZSBwcmVjZWRlbnQgaGVyZS48YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uIGFsbCB5b3UgYXJl IHRlc3RpbmcsIGlzIHRoYXQgYXQgdGhlIG90aGVyIGVuZCBvZiBhbiBJUCBUdW5uZWwgYSBzcGVj aWZpYyBWWExBTiBleGlzdCBvciBub3QuIFdoaWNoIGRvZXMgbm90IHJlcXVpcmUgcnVubmluZyBj b250aW51b3VzIEJGRC48YnI+DQpHVlAxJmd0OyBUaGVyZSBhcmUgc3BlY2lmaWMgdXNlLWNhc2Vz IChzZWUgbm90ZSBhYm91dCBTZXJ2aWNlIE5vZGUgcmVhY2hhYmlsaXR5IGluIFNlYyAyIG9mIHRo ZSBkcmFmdCkgdGhhdCByZXF1aXJlIGNvbnRpbnVvdXMgbW9uaXRvcmluZyBvZiBzb21lIHNwZWNp YWwtcHVycG9zZSBWVEVQcy48YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uIHRoaXMgaXMgYSB2ZXJ5 IGluIGVmZmljaWVudCB3YXkgb2YgZ2V0dGluZyB0aGF0IGluZm9ybWF0aW9uLiBUaGUgY29udHJv bGxlciBzaG91bGQgYmUgYWJsZSB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiBtdWNoIG1vcmUgZWZm aWNpZW50bHkuDQo8YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjYW4gcHJvdmlk ZSBhbiBleGFtcGxlIG9mIHdoYXQgeW91IHRoaW5rIGlzIG1vcmUgY292ZXJhZ2UgdGhhbiBCRkQu IE9yIGF0IGxlYXN0IHdoYXQgZXh0cmEgY292ZXJhZ2UgZG8geW91IGV4YWN0bHkgaGF2ZSBpbiBt aW5kLCBzaW5jZSB0aGlzIGRyYWZ0IGlzIG5vdCBjYXBhYmxlIG9mIG1vcmUgY292ZXJhZ2UgdGhh biBzdGFuZGFyZCBCRkQgb3ZlciB0aGUgSVAgdHVubmVsLg0KPGJyPg0KPGJyPg0KUmVnYXJkcyw8 YnI+DQpTaGFocmFtPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A6CE49E6084B141B15C0713B8993F2831F4941FSJEXCHMB12corpa_--