From manav.bhatia@alcatel-lucent.com Mon Aug 1 00:01:50 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30F421F86C1 for ; Mon, 1 Aug 2011 00:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=-3.622, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY1Q+MMGS-MA for ; Mon, 1 Aug 2011 00:01:49 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 68FBA21F86BD for ; Mon, 1 Aug 2011 00:01:49 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7171kTe006105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 02:01:49 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7171jWp013320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Aug 2011 12:31:45 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 1 Aug 2011 12:31:45 +0530 Message-ID: <4E364F01.2070907@alcatel-lucent.com> Date: Mon, 1 Aug 2011 12:30:17 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.8 MIME-Version: 1.0 To: Mach Chen Subject: Re: =?GB2312?B?tPC4tDogtPC4tDogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZg==?= =?GB2312?B?b3IgSW50ZXJmYWNlIGRyYWZ0?= References: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2671@SJEXCHCCR02.corp.ad.broadcom.com> <4E36495A.6060108@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 07:01:50 -0000 Hi Mac, This is exactly the point that i am trying to make - one pays a price by sending BFD on each component link - so we must only do it if there is no way out. Thus your comment in the earlier mail "From the view of implementation, there is no difference between runing single BFD over a LAG and runing per-link BFD." isnt entirely correct. Cheers, Manav On 8/1/2011 12:16 PM, Mach Chen wrote: > Hi Manav, > >> Practically, most routers are constrained by the number of BFD packets the system can send and receive per second. If we start sending BFD packets over each component link of the lag, then the > number of IP interfaces that can support BFD goes down. > > In the case of certain resources, this should be so. You have to pay this if you want to do per-link detection whatever techniques are used. > > Best regards, > Mach > ________________________________________ > 发件人: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] 代表 Manav Bhatia [manav.bhatia@alcatel-lucent.com] > 发送时间: 2011年8月1日 14:36 > 到: rtg-bfd@ietf.org > 主题: Re: 答复: Solicit comments on BFD for Interface draft > > Hi Mach, > >> First, Could you please explain your protocol layering model. Do we now need 2 IP layers, one before LAG termination and one after LAG termination, where the one before LAG termination only understands the well known Multicast IPDA. >> >> Or implementing this draft assumes bypassing LAG termination when IP-DA is the known multicast proposed in the draft. In other words now LAG termination is conditional on IP address. >> >> [Mach] From the view of implementation, there is no difference between runing single BFD over a LAG and runing per-link BFD. The key point is how to identify a BFD packet, current as defined in RFC 5880, it uses the UDP port, now for per-link BFD, it uses both multicast IP DA and UDP port. You can do it before or after the LAG termination, it's implementation specific. > > [Manav] I disagree. Practically, most routers are constrained by the > number of BFD packets the system can send and receive per second. If we > start sending BFD packets over each component link of the lag, then the > number of IP interfaces that can support BFD goes down. > > Cheers, Manav From mach.chen@huawei.com Mon Aug 1 00:33:36 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1221F85B8 for ; Mon, 1 Aug 2011 00:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skSP-uBBoVKm for ; Mon, 1 Aug 2011 00:33:35 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A809221F8548 for ; Mon, 1 Aug 2011 00:33:35 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800AQ6NLHJA@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 15:32:05 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800876NLG12@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 15:32:05 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACY78719; Mon, 01 Aug 2011 15:32:02 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 01 Aug 2011 15:32:01 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 01 Aug 2011 15:32:02 +0800 Date: Mon, 01 Aug 2011 07:32:01 +0000 From: Mach Chen Subject: RE: Solicit comments on BFD for Interface draft X-Originating-IP: [172.24.2.41] To: Manav Bhatia Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMUB0ao/ML+kRa2k6U2Olul6P1Ig== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 07:33:37 -0000 SGkgTWFuYXYsDQoNClRoZSBjb21tZW50cyB0aGF0IEkgbWFkZSBpcyBmcm9tIHRoZSB2aWV3IG9m IHByb2Nlc3Mgb2YgQkZEIHBhY2tldC4gDQoNClRoZSB3b3JsZCBpcyBub3QgYWx3YXlzIG9ubHkg b25lIHdheSwgcGVvcGxlIGFyZSBhbHdheXMgbG9va2luZyBmb3IgYmV0dGVyIGFuZCBtb3JlIHNp bXBsZSB3YXkuIEJhc2VkIG9uIG1vc3Qgb2YgdGhlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBv ZiBCRkQgYW5kIEVUSCBPQU0oZWcuLCAuYWgvLmFnLi4uKSwgQkZEJ3MgY29uZmlndXJhdGlvbiBt b3JlIHNpbXBsZSwgdGhpcyBpcyB3aHkgbWFueSBvcGVydG9ycyAoZXNwZWNpY2FsbHkgdGhvc2Ug b3BlcmF0b3JzIHdobyBhcmUgcnVubmluZyBJUC9NUExTIG5ldHdvcmsgYW5kIGZhbWlsYXIgd2l0 aCBCRkQpIGxpa2UgaXQuIA0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IE1hbmF2IEJoYXRpYSBbbWFuYXYuYmhh dGlhQGFsY2F0ZWwtbHVjZW50LmNvbV0NCreiy83KsbzkOiAyMDExxOo41MIxyNUgMTU6MDANCrW9 OiBNYWNoIENoZW4NCkNjOiBydGctYmZkQGlldGYub3JnDQrW98ziOiBSZTogtPC4tDogtPC4tDog U29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBkcmFmdA0KDQpIaSBNYWMsDQoN ClRoaXMgaXMgZXhhY3RseSB0aGUgcG9pbnQgdGhhdCBpIGFtIHRyeWluZyB0byBtYWtlIC0gb25l IHBheXMgYSBwcmljZSBieQ0Kc2VuZGluZyBCRkQgb24gZWFjaCBjb21wb25lbnQgbGluayAtIHNv IHdlIG11c3Qgb25seSBkbyBpdCBpZiB0aGVyZSBpcw0Kbm8gd2F5IG91dC4gVGh1cyB5b3VyIGNv bW1lbnQgaW4gdGhlIGVhcmxpZXIgbWFpbCAiRnJvbSB0aGUgdmlldyBvZg0KaW1wbGVtZW50YXRp b24sIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBydW5pbmcgc2luZ2xlIEJGRCBvdmVy IGENCkxBRyBhbmQgcnVuaW5nIHBlci1saW5rIEJGRC4iIGlzbnQgZW50aXJlbHkgY29ycmVjdC4N Cg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiA4LzEvMjAxMSAxMjoxNiBQTSwgTWFjaCBDaGVuIHdyb3Rl Og0KPiBIaSBNYW5hdiwNCj4NCj4+IFByYWN0aWNhbGx5LCBtb3N0IHJvdXRlcnMgYXJlIGNvbnN0 cmFpbmVkIGJ5IHRoZSBudW1iZXIgb2YgQkZEIHBhY2tldHMgdGhlIHN5c3RlbSBjYW4gc2VuZCBh bmQgcmVjZWl2ZSBwZXIgc2Vjb25kLiBJZiB3ZSBzdGFydCBzZW5kaW5nIEJGRCBwYWNrZXRzIG92 ZXIgZWFjaCBjb21wb25lbnQgbGluayBvZiB0aGUgbGFnLCB0aGVuIHRoZQ0KPiBudW1iZXIgb2Yg SVAgaW50ZXJmYWNlcyB0aGF0IGNhbiBzdXBwb3J0IEJGRCBnb2VzIGRvd24uDQo+DQo+IEluIHRo ZSBjYXNlIG9mIGNlcnRhaW4gcmVzb3VyY2VzLCB0aGlzIHNob3VsZCBiZSBzby4gWW91IGhhdmUg dG8gcGF5IHRoaXMgaWYgeW91IHdhbnQgdG8gZG8gcGVyLWxpbmsgZGV0ZWN0aW9uIHdoYXRldmVy IHRlY2huaXF1ZXMgYXJlIHVzZWQuDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gTWFjaA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogcnRnLWJmZC1i b3VuY2VzQGlldGYub3JnIFtydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTWFuYXYgQmhh dGlhIFttYW5hdi5iaGF0aWFAYWxjYXRlbC1sdWNlbnQuY29tXQ0KPiC3osvNyrG85DogMjAxMcTq ONTCMcjVIDE0OjM2DQo+ILW9OiBydGctYmZkQGlldGYub3JnDQo+INb3zOI6IFJlOiC08Li0OiBT b2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQo+DQo+IEhpIE1hY2gs DQo+DQo+PiBGaXJzdCwgQ291bGQgeW91IHBsZWFzZSBleHBsYWluIHlvdXIgcHJvdG9jb2wgbGF5 ZXJpbmcgbW9kZWwuIERvIHdlIG5vdyBuZWVkIDIgSVAgbGF5ZXJzLCBvbmUgYmVmb3JlIExBRyB0 ZXJtaW5hdGlvbiBhbmQgb25lIGFmdGVyIExBRyB0ZXJtaW5hdGlvbiwgd2hlcmUgdGhlIG9uZSBi ZWZvcmUgTEFHIHRlcm1pbmF0aW9uIG9ubHkgdW5kZXJzdGFuZHMgdGhlIHdlbGwga25vd24gTXVs dGljYXN0IElQREEuDQo+Pg0KPj4gT3IgaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQgYXNzdW1lcyAg YnlwYXNzaW5nIExBRyB0ZXJtaW5hdGlvbiB3aGVuIElQLURBIGlzIHRoZSBrbm93biBtdWx0aWNh c3QgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0LiBJbiBvdGhlciB3b3JkcyBub3cgTEFHIHRlcm1pbmF0 aW9uIGlzIGNvbmRpdGlvbmFsIG9uIElQIGFkZHJlc3MuDQo+Pg0KPj4gW01hY2hdIEZyb20gdGhl IHZpZXcgb2YgaW1wbGVtZW50YXRpb24sIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBy dW5pbmcgc2luZ2xlIEJGRCBvdmVyIGEgTEFHIGFuZCBydW5pbmcgcGVyLWxpbmsgQkZELiBUaGUg a2V5IHBvaW50IGlzIGhvdyB0byBpZGVudGlmeSBhIEJGRCBwYWNrZXQsIGN1cnJlbnQgYXMgZGVm aW5lZCBpbiBSRkMgNTg4MCwgaXQgdXNlcyB0aGUgVURQIHBvcnQsIG5vdyBmb3IgcGVyLWxpbmsg QkZELCBpdCB1c2VzIGJvdGggbXVsdGljYXN0IElQIERBIGFuZCBVRFAgcG9ydC4gWW91IGNhbiBk byBpdCBiZWZvcmUgb3IgYWZ0ZXIgdGhlIExBRyB0ZXJtaW5hdGlvbiwgaXQncyBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpYy4NCj4NCj4gW01hbmF2XSBJIGRpc2FncmVlLiBQcmFjdGljYWxseSwgbW9z dCByb3V0ZXJzIGFyZSBjb25zdHJhaW5lZCBieSB0aGUNCj4gbnVtYmVyIG9mIEJGRCBwYWNrZXRz IHRoZSBzeXN0ZW0gY2FuIHNlbmQgYW5kIHJlY2VpdmUgcGVyIHNlY29uZC4gSWYgd2UNCj4gc3Rh cnQgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVyIGVhY2ggY29tcG9uZW50IGxpbmsgb2YgdGhlIGxh ZywgdGhlbiB0aGUNCj4gbnVtYmVyIG9mIElQIGludGVyZmFjZXMgdGhhdCBjYW4gc3VwcG9ydCBC RkQgZ29lcyBkb3duLg0KPg0KPiBDaGVlcnMsIE1hbmF2 From manav.bhatia@alcatel-lucent.com Mon Aug 1 01:01:20 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2E21F85FF for ; Mon, 1 Aug 2011 01:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ldp9DUMPsyH for ; Mon, 1 Aug 2011 01:01:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8D49521F85FE for ; Mon, 1 Aug 2011 01:01:18 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p7181DGo022318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 03:01:15 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7181CEM019759 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Aug 2011 13:31:12 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 1 Aug 2011 13:31:12 +0530 Message-ID: <4E365CEF.7000209@alcatel-lucent.com> Date: Mon, 1 Aug 2011 13:29:43 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.8 MIME-Version: 1.0 To: Mach Chen Subject: Re: Solicit comments on BFD for Interface draft References: In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 08:01:20 -0000 Hi Mach, Then can this point about configuration complexity be added to the draft so that the reader is aware of why this solution is being proposed? Secondly, can you split this into two drafts - one that discusses doing BFD over unnumbered IP interfaces and a new one that discusses BFD over lags. While your original draft did not explicitly deal with the latter, i think it makes sense to have a separate draft that deals with how BFD could/should be done over lags. Cheers, Manav On 8/1/2011 1:02 PM, Mach Chen wrote: > Hi Manav, > > The comments that I made is from the view of process of BFD packet. > > The world is not always only one way, people are always looking for better and more simple way. Based on most of the existing implementations of BFD and ETH OAM(eg., .ah/.ag...), BFD's configuration more simple, this is why many opertors (especically those operators who are running IP/MPLS network and familar with BFD) like it. > > Best regards, > Mach > ________________________________________ > 发件人: Manav Bhatia [manav.bhatia@alcatel-lucent.com] > 发送时间: 2011年8月1日 15:00 > 到: Mach Chen > Cc: rtg-bfd@ietf.org > 主题: Re: 答复: 答复: Solicit comments on BFD for Interface draft > > Hi Mac, > > This is exactly the point that i am trying to make - one pays a price by > sending BFD on each component link - so we must only do it if there is > no way out. Thus your comment in the earlier mail "From the view of > implementation, there is no difference between runing single BFD over a > LAG and runing per-link BFD." isnt entirely correct. > > Cheers, Manav > > On 8/1/2011 12:16 PM, Mach Chen wrote: >> Hi Manav, >> >>> Practically, most routers are constrained by the number of BFD packets the system can send and receive per second. If we start sending BFD packets over each component link of the lag, then the >> number of IP interfaces that can support BFD goes down. >> >> In the case of certain resources, this should be so. You have to pay this if you want to do per-link detection whatever techniques are used. >> >> Best regards, >> Mach >> ________________________________________ >> 发件人: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] 代表 Manav Bhatia [manav.bhatia@alcatel-lucent.com] >> 发送时间: 2011年8月1日 14:36 >> 到: rtg-bfd@ietf.org >> 主题: Re: 答复: Solicit comments on BFD for Interface draft >> >> Hi Mach, >> >>> First, Could you please explain your protocol layering model. Do we now need 2 IP layers, one before LAG termination and one after LAG termination, where the one before LAG termination only understands the well known Multicast IPDA. >>> >>> Or implementing this draft assumes bypassing LAG termination when IP-DA is the known multicast proposed in the draft. In other words now LAG termination is conditional on IP address. >>> >>> [Mach] From the view of implementation, there is no difference between runing single BFD over a LAG and runing per-link BFD. The key point is how to identify a BFD packet, current as defined in RFC 5880, it uses the UDP port, now for per-link BFD, it uses both multicast IP DA and UDP port. You can do it before or after the LAG termination, it's implementation specific. >> >> [Manav] I disagree. Practically, most routers are constrained by the >> number of BFD packets the system can send and receive per second. If we >> start sending BFD packets over each component link of the lag, then the >> number of IP interfaces that can support BFD goes down. >> >> Cheers, Manav From mach.chen@huawei.com Mon Aug 1 01:13:07 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0949721F8640 for ; Mon, 1 Aug 2011 01:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-3.037, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q+ze2HErHw6 for ; Mon, 1 Aug 2011 01:13:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id EA28C21F85DE for ; Mon, 1 Aug 2011 01:13:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800ERXPG8DX@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 16:12:08 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP800LPUPG8YB@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 01 Aug 2011 16:12:08 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACY80792; Mon, 01 Aug 2011 16:12:07 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 01 Aug 2011 16:12:06 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Mon, 01 Aug 2011 16:11:53 +0800 Date: Mon, 01 Aug 2011 08:11:52 +0000 From: Mach Chen Subject: =?gb2312?B?tPC4tDogU29saWNpdCBjb21tZW50cyBvbiBCRkQgZm9yIEludGVyZmFjZSBk?= =?gb2312?Q?raft?= In-reply-to: <4E365CEF.7000209@alcatel-lucent.com> X-Originating-IP: [172.24.2.41] To: Manav Bhatia Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMUB0ao/ML+kRa2k6U2Olul6P1IpUHG5uAgACHdSE= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E365CEF.7000209@alcatel-lucent.com> Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 08:13:07 -0000 SGkgTWFuYXYsDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb25zISBXZSB3aWxsIGFk ZCB0ZXh0IGZvciB0aGUgY29uZmlndWF0aW9uIGNvbXBsZXhpdHkgcGFydC4gQW5kIGJhc2ljYWxs eSwgZnJvbSBteSBzaWRlLCBJIGFtIGZpbmUgdG8gc3BsaXQgdGhlIGRyYWZ0IGlmIHRoYXQgaGVs cC4gSSBuZWVkIHRvIGRpc2N1c3Mgd2l0aCB0aGUgY28tYXV0aG9ycyBhbmQgc29saWNpdCB0aGUg b3BpbmlvbnMgb2YgdGhlIFdHIGFuZCB0aGVuIGRlY2lkZSBob3cgdG8gcHJvZ3Jlc3MgaXQuDQoN CkJlc3QgcmVnYXJkcywNCk1hY2gNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCreivP7IyzogTWFuYXYgQmhhdGlhIFttYW5hdi5iaGF0aWFAYWxjYXRlbC1sdWNlbnQu Y29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jjUwjHI1SAxNTo1OQ0Ktb06IE1hY2ggQ2hlbg0KQ2M6IHJ0 Zy1iZmRAaWV0Zi5vcmcNCtb3zOI6IFJlOiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50 ZXJmYWNlIGRyYWZ0DQoNCkhpIE1hY2gsDQoNClRoZW4gY2FuIHRoaXMgcG9pbnQgYWJvdXQgY29u ZmlndXJhdGlvbiBjb21wbGV4aXR5IGJlIGFkZGVkIHRvIHRoZSBkcmFmdA0Kc28gdGhhdCB0aGUg cmVhZGVyIGlzIGF3YXJlIG9mIHdoeSB0aGlzIHNvbHV0aW9uIGlzIGJlaW5nIHByb3Bvc2VkPw0K U2Vjb25kbHksIGNhbiB5b3Ugc3BsaXQgdGhpcyBpbnRvIHR3byBkcmFmdHMgLSBvbmUgdGhhdCBk aXNjdXNzZXMgZG9pbmcNCkJGRCBvdmVyIHVubnVtYmVyZWQgSVAgaW50ZXJmYWNlcyBhbmQgYSBu ZXcgb25lIHRoYXQgZGlzY3Vzc2VzIEJGRCBvdmVyDQpsYWdzLiBXaGlsZSB5b3VyIG9yaWdpbmFs IGRyYWZ0IGRpZCBub3QgZXhwbGljaXRseSBkZWFsIHdpdGggdGhlIGxhdHRlciwNCmkgdGhpbmsg aXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBhIHNlcGFyYXRlIGRyYWZ0IHRoYXQgZGVhbHMgd2l0aCBo b3cgQkZEDQpjb3VsZC9zaG91bGQgYmUgZG9uZSBvdmVyIGxhZ3MuDQoNCkNoZWVycywgTWFuYXYN Cg0KT24gOC8xLzIwMTEgMTowMiBQTSwgTWFjaCBDaGVuIHdyb3RlOg0KPiBIaSBNYW5hdiwNCj4N Cj4gVGhlIGNvbW1lbnRzIHRoYXQgSSBtYWRlIGlzIGZyb20gdGhlIHZpZXcgb2YgcHJvY2VzcyBv ZiBCRkQgcGFja2V0Lg0KPg0KPiBUaGUgd29ybGQgaXMgbm90IGFsd2F5cyBvbmx5IG9uZSB3YXks IHBlb3BsZSBhcmUgYWx3YXlzIGxvb2tpbmcgZm9yIGJldHRlciBhbmQgbW9yZSBzaW1wbGUgd2F5 LiBCYXNlZCBvbiBtb3N0IG9mIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgQkZEIGFu ZCBFVEggT0FNKGVnLiwgLmFoLy5hZy4uLiksIEJGRCdzIGNvbmZpZ3VyYXRpb24gbW9yZSBzaW1w bGUsIHRoaXMgaXMgd2h5IG1hbnkgb3BlcnRvcnMgKGVzcGVjaWNhbGx5IHRob3NlIG9wZXJhdG9y cyB3aG8gYXJlIHJ1bm5pbmcgSVAvTVBMUyBuZXR3b3JrIGFuZCBmYW1pbGFyIHdpdGggQkZEKSBs aWtlIGl0Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiC3orz+yMs6IE1hbmF2IEJoYXRpYSBbbWFuYXYuYmhh dGlhQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTHE6jjUwjHI1SAxNTowMA0K PiC1vTogTWFjaCBDaGVuDQo+IENjOiBydGctYmZkQGlldGYub3JnDQo+INb3zOI6IFJlOiC08Li0 OiC08Li0OiBTb2xpY2l0IGNvbW1lbnRzIG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQo+DQo+ IEhpIE1hYywNCj4NCj4gVGhpcyBpcyBleGFjdGx5IHRoZSBwb2ludCB0aGF0IGkgYW0gdHJ5aW5n IHRvIG1ha2UgLSBvbmUgcGF5cyBhIHByaWNlIGJ5DQo+IHNlbmRpbmcgQkZEIG9uIGVhY2ggY29t cG9uZW50IGxpbmsgLSBzbyB3ZSBtdXN0IG9ubHkgZG8gaXQgaWYgdGhlcmUgaXMNCj4gbm8gd2F5 IG91dC4gVGh1cyB5b3VyIGNvbW1lbnQgaW4gdGhlIGVhcmxpZXIgbWFpbCAiRnJvbSB0aGUgdmll dyBvZg0KPiBpbXBsZW1lbnRhdGlvbiwgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHJ1 bmluZyBzaW5nbGUgQkZEIG92ZXIgYQ0KPiBMQUcgYW5kIHJ1bmluZyBwZXItbGluayBCRkQuIiBp c250IGVudGlyZWx5IGNvcnJlY3QuDQo+DQo+IENoZWVycywgTWFuYXYNCj4NCj4gT24gOC8xLzIw MTEgMTI6MTYgUE0sIE1hY2ggQ2hlbiB3cm90ZToNCj4+IEhpIE1hbmF2LA0KPj4NCj4+PiBQcmFj dGljYWxseSwgbW9zdCByb3V0ZXJzIGFyZSBjb25zdHJhaW5lZCBieSB0aGUgbnVtYmVyIG9mIEJG RCBwYWNrZXRzIHRoZSBzeXN0ZW0gY2FuIHNlbmQgYW5kIHJlY2VpdmUgcGVyIHNlY29uZC4gSWYg d2Ugc3RhcnQgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVyIGVhY2ggY29tcG9uZW50IGxpbmsgb2Yg dGhlIGxhZywgdGhlbiB0aGUNCj4+IG51bWJlciBvZiBJUCBpbnRlcmZhY2VzIHRoYXQgY2FuIHN1 cHBvcnQgQkZEIGdvZXMgZG93bi4NCj4+DQo+PiBJbiB0aGUgY2FzZSBvZiBjZXJ0YWluIHJlc291 cmNlcywgdGhpcyBzaG91bGQgYmUgc28uIFlvdSBoYXZlIHRvIHBheSB0aGlzIGlmIHlvdSB3YW50 IHRvIGRvIHBlci1saW5rIGRldGVjdGlvbiB3aGF0ZXZlciB0ZWNobmlxdWVzIGFyZSB1c2VkLg0K Pj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IE1hY2gNCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ILeivP7IyzogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFty dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTWFuYXYgQmhhdGlhIFttYW5hdi5iaGF0aWFA YWxjYXRlbC1sdWNlbnQuY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTHE6jjUwjHI1SAxNDozNg0KPj4g tb06IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+INb3zOI6IFJlOiC08Li0OiBTb2xpY2l0IGNvbW1lbnRz IG9uIEJGRCBmb3IgSW50ZXJmYWNlIGRyYWZ0DQo+Pg0KPj4gSGkgTWFjaCwNCj4+DQo+Pj4gRmly c3QsIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB5b3VyIHByb3RvY29sIGxheWVyaW5nIG1vZGVs LiBEbyB3ZSBub3cgbmVlZCAyIElQIGxheWVycywgb25lIGJlZm9yZSBMQUcgdGVybWluYXRpb24g YW5kIG9uZSBhZnRlciBMQUcgdGVybWluYXRpb24sIHdoZXJlIHRoZSBvbmUgYmVmb3JlIExBRyB0 ZXJtaW5hdGlvbiBvbmx5IHVuZGVyc3RhbmRzIHRoZSB3ZWxsIGtub3duIE11bHRpY2FzdCBJUERB Lg0KPj4+DQo+Pj4gT3IgaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQgYXNzdW1lcyAgYnlwYXNzaW5n IExBRyB0ZXJtaW5hdGlvbiB3aGVuIElQLURBIGlzIHRoZSBrbm93biBtdWx0aWNhc3QgcHJvcG9z ZWQgaW4gdGhlIGRyYWZ0LiBJbiBvdGhlciB3b3JkcyBub3cgTEFHIHRlcm1pbmF0aW9uIGlzIGNv bmRpdGlvbmFsIG9uIElQIGFkZHJlc3MuDQo+Pj4NCj4+PiBbTWFjaF0gRnJvbSB0aGUgdmlldyBv ZiBpbXBsZW1lbnRhdGlvbiwgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHJ1bmluZyBz aW5nbGUgQkZEIG92ZXIgYSBMQUcgYW5kIHJ1bmluZyBwZXItbGluayBCRkQuIFRoZSBrZXkgcG9p bnQgaXMgaG93IHRvIGlkZW50aWZ5IGEgQkZEIHBhY2tldCwgY3VycmVudCBhcyBkZWZpbmVkIGlu IFJGQyA1ODgwLCBpdCB1c2VzIHRoZSBVRFAgcG9ydCwgbm93IGZvciBwZXItbGluayBCRkQsIGl0 IHVzZXMgYm90aCBtdWx0aWNhc3QgSVAgREEgYW5kIFVEUCBwb3J0LiBZb3UgY2FuIGRvIGl0IGJl Zm9yZSBvciBhZnRlciB0aGUgTEFHIHRlcm1pbmF0aW9uLCBpdCdzIGltcGxlbWVudGF0aW9uIHNw ZWNpZmljLg0KPj4NCj4+IFtNYW5hdl0gSSBkaXNhZ3JlZS4gUHJhY3RpY2FsbHksIG1vc3Qgcm91 dGVycyBhcmUgY29uc3RyYWluZWQgYnkgdGhlDQo+PiBudW1iZXIgb2YgQkZEIHBhY2tldHMgdGhl IHN5c3RlbSBjYW4gc2VuZCBhbmQgcmVjZWl2ZSBwZXIgc2Vjb25kLiBJZiB3ZQ0KPj4gc3RhcnQg c2VuZGluZyBCRkQgcGFja2V0cyBvdmVyIGVhY2ggY29tcG9uZW50IGxpbmsgb2YgdGhlIGxhZywg dGhlbiB0aGUNCj4+IG51bWJlciBvZiBJUCBpbnRlcmZhY2VzIHRoYXQgY2FuIHN1cHBvcnQgQkZE IGdvZXMgZG93bi4NCj4+DQo+PiBDaGVlcnMsIE1hbmF2 From tnadeau@lucidvision.com Mon Aug 1 06:03:08 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1B821F8B2E for ; Mon, 1 Aug 2011 06:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk7wjl6aA3uJ for ; Mon, 1 Aug 2011 06:03:07 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A9B7521F8B39 for ; Mon, 1 Aug 2011 06:03:01 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4996F1D42E42; Mon, 1 Aug 2011 09:03:07 -0400 (EDT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Nadeau In-Reply-To: <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> Date: Mon, 1 Aug 2011 09:03:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <497624C8-E499-4205-AC6D-5905457D7FD6@lucidvision.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D266F@SJEXCHCCR02.corp.ad.broadcom.com> <6BFFD9D6-D2D3-4230-B5A9-6BFA4FBD497A@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1244.3) Cc: "'rtg-bfd@ietf.org'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 13:03:08 -0000 On Jul 31, 2011, at 10:31 PM, Shane Amante wrote: > Sharam, >=20 > On Jul 31, 2011, at 7:12 PM, Shahram Davari wrote: >> Hi Shane and all >>=20 >> Even if as you say BFD requires less configuration (which it doesn't) >=20 > I noticed you haven't pointed toward an existing standard or, better = yet, implementation of said standard that would back your claim that = today's implementations of 802.1ag/Y.1731 are "less configuration" than = BFD =85 I totally agree. Having implemented the .ah/.ag stuff in a past = life and worked with operators who were trying to deploy it, as well as = worked at one who was trying to deploy it, Shane's analysis of the = operational complexity is right on. BFD is as its name implies: dead = simple to deploy as there is nearly 0 configuration - actually most = implementations will have 0 configuration for routing protocols and = links other than globally enabling it if it isn't already by default. = He is also correct when he stated that there are several potentially = complicated steps to configure MIPs and MEPs within a network, most of = which much be performed on EVERY box in the network where MIPs/MEPs = exist, not to mention potentially when other configurations around the = network change. --Tom >> still it can't justify doing unnecessary layer violation to proxy = for Ethernet OAM that already exists. Why not use BFD for OTN and PON = OAM next. >=20 > Let's be perfectly clear here. BFD is a fast, failure detection = mechanism that is [already] directly integrated into and directly drives = *routing* and *signaling* protocols for IP/MPLS networks. That was why = BFD was created and that is how it is being extensively used. And, = that's **how** we want to continue to use it, in this case on = component-links of LAG's between /routed/ devices, as we need to /scale/ = our networks beyond the capability of physical media. >=20 > Ethernet OAM has it's place and will continue to have it's place, but = that's IMO [strictly] in L2 switched networks where one has no other = choice (since those devices are strictly L2 switches), either on: > a) Directly adjacent links: 802.3ah or 802.1ag/Y.1731; or, > b) Multiple hops: 802.1ag/Y.1731 > ... but, Ethernet OAM is a huge pain-in-the-neck to configure and = operate, as I demonstrated. >=20 > -shane >=20 >=20 >> Thx >> Shahram >>=20 >> Regards >> Shahram >>=20 >> ----- Original Message ----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Sunday, July 31, 2011 06:00 PM >> To: 'shane@castlepoint.net' >> Cc: 'rtg-bfd@ietf.org' >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hi shane >>=20 >> Same can be said about ethernet oam. Basically everything can be = automatically assigned by software except MDL. >>=20 >> As someone who has implemented OAM and BFD, I can certainly say BFD = requires more variables and parameters. >>=20 >> Regards >> Shahram=20 >>=20 >> Regards >> Shahram >>=20 >> ----- Original Message ----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Sunday, July 31, 2011 04:16 PM >> To: Shahram Davari >> Cc: Bhatia, Manav (Manav) ; = rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Hi Sharam, >>=20 >> On Jul 31, 2011, at 8:43 AM, Shahram Davari wrote: >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> As an _operator_ of BFD, I am not /required/ to configure every = single variable you named above, on every single link of every router in = my network. Good try though. =20 >>=20 >> Not to pick on any one implementation, but here's proof that the only = required **configuration elements** necessary to bring up BFD was the = 'minimum-interval', (specifying a period of 100 msecs): >> ---snip--- >> interface fe-0/0/6.0 { >> point-to-point; >> bfd-liveness-detection { >> minimum-interval 100; >> } >> } >> [...] >>> show bfd session=20 >> Detect Transmit >> Address State Interface Time Interval = Multiplier >> 10.200.2.0 Up fe-0/0/6.0 0.300 0.100 = 3 =20 >>=20 >> 1 sessions, 1 clients >> Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps >> ---snip--- >>=20 >> As with most IETF protocols, and particularly with smart & clever = implementers designing & coding them, very sensible defaults are chosen = so as to reduce the configuration burden on behalf of operators. This = is another way of saying, yes, as a [BFD] protocol implementer you need = to worry that you've implemented all of variables required by the RFC, = either by forcing the operator to give you input for them or, better = yet, by speaking to operators and choosing to implement sensible = defaults. >>=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 >>=20 >> The above would seem to indicate that's false. But, if you still = don't believe me, here's a short configuration snippet showing all of = the required configuration parameters to make IEEE 802.1ag work, on just = a single link: >> ---snip--- >> ethernet { >> connectivity-fault-management { >> maintenance-domain myOrg { >> level 1; >> name-format character-string; >> maintenance-association link-MA { >> short-name-format character-string; >> continuity-check { >> interval 100ms; >> } >> mep 2 { >> interface ge-3/0/1; >> direction down; >> remote-mep 5; >> } >> } >> } >> } >> } >> ---snip--- >>=20 >> For starters, as an operator, good luck on trying to keep all your = MEP ID's straight for every component-link inside every LAG! And, = again, I'm not picking on any one vendor's configuration syntax ... the = above is no different, and sometimes worse, on any other vendor I've = configured 802.1ag/Y.1731. >>=20 >> In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the = conclusion that the designers of those protocols were likely operating = under the assumption, at that time, that a OSS and/or NMS would be used = as the [sole] means to *configure* and *maintain* all of the = configuration elements required to bootstrap them and, when something = goes wrong, figure out what information is being reported by those = protocols. Unfortunately, this is completely *untrue* of how we run = IP/MPLS networks -- namely, we don't use NMS systems, particularly to = configure our networks!, and thus we need something simple, that just = works, i.e.: BFD. >>=20 >> -shane >>=20 >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, = potentially error-prone, configuration required. Take a moment and = think about how many variables are *required* to properly set-up = 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for = the MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's = of LAG's in each carrier's network, so this needs to get repeated over = and over and over again. Bottom-line: 802.1ag/Y.1731 is extremely = complex to set-up *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can = see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 From tnadeau@lucidvision.com Mon Aug 1 06:07:58 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189C621F9234 for ; Mon, 1 Aug 2011 06:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l3RedlDtI0C for ; Mon, 1 Aug 2011 06:07:57 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 02D9821F9228 for ; Mon, 1 Aug 2011 06:07:57 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E2A5E1D42EF3; Mon, 1 Aug 2011 09:08:02 -0400 (EDT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 1 Aug 2011 09:08:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> To: "Shahram Davari" X-Mailer: Apple Mail (2.1244.3) Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 13:07:58 -0000 On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: > Hi Shane, >=20 > Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) > Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 On paper perhaps, but in reality that is not the case. I do not = know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. --Tom >=20 > Regards > Shahram =20 >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante > Sent: Saturday, July 30, 2011 9:36 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 > Manav, Sharam, Others, >=20 > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >> I think the diagnoses is correct, but the medicine isn't! :-) >>=20 >> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >=20 > The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >=20 > The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the = MEP? > ... that is *ridiculous*! >=20 > Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and = over and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex = to set-up *and* maintain. =20 >=20 > BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >=20 > So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 >> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>> Sent: Saturday, July 30, 2011 3:34 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hello Manav, >>>=20 >>> others have already replied but the part "[...] has no=20 >>> business" triggers now my reply. I deliberately=20 >>> "mis"-understand it. Point is that this is about business.=20 >>> Customers have pushed their vendors to implement BFD over LAG=20 >>> component links. Reasons I know >>>=20 >>> - LACP is not fast enough >>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>> Designers and Operations, so they would like to use it everywhere >>> - BFDs reputation for being fast and working >>>=20 >>>=20 >>> So now we have 3-4 different implementation for=20 >>> per-cmponent-link BFD that I know about. Potentially there=20 >>> exists more. Probably not that much different but enough to=20 >>> make interoperability impossible. It's again customers who=20 >>> push now for standardization. Thus the draft to find an agreement = :-) >>>=20 >>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>> as I see two fundamental setups: (a) run BFD on every=20 >>> component link and (b) run a single BFD session over the LAG=20 >>> interface. They solve different network setups as far as I can see. >>>=20 >>>=20 >>> Regards, Marc >>>=20 >>>=20 >>>=20 >>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>=20 >>>> Hi Jeff, >>>>=20 >>>> Let me understand this. If you have an IP interface over a=20 >>> LAG with 5 component links, then you internally establish 5=20 >>> BFD sessions with 30ms timeouts? >>>>=20 >>>> You don't need to do this. You could use LACP for lag and=20 >>> BFD for IP connectivity - which means BFD should remain up as=20 >>> long as there is reachability over the lag. IMO it has no=20 >>> business to bother with each individual component links.=20 >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>> Sent: Friday, July 29, 2011 7:15 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We have been supporting this mode of BFD over LAG=20 >>> operations for last 5 years and our customers love it. >>>>=20 >>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>> hit min-links, do you really want to bring the LAG down? >>>>=20 >>>> Mach - be aware of patents :) >>>>=20 >>>> Regards, >>>> Jeff >>>>=20 >>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>> wrote: >>>>=20 >>>>> Hi Mach, >>>>>=20 >>>>> I am not sure I understand why you would want BFD to=20 >>> ensure liveliness of each component link in a LAG. The draft=20 >>> seems to suggest establishing separate BFD session for each=20 >>> pair of component interfaces to detect the failures. Why=20 >>> should BFD be concerned about each component link? I would=20 >>> rather that BFD sprays packets over each component link in a=20 >>> round robin fashion and brings down the IP interface over a=20 >>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org=20 >>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>> Behalf Of Mach Chen >>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We uploaded a new=20 >>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>> interface). You are very welcome to read the draft and give=20 >>> your comments. >>>>>=20 >>>>> Many thanks, >>>>> Mach >>>>=20 >>>=20 >>> -- >>> Marc Binderberger >>>=20 >>>=20 >=20 >=20 >=20 >=20 From warren@kumari.net Mon Aug 1 08:39:39 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE6C11E80CC for ; Mon, 1 Aug 2011 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeTQnBrP+Tpm for ; Mon, 1 Aug 2011 08:39:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4236211E80C9 for ; Mon, 1 Aug 2011 08:39:38 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id D00D21B401D8; Mon, 1 Aug 2011 11:39:20 -0400 (EDT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 1 Aug 2011 11:39:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> To: Thomas Nadeau X-Mailer: Apple Mail (2.1084) Cc: Shane Amante , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 15:39:39 -0000 On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 > On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >=20 >> Hi Shane, >>=20 >> Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. >=20 > While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) +1 Yes -- and a lot of operators already use BFD in their networks, they = are already familiar with the protocol, their tools already understand = generation of configlets (and auditing), etc. It already "just works" -- = having it run on component link seems like a no brainer.... >=20 >> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 >=20 > On paper perhaps, but in reality that is not the case. I do not = know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. >=20 > --Tom >=20 >=20 >>=20 >> Regards >> Shahram =20 >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >> Sent: Saturday, July 30, 2011 9:36 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Manav, Sharam, Others, >>=20 >> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>> I think the diagnoses is correct, but the medicine isn't! :-) >>>=20 >>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>=20 >> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>=20 >> The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: >> a) What MD "name" should you use? >> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >> c) What MD "level" should you use, (probably 0 or 1)? >> d) What MEP ID's do I assign to each side of the link? >> e) Don't forget to configure the right direction, up or down, for = the MEP? >> ... that is *ridiculous*! >>=20 >> Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and = over and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex = to set-up *and* maintain. =20 >>=20 >> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>=20 >> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >>=20 >> Thanks, >>=20 >> -shane >>=20 >>=20 >>=20 >>> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>> Sent: Saturday, July 30, 2011 3:34 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hello Manav, >>>>=20 >>>> others have already replied but the part "[...] has no=20 >>>> business" triggers now my reply. I deliberately=20 >>>> "mis"-understand it. Point is that this is about business.=20 >>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>> component links. Reasons I know >>>>=20 >>>> - LACP is not fast enough >>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>> Designers and Operations, so they would like to use it everywhere >>>> - BFDs reputation for being fast and working >>>>=20 >>>>=20 >>>> So now we have 3-4 different implementation for=20 >>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>> exists more. Probably not that much different but enough to=20 >>>> make interoperability impossible. It's again customers who=20 >>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>=20 >>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>> as I see two fundamental setups: (a) run BFD on every=20 >>>> component link and (b) run a single BFD session over the LAG=20 >>>> interface. They solve different network setups as far as I can see. >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Hi Jeff, >>>>>=20 >>>>> Let me understand this. If you have an IP interface over a=20 >>>> LAG with 5 component links, then you internally establish 5=20 >>>> BFD sessions with 30ms timeouts? >>>>>=20 >>>>> You don't need to do this. You could use LACP for lag and=20 >>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>> long as there is reachability over the lag. IMO it has no=20 >>>> business to bother with each individual component links.=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We have been supporting this mode of BFD over LAG=20 >>>> operations for last 5 years and our customers love it. >>>>>=20 >>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>> hit min-links, do you really want to bring the LAG down? >>>>>=20 >>>>> Mach - be aware of patents :) >>>>>=20 >>>>> Regards, >>>>> Jeff >>>>>=20 >>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>> wrote: >>>>>=20 >>>>>> Hi Mach, >>>>>>=20 >>>>>> I am not sure I understand why you would want BFD to=20 >>>> ensure liveliness of each component link in a LAG. The draft=20 >>>> seems to suggest establishing separate BFD session for each=20 >>>> pair of component interfaces to detect the failures. Why=20 >>>> should BFD be concerned about each component link? I would=20 >>>> rather that BFD sprays packets over each component link in a=20 >>>> round robin fashion and brings down the IP interface over a=20 >>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>> Behalf Of Mach Chen >>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>> To: rtg-bfd@ietf.org >>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We uploaded a new=20 >>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>> interface). You are very welcome to read the draft and give=20 >>>> your comments. >>>>>>=20 >>>>>> Many thanks, >>>>>> Mach >>>>>=20 >>>>=20 >>>> -- >>>> Marc Binderberger >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >>=20 >=20 From warren@kumari.net Mon Aug 1 08:40:43 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0387F11E80F1 for ; Mon, 1 Aug 2011 08:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBvMnV-IZ2o8 for ; Mon, 1 Aug 2011 08:40:42 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA3E11E8101 for ; Mon, 1 Aug 2011 08:40:40 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 216291B401D8; Mon, 1 Aug 2011 11:40:47 -0400 (EDT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 1 Aug 2011 11:40:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Shane Amante X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 15:40:43 -0000 On Jul 30, 2011, at 12:36 PM, Shane Amante wrote: > Manav, Sharam, Others, >=20 > On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >> I think the diagnoses is correct, but the medicine isn't! :-) >>=20 >> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >=20 > The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. +1. >=20 > The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: > a) What MD "name" should you use? > b) What MD "name format" should you use, (ASCII, DNS, etc.)? > c) What MD "level" should you use, (probably 0 or 1)? > d) What MEP ID's do I assign to each side of the link? > e) Don't forget to configure the right direction, up or down, for the = MEP? > ... that is *ridiculous*! >=20 > Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and = over and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex = to set-up *and* maintain. =20 >=20 > BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >=20 > So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. Here's my hat too.... W >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 >> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>> Sent: Saturday, July 30, 2011 3:34 AM >>> To: Bhatia, Manav (Manav) >>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Hello Manav, >>>=20 >>> others have already replied but the part "[...] has no=20 >>> business" triggers now my reply. I deliberately=20 >>> "mis"-understand it. Point is that this is about business.=20 >>> Customers have pushed their vendors to implement BFD over LAG=20 >>> component links. Reasons I know >>>=20 >>> - LACP is not fast enough >>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>> Designers and Operations, so they would like to use it everywhere >>> - BFDs reputation for being fast and working >>>=20 >>>=20 >>> So now we have 3-4 different implementation for=20 >>> per-cmponent-link BFD that I know about. Potentially there=20 >>> exists more. Probably not that much different but enough to=20 >>> make interoperability impossible. It's again customers who=20 >>> push now for standardization. Thus the draft to find an agreement = :-) >>>=20 >>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>> as I see two fundamental setups: (a) run BFD on every=20 >>> component link and (b) run a single BFD session over the LAG=20 >>> interface. They solve different network setups as far as I can see. >>>=20 >>>=20 >>> Regards, Marc >>>=20 >>>=20 >>>=20 >>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>=20 >>>> Hi Jeff, >>>>=20 >>>> Let me understand this. If you have an IP interface over a=20 >>> LAG with 5 component links, then you internally establish 5=20 >>> BFD sessions with 30ms timeouts? >>>>=20 >>>> You don't need to do this. You could use LACP for lag and=20 >>> BFD for IP connectivity - which means BFD should remain up as=20 >>> long as there is reachability over the lag. IMO it has no=20 >>> business to bother with each individual component links.=20 >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> -----Original Message----- >>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>> Sent: Friday, July 29, 2011 7:15 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hi, >>>>=20 >>>> We have been supporting this mode of BFD over LAG=20 >>> operations for last 5 years and our customers love it. >>>>=20 >>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>> hit min-links, do you really want to bring the LAG down? >>>>=20 >>>> Mach - be aware of patents :) >>>>=20 >>>> Regards, >>>> Jeff >>>>=20 >>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>> wrote: >>>>=20 >>>>> Hi Mach, >>>>>=20 >>>>> I am not sure I understand why you would want BFD to=20 >>> ensure liveliness of each component link in a LAG. The draft=20 >>> seems to suggest establishing separate BFD session for each=20 >>> pair of component interfaces to detect the failures. Why=20 >>> should BFD be concerned about each component link? I would=20 >>> rather that BFD sprays packets over each component link in a=20 >>> round robin fashion and brings down the IP interface over a=20 >>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org=20 >>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>> Behalf Of Mach Chen >>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We uploaded a new=20 >>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>> interface). You are very welcome to read the draft and give=20 >>> your comments. >>>>>=20 >>>>> Many thanks, >>>>> Mach >>>>=20 >>>=20 >>> -- >>> Marc Binderberger >>>=20 >>>=20 >=20 From davari@broadcom.com Mon Aug 1 10:16:30 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B34B11E8077 for ; Mon, 1 Aug 2011 10:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIK5wvgXKjly for ; Mon, 1 Aug 2011 10:16:29 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6B511E812C for ; Mon, 1 Aug 2011 10:16:29 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 01 Aug 2011 10:21:38 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 1 Aug 2011 10:16:24 -0700 From: "Shahram Davari" To: "Warren Kumari" , "Thomas Nadeau" Date: Mon, 1 Aug 2011 10:16:19 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQYTWmyx5SMKA6T6uUcGSrPK7CaAADI06A Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> In-Reply-To: <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62283F283W4513544-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 17:16:30 -0000 Let's do the math: BFD Tx direction: My Discr: Auto assignment by SW Your Discr: default to 0 Remote IP add: need to configure Min Tx interval: need to configure Min Rx interval: need to configure BFD Rx direction: Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) Remote Tx interval: learn Remote Rx interval: learn CFM Tx direction: MD name: Auto assign for all MDL=3D0 (such as LinkMD) MDL: need to configure MDL=3D0 MEPID: Auto assign by SW UP/Down: SW can automatically set to down for all MDL=3D0 Tx Rate: need to configure CFM Rx direction: MD name: Learn (unknown MDL redirected to CPU for learning) MDL: Learn (unknown MDL redirected to CPU for learning) MEPID: Learn (unknown MEPID redirected to CPU for learning) UP/Down: SW sets to Down for all MDL=3D0=20 Rx rate: need to configure As you can see there isn't much difference in configuration of BFD and 802.= 1ag for Link OAM. For BFD one needs to configure the Remote IP address and = the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx rat= e. So your argument is moot. Regards Shahram -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, August 01, 2011 8:39 AM To: Thomas Nadeau Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 > On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >=20 >> Hi Shane, >>=20 >> Same for BFD. You need to know my discriminator, your discriminator, loc= al IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand = mode, Authentication, Active/Passive, Detection Interval, etc. >=20 > While those parameters are required, that doesn't mean that clever imple= mentations can choose reasonable defaults for you. I know such implementati= ons from at least 3 major vendors. *) +1 Yes -- and a lot of operators already use BFD in their networks, they are a= lready familiar with the protocol, their tools already understand generatio= n of configlets (and auditing), etc. It already "just works" -- having it r= un on component link seems like a no brainer.... >=20 >> Believe me BFD requires more configuration than 802.1ag. So your argumen= t of requiring a lot of info to configure 802.1ag applies even more to BFD.= =20 >=20 > On paper perhaps, but in reality that is not the case. I do not know of= any implementations where MIP/MEP configuration is done automatically such= as is the case for links and routing protocols in the major implementation= s using BFD. >=20 > --Tom >=20 >=20 >>=20 >> Regards >> Shahram =20 >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beha= lf Of Shane Amante >> Sent: Saturday, July 30, 2011 9:36 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >> Manav, Sharam, Others, >>=20 >> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>> I think the diagnoses is correct, but the medicine isn't! :-) >>>=20 >>> I completely agree that LACP is not fast enough and that operators also= want to detect individual component link breakdowns instead of the entire = LAG. If that's the case then folks should use IEEE 802.1ag for individual c= omponent links and BFD for the entire LAG. Are we trying to position BFD as= an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over = component links since not all links may be ethernet? >>=20 >> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731= (or 802.3ah) for *fast* detection of component-link failures in a LAG is: = operational simplicity, clear and simple. >>=20 >> The problem with 802.1ag/Y.1731 is the massive amount of, potentially er= ror-prone, configuration required. Take a moment and think about how many = variables are *required* to properly set-up 802.1ag/Y.1731: >> a) What MD "name" should you use? >> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >> c) What MD "level" should you use, (probably 0 or 1)? >> d) What MEP ID's do I assign to each side of the link? >> e) Don't forget to configure the right direction, up or down, for the M= EP? >> ... that is *ridiculous*! >>=20 >> Let's not forget that there are [potentially] 100's if not 1,000's of LA= G's in each carrier's network, so this needs to get repeated over and over = and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up= *and* maintain. =20 >>=20 >> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx}= interval". (The "multiplier" should default to 3, unless you want to conf= igure it differently). That's it! Done! >>=20 >> So, in short, let me throw my hat in the ring with other operators that = I really, really, really want a standards-based way of running BFD over com= ponent-links in a LAG in order to quickly detect a component-link failure a= nd take it out of the bundle. >>=20 >> Thanks, >>=20 >> -shane >>=20 >>=20 >>=20 >>> I think (and this is also what Shahram was alluding to) that BFD is mea= nt to detect IP liveliness. This means that if I run BFD over an IP interfa= ce it should bring it down only when the IP connectivity goes down. Shouldn= 't BFD be oblivious to the number of links alive in a LAG as long as the LA= G remains up and it can reach the other end. It is a simple implementation = effort to note the status of each component link of a lag and to bring it d= own if the number goes below a certain threshold - You don't need to run BF= D over each link! >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>> Sent: Saturday, July 30, 2011 3:34 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Hello Manav, >>>>=20 >>>> others have already replied but the part "[...] has no=20 >>>> business" triggers now my reply. I deliberately=20 >>>> "mis"-understand it. Point is that this is about business.=20 >>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>> component links. Reasons I know >>>>=20 >>>> - LACP is not fast enough >>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>> Designers and Operations, so they would like to use it everywhere >>>> - BFDs reputation for being fast and working >>>>=20 >>>>=20 >>>> So now we have 3-4 different implementation for=20 >>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>> exists more. Probably not that much different but enough to=20 >>>> make interoperability impossible. It's again customers who=20 >>>> push now for standardization. Thus the draft to find an agreement :-) >>>>=20 >>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>> as I see two fundamental setups: (a) run BFD on every=20 >>>> component link and (b) run a single BFD session over the LAG=20 >>>> interface. They solve different network setups as far as I can see. >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>=20 >>>>> Hi Jeff, >>>>>=20 >>>>> Let me understand this. If you have an IP interface over a=20 >>>> LAG with 5 component links, then you internally establish 5=20 >>>> BFD sessions with 30ms timeouts? >>>>>=20 >>>>> You don't need to do this. You could use LACP for lag and=20 >>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>> long as there is reachability over the lag. IMO it has no=20 >>>> business to bother with each individual component links.=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> We have been supporting this mode of BFD over LAG=20 >>>> operations for last 5 years and our customers love it. >>>>>=20 >>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>> hit min-links, do you really want to bring the LAG down? >>>>>=20 >>>>> Mach - be aware of patents :) >>>>>=20 >>>>> Regards, >>>>> Jeff >>>>>=20 >>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>> wrote: >>>>>=20 >>>>>> Hi Mach, >>>>>>=20 >>>>>> I am not sure I understand why you would want BFD to=20 >>>> ensure liveliness of each component link in a LAG. The draft=20 >>>> seems to suggest establishing separate BFD session for each=20 >>>> pair of component interfaces to detect the failures. Why=20 >>>> should BFD be concerned about each component link? I would=20 >>>> rather that BFD sprays packets over each component link in a=20 >>>> round robin fashion and brings down the IP interface over a=20 >>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>> Behalf Of Mach Chen >>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>> To: rtg-bfd@ietf.org >>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We uploaded a new=20 >>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>> interface). You are very welcome to read the draft and give=20 >>>> your comments. >>>>>>=20 >>>>>> Many thanks, >>>>>> Mach >>>>>=20 >>>>=20 >>>> -- >>>> Marc Binderberger >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >>=20 >=20 From shane@castlepoint.net Mon Aug 1 11:53:31 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A20911E8137 for ; Mon, 1 Aug 2011 11:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLuV10HVERXL for ; Mon, 1 Aug 2011 11:53:28 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7319611E8077 for ; Mon, 1 Aug 2011 11:53:28 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 402CF268037; Mon, 1 Aug 2011 12:53:35 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Aug 2011 12:53:35 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=51538; data-bytes=0 Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 1 Aug 2011 12:53:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <04BFDB34-4D9A-4EBE-ADF3-9B7DD969E354@castlepoint.net> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 18:53:31 -0000 Let's do the correct math ... On Aug 1, 2011, at 11:16 AM, Shahram Davari wrote: > Let's do the math: >=20 > BFD Tx direction: >=20 > My Discr: Auto assignment by SW > Your Discr: default to 0 OK. But, what you're saying is that I, as an operator, do not need to = configure them. The SW is automatically configuring them on my behalf. = So, these don't count against BFD. > Remote IP add: need to configure No. This is automatically gleaned from the IGP routing protocol that is = bootstrapping BFD. And, note that with IGP routing protocols you /are = not/ configuring a remote IP address. You *auto-discover* the remote IP = address by virtue of forming a IGP neighbor relationship. > Min Tx interval: need to configure > Min Rx interval: need to configure Partially correct. First, IMO, implementations MAY use the same value = for the Tx & Rx interval, so you could compress this down to one = variable that needs to be configured. Second, I think this is a "wash", = in that you would need to configure this value for *either* BFD or = 802.1ag/Y.1731, since only an operator is either going to know what they = want their detection interval to be and/or what their equipment is = capable of, in terms of the frequency at which it can send/recv BFD or = Ethernet CFM PDU's. > BFD Rx direction: >=20 > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn Agreed. So, based on the above, it appears that for most implementations there = is only 1 variable (interval) that BFD requires to be configured on = *each side* of the link. Would you agree? > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) And, hope that either: a) that doesn't conflict with another MD that = already exists on that device/LAN; or, b) if it does, that the SW balks = at the operator loudly to manually fix the problem. Sure, you can write = this into documentation and try to train us operators not to use this = auto-assigned or preconfigured name, but mistakes can/do happen ...=20 Also, didn't you forget about Maintenance Association (MA)? Are you = proposing this is auto-magically assigned too? Given that we'd probably = want to have separate MA's assigned per LAG, (in order to have a = separate "container" for the MEP ID's used for all component-links in a = specific LAG), you'd need to either: a) manually configure a unique MA = per LAG; or, b) find a way to auto-assign it that doesn't conflict with = MA's already being used (either manually config'd or auto-generated). > MDL: need to configure MDL=3D0 OK, so that's 1 variable. > MEPID: Auto assign by SW How? (My question pertains to how do you avoid conflicting/overlapping = MEP ID's both on the local & remote devices and/or auto-magically "fix" = them when overlaps/conflicts do happen). > UP/Down: SW can automatically set to down for all MDL=3D0 Agreed. > Tx Rate: need to configure Agreed, but as I said above this is a wash for BFD & Ethernet CFM: both = need this. But, this is (at a minimum) 2 variables so far on the Tx = side. > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) Interesting; however, to my knowledge, there exists nothing in IEEE = 802.1ag/ITU Y.1731 to negotiate a 'master/slave' relationship, which you = would need to resolve conflicts with the above naming/ID's. = Specifically, let's say you had: DeviceA <---> DeviceB If both DeviceA and DeviceB start off transmitting = auto-assigned/auto-generated MD's, MA's, MEPID's, etc. then which one is = supposed to back-off and accept the other's parameters? Or, more = worrisome, what happens when [somehow] DeviceA is identified as the = "master" and DeviceB is supposed to automatically accept all of the = recv'd parameters, but one (or more) of them conflicts? For example, I = can easily see a case where DeviceA is sending a MEPID #1 toward = DeviceB, however DeviceB is already configured (or, has auto-assigned) = to use MEPID #1 for some other purpose, (e.g.: perhaps it has = auto-assigned this to another component-link in LAG toward a third = device, DeviceC). > UP/Down: SW sets to Down for all MDL=3D0=20 > Rx rate: need to configure OK. So, even if one accepts your theoretical proposal, that's still 2 = variables required on the Tx side and 1 variable required on the Rx = side. But, I think there is still substantial work to do with your = proposal in order to ensure that both devices are able to successful = negotiate their "role", (e.g.: master/slave), and also to resolve = potential conflicts with ID's/names that you propose are going to be = "automagically negotiated". > As you can see there isn't much difference in configuration of BFD and = 802.1ag for Link OAM. For BFD one needs to configure the Remote IP = address and the Tx/Rx rate and for OAM one needs to configure the MDL = and the Tx/Rx rate. Umm, no. One only needs to configure a 'interval' BFD and the rest is = bootstrapped either by the IGP routing protocol or by sensible defaults = within the implementation. =20 Furthermore, I still think there's much more significant details that = need to be sorted out before such a proposal could be considered = "operationally feasible" to be deployed in a reliable & robust fashion. = =46rom what I've seen, so far, IEEE 802.1ag/ITU Y.1731 were originally = designed to operate on a principle of doing [exactly] what they're = configured (i.e.: told) to do ... there is no "negotiation" of critical = configuration parameters in those protocols. So, what you're proposing = seems like a very fundamental change to either, or both, of those = protocols. (This is unlike BFD, where automatic "negotiation" of = various parameters was/is a fundamental foundation of the protocol from = Day 1). Finally, I would add that this is the BFD WG mailing list and working = out those details is definitely not within scope of the IETF. If you're = excited about your proposal, then perhaps you could take it to the IETF = and/or ITU and work in those organizations to make 802.1ag/Y.1731 more = "palatable" for LAG's? > So your argument is moot. I'm afraid not, given the evidence that existing shipping = implementations support a much more simplified configuration model for = BFD compared to 802.1ag/Y.1731. -shane > Regards > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 >>=20 >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>=20 >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) >=20 > +1 >=20 > Yes -- and a lot of operators already use BFD in their networks, they = are already familiar with the protocol, their tools already understand = generation of configlets (and auditing), etc. It already "just works" -- = having it run on component link seems like a no brainer.... >=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 >>=20 >> On paper perhaps, but in reality that is not the case. I do not = know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, = potentially error-prone, configuration required. Take a moment and = think about how many variables are *required* to properly set-up = 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for = the MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's = of LAG's in each carrier's network, so this needs to get repeated over = and over and over again. Bottom-line: 802.1ag/Y.1731 is extremely = complex to set-up *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can = see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From davari@broadcom.com Mon Aug 1 12:37:01 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A08A11E813F for ; Mon, 1 Aug 2011 12:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taGCZDcG0pYj for ; Mon, 1 Aug 2011 12:36:59 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id A438411E8137 for ; Mon, 1 Aug 2011 12:36:59 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 01 Aug 2011 12:41:09 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 1 Aug 2011 12:35:54 -0700 From: "Shahram Davari" To: "Shane Amante" Date: Mon, 1 Aug 2011 12:35:53 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQfFcjHJqZKHB5QsKY3CiyQov1MQABVV5g Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB43E@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <04BFDB34-4D9A-4EBE-ADF3-9B7DD969E354@castlepoint.net> In-Reply-To: <04BFDB34-4D9A-4EBE-ADF3-9B7DD969E354@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6229DEDF3W4553282-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 19:37:01 -0000 Hi Shane, Even if we assume that BFD has less parameters to configure, we must look a= t the big picture. You only need to configure this once for your routers ph= ysical ports and you are done. There is no need for dynamic configuration a= s is needed for LSP and PW. Regards, Shahram -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net] Sent: Monday, August 01, 2011 11:54 AM To: Shahram Davari Cc: Warren Kumari; Thomas Nadeau; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Let's do the correct math ... On Aug 1, 2011, at 11:16 AM, Shahram Davari wrote: > Let's do the math: > > BFD Tx direction: > > My Discr: Auto assignment by SW > Your Discr: default to 0 OK. But, what you're saying is that I, as an operator, do not need to conf= igure them. The SW is automatically configuring them on my behalf. So, th= ese don't count against BFD. > Remote IP add: need to configure No. This is automatically gleaned from the IGP routing protocol that is bo= otstrapping BFD. And, note that with IGP routing protocols you /are not/ c= onfiguring a remote IP address. You *auto-discover* the remote IP address = by virtue of forming a IGP neighbor relationship. > Min Tx interval: need to configure > Min Rx interval: need to configure Partially correct. First, IMO, implementations MAY use the same value for = the Tx & Rx interval, so you could compress this down to one variable that = needs to be configured. Second, I think this is a "wash", in that you woul= d need to configure this value for *either* BFD or 802.1ag/Y.1731, since on= ly an operator is either going to know what they want their detection inter= val to be and/or what their equipment is capable of, in terms of the freque= ncy at which it can send/recv BFD or Ethernet CFM PDU's. > BFD Rx direction: > > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn Agreed. So, based on the above, it appears that for most implementations there is o= nly 1 variable (interval) that BFD requires to be configured on *each side*= of the link. Would you agree? > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) And, hope that either: a) that doesn't conflict with another MD that alread= y exists on that device/LAN; or, b) if it does, that the SW balks at the op= erator loudly to manually fix the problem. Sure, you can write this into d= ocumentation and try to train us operators not to use this auto-assigned or= preconfigured name, but mistakes can/do happen ... Also, didn't you forget about Maintenance Association (MA)? Are you propos= ing this is auto-magically assigned too? Given that we'd probably want to = have separate MA's assigned per LAG, (in order to have a separate "containe= r" for the MEP ID's used for all component-links in a specific LAG), you'd = need to either: a) manually configure a unique MA per LAG; or, b) find a wa= y to auto-assign it that doesn't conflict with MA's already being used (eit= her manually config'd or auto-generated). > MDL: need to configure MDL=3D0 OK, so that's 1 variable. > MEPID: Auto assign by SW How? (My question pertains to how do you avoid conflicting/overlapping MEP= ID's both on the local & remote devices and/or auto-magically "fix" them w= hen overlaps/conflicts do happen). > UP/Down: SW can automatically set to down for all MDL=3D0 Agreed. > Tx Rate: need to configure Agreed, but as I said above this is a wash for BFD & Ethernet CFM: both nee= d this. But, this is (at a minimum) 2 variables so far on the Tx side. > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) Interesting; however, to my knowledge, there exists nothing in IEEE 802.1ag= /ITU Y.1731 to negotiate a 'master/slave' relationship, which you would nee= d to resolve conflicts with the above naming/ID's. Specifically, let's say= you had: DeviceA <---> DeviceB If both DeviceA and DeviceB start off transmitting auto-assigned/auto-gener= ated MD's, MA's, MEPID's, etc. then which one is supposed to back-off and a= ccept the other's parameters? Or, more worrisome, what happens when [someh= ow] DeviceA is identified as the "master" and DeviceB is supposed to automa= tically accept all of the recv'd parameters, but one (or more) of them conf= licts? For example, I can easily see a case where DeviceA is sending a MEP= ID #1 toward DeviceB, however DeviceB is already configured (or, has auto-a= ssigned) to use MEPID #1 for some other purpose, (e.g.: perhaps it has auto= -assigned this to another component-link in LAG toward a third device, Devi= ceC). > UP/Down: SW sets to Down for all MDL=3D0 > Rx rate: need to configure OK. So, even if one accepts your theoretical proposal, that's still 2 vari= ables required on the Tx side and 1 variable required on the Rx side. But,= I think there is still substantial work to do with your proposal in order = to ensure that both devices are able to successful negotiate their "role", = (e.g.: master/slave), and also to resolve potential conflicts with ID's/nam= es that you propose are going to be "automagically negotiated". > As you can see there isn't much difference in configuration of BFD and 80= 2.1ag for Link OAM. For BFD one needs to configure the Remote IP address an= d the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx r= ate. Umm, no. One only needs to configure a 'interval' BFD and the rest is boot= strapped either by the IGP routing protocol or by sensible defaults within = the implementation. Furthermore, I still think there's much more significant details that need = to be sorted out before such a proposal could be considered "operationally = feasible" to be deployed in a reliable & robust fashion. From what I've se= en, so far, IEEE 802.1ag/ITU Y.1731 were originally designed to operate on = a principle of doing [exactly] what they're configured (i.e.: told) to do .= .. there is no "negotiation" of critical configuration parameters in those = protocols. So, what you're proposing seems like a very fundamental change = to either, or both, of those protocols. (This is unlike BFD, where automat= ic "negotiation" of various parameters was/is a fundamental foundation of t= he protocol from Day 1). Finally, I would add that this is the BFD WG mailing list and working out t= hose details is definitely not within scope of the IETF. If you're excited= about your proposal, then perhaps you could take it to the IETF and/or ITU= and work in those organizations to make 802.1ag/Y.1731 more "palatable" fo= r LAG's? > So your argument is moot. I'm afraid not, given the evidence that existing shipping implementations s= upport a much more simplified configuration model for BFD compared to 802.1= ag/Y.1731. -shane > Regards > Shahram > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: > >> >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >> >>> Hi Shane, >>> >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >> >> While those parameters are required, that doesn't mean that clever = implementations can choose reasonable defaults for you. I know such impleme= ntations from at least 3 major vendors. *) > > +1 > > Yes -- and a lot of operators already use BFD in their networks, they are= already familiar with the protocol, their tools already understand generat= ion of configlets (and auditing), etc. It already "just works" -- having it= run on component link seems like a no brainer.... > >> >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= . >> >> On paper perhaps, but in reality that is not the case. I do not kn= ow of any implementations where MIP/MEP configuration is done automatically= such as is the case for links and routing protocols in the major implement= ations using BFD. >> >> --Tom >> >> >>> >>> Regards >>> Shahram >>> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>> >>> Manav, Sharam, Others, >>> >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>> >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>> >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>> >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. Take a moment and think about how many= variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for the = MEP? >>> ... that is *ridiculous*! >>> >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-u= p *and* maintain. >>> >>> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx= } interval". (The "multiplier" should default to 3, unless you want to con= figure it differently). That's it! Done! >>> >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>> >>> Thanks, >>> >>> -shane >>> >>> >>> >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>> >>>>> Hello Manav, >>>>> >>>>> others have already replied but the part "[...] has no >>>>> business" triggers now my reply. I deliberately >>>>> "mis"-understand it. Point is that this is about business. >>>>> Customers have pushed their vendors to implement BFD over LAG >>>>> component links. Reasons I know >>>>> >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>> >>>>> >>>>> So now we have 3-4 different implementation for >>>>> per-cmponent-link BFD that I know about. Potentially there >>>>> exists more. Probably not that much different but enough to >>>>> make interoperability impossible. It's again customers who >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>> >>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>> as I see two fundamental setups: (a) run BFD on every >>>>> component link and (b) run a single BFD session over the LAG >>>>> interface. They solve different network setups as far as I can see. >>>>> >>>>> >>>>> Regards, Marc >>>>> >>>>> >>>>> >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>> >>>>>> Hi Jeff, >>>>>> >>>>>> Let me understand this. If you have an IP interface over a >>>>> LAG with 5 component links, then you internally establish 5 >>>>> BFD sessions with 30ms timeouts? >>>>>> >>>>>> You don't need to do this. You could use LACP for lag and >>>>> BFD for IP connectivity - which means BFD should remain up as >>>>> long as there is reachability over the lag. IMO it has no >>>>> business to bother with each individual component links. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>> >>>>>> Hi, >>>>>> >>>>>> We have been supporting this mode of BFD over LAG >>>>> operations for last 5 years and our customers love it. >>>>>> >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>> hit min-links, do you really want to bring the LAG down? >>>>>> >>>>>> Mach - be aware of patents :) >>>>>> >>>>>> Regards, >>>>>> Jeff >>>>>> >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>> wrote: >>>>>> >>>>>>> Hi Mach, >>>>>>> >>>>>>> I am not sure I understand why you would want BFD to >>>>> ensure liveliness of each component link in a LAG. The draft >>>>> seems to suggest establishing separate BFD session for each >>>>> pair of component interfaces to detect the failures. Why >>>>> should BFD be concerned about each component link? I would >>>>> rather that BFD sprays packets over each component link in a >>>>> round robin fashion and brings down the IP interface over a >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org >>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We uploaded a new >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>> interface). You are very welcome to read the draft and give >>>>> your comments. >>>>>>> >>>>>>> Many thanks, >>>>>>> Mach >>>>>> >>>>> >>>>> -- >>>>> Marc Binderberger >>>>> >>>>> >>> >>> >>> >>> >> > > > From warren@kumari.net Mon Aug 1 13:51:44 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962F51F0C3C for ; Mon, 1 Aug 2011 13:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1b9Z6r+2MPH for ; Mon, 1 Aug 2011 13:51:43 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6272E1F0C39 for ; Mon, 1 Aug 2011 13:51:43 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 50F131B404D1; Mon, 1 Aug 2011 16:51:40 -0400 (EDT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 1 Aug 2011 16:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" , Shane Amante X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 20:51:44 -0000 On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > Let's do the math: >=20 > BFD Tx direction: >=20 > My Discr: Auto assignment by SW > Your Discr: default to 0 > Remote IP add: need to configure > Min Tx interval: need to configure > Min Rx interval: need to configure >=20 > BFD Rx direction: >=20 > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn >=20 > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) > MDL: need to configure MDL=3D0 > MEPID: Auto assign by SW > UP/Down: SW can automatically set to down for all MDL=3D0 > Tx Rate: need to configure >=20 > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) > UP/Down: SW sets to Down for all MDL=3D0=20 > Rx rate: need to configure >=20 >=20 > As you can see there isn't much difference in configuration of BFD and = 802.1ag for Link OAM. For BFD one needs to configure the Remote IP = address and the Tx/Rx rate and for OAM one needs to configure the MDL = and the Tx/Rx rate. >=20 > So your argument is moot. Which part? You mean the "tools already understand generation of configlets (and = auditing)" bit? Please point to the bit where my (or most) CM systems = understands OAM config for major vendors... You mean the "operators are already familiar with the protocol" bit? = Hmmm, also no... =20 Maybe you don't buy that "a lot of operators already use BFD in their = networks"? Really? But, it has become apparent that you are not actually listening, so I've = lost interest.... W >=20 > Regards > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 >>=20 >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>=20 >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, = Demand mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) >=20 > +1 >=20 > Yes -- and a lot of operators already use BFD in their networks, they = are already familiar with the protocol, their tools already understand = generation of configlets (and auditing), etc. It already "just works" -- = having it run on component link seems like a no brainer.... >=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 >>=20 >> On paper perhaps, but in reality that is not the case. I do not = know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, = potentially error-prone, configuration required. Take a moment and = think about how many variables are *required* to properly set-up = 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for = the MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's = of LAG's in each carrier's network, so this needs to get repeated over = and over and over again. Bottom-line: 802.1ag/Y.1731 is extremely = complex to set-up *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP = interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can = see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From rajeenai@cisco.com Mon Aug 1 14:16:00 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6D1F0C4B for ; Mon, 1 Aug 2011 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdX9PbQrk2H4 for ; Mon, 1 Aug 2011 14:15:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCBB1F0C44 for ; Mon, 1 Aug 2011 14:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajeenai@cisco.com; l=524; q=dns/txt; s=iport; t=1312233367; x=1313442967; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=IOqRZemyJg1yoUUCiO2GhE6GQV8K535/L66etN0CA4I=; b=Xtnk3bnTtQe+tjd7494cdL6M7f86+9yjlwvGsKDxWRRABSvGf3UvHDmU DH+G7c9oH2zTSx1JaEbL0sFCSen4MVHSgQ5eazApIqkPZwAbaZNoY7ayf IQaJl+L2kUXAgdELjN0kFMh1TXV5kHbhh9Kfl9ZyAFaWkTZSHyn0ufbj0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACkXN06rRDoI/2dsb2JhbABCp193gTkHAQEBAQIBEgEnPwULC0ZXBjWHSgSheQGeboVjXwSHWoshkQQ X-IronPort-AV: E=Sophos;i="4.67,302,1309737600"; d="scan'208";a="8574127" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2011 21:16:06 +0000 Received: from dhcp-171-71-55-230.cisco.com (dhcp-171-71-55-230.cisco.com [171.71.55.230]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71LG6ta000988; Mon, 1 Aug 2011 21:16:06 GMT Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rajeev Nair In-Reply-To: Date: Mon, 1 Aug 2011 14:16:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> References: To: Mach Chen X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 21:16:00 -0000 Hi Mach, Does this scheme (or a current per-link implementation) work with a = port-channel that is not connected back-to-back ?=20 i.e. L3 port-channels with L2 cloud in between ? thanks Rajeev On Jul 28, 2011, at 3:34 PM, Mach Chen wrote: > Hi, >=20 > We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >=20 > Many thanks, > Mach From davari@broadcom.com Mon Aug 1 14:24:42 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646A71F0C4D for ; Mon, 1 Aug 2011 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Or7TtclAZ+g for ; Mon, 1 Aug 2011 14:24:41 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1031F0C4E for ; Mon, 1 Aug 2011 14:24:41 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 01 Aug 2011 14:27:22 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 1 Aug 2011 14:22:24 -0700 From: "Shahram Davari" To: "Warren Kumari" Date: Mon, 1 Aug 2011 14:22:23 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQjNcYAyzp3qJ/S+mPe1aMZKuslgAA5feg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> In-Reply-To: <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6229C5B03KO1604930-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , Shane Amante X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2011 21:24:42 -0000 It doesn't matter if BFD is easier to configure since you need to configure= link OAM only once for some limited number of links in each router. Also the Argument that service providers are more familiar with BFD therefo= re lets use BFD for any required OAM is very dangerous. I am sure if this d= raft becomes and RFC then sooner or later drafts will pop up to use BFD for= Ethernet, SONET, OTN, PON, MLPPP, etc. I am sure IETF doesn't want to start a inter-operability nightmare. Shahram -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, August 01, 2011 1:52 PM To: Shahram Davari Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > Let's do the math: >=20 > BFD Tx direction: >=20 > My Discr: Auto assignment by SW > Your Discr: default to 0 > Remote IP add: need to configure > Min Tx interval: need to configure > Min Rx interval: need to configure >=20 > BFD Rx direction: >=20 > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn >=20 > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) > MDL: need to configure MDL=3D0 > MEPID: Auto assign by SW > UP/Down: SW can automatically set to down for all MDL=3D0 > Tx Rate: need to configure >=20 > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) > UP/Down: SW sets to Down for all MDL=3D0=20 > Rx rate: need to configure >=20 >=20 > As you can see there isn't much difference in configuration of BFD and 80= 2.1ag for Link OAM. For BFD one needs to configure the Remote IP address an= d the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx r= ate. >=20 > So your argument is moot. Which part? You mean the "tools already understand generation of configlets (and auditi= ng)" bit? Please point to the bit where my (or most) CM systems understands= OAM config for major vendors... You mean the "operators are already familiar with the protocol" bit? Hmmm, = also no... =20 Maybe you don't buy that "a lot of operators already use BFD in their netwo= rks"? Really? But, it has become apparent that you are not actually listening, so I've lo= st interest.... W >=20 > Regards > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 >>=20 >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>=20 >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> While those parameters are required, that doesn't mean that clever impl= ementations can choose reasonable defaults for you. I know such implementat= ions from at least 3 major vendors. *) >=20 > +1 >=20 > Yes -- and a lot of operators already use BFD in their networks, they are= already familiar with the protocol, their tools already understand generat= ion of configlets (and auditing), etc. It already "just works" -- having it= run on component link seems like a no brainer.... >=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= .=20 >>=20 >> On paper perhaps, but in reality that is not the case. I do not know o= f any implementations where MIP/MEP configuration is done automatically suc= h as is the case for links and routing protocols in the major implementatio= ns using BFD. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. Take a moment and think about how many= variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for the = MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-u= p *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx= } interval". (The "multiplier" should default to 3, unless you want to con= figure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From mach.chen@huawei.com Tue Aug 2 02:16:39 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1827321F8EC1 for ; Tue, 2 Aug 2011 02:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.922 X-Spam-Level: X-Spam-Status: No, score=-4.922 tagged_above=-999 required=5 tests=[AWL=1.677, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHZt75o2QZGw for ; Tue, 2 Aug 2011 02:16:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC521F8EBB for ; Tue, 2 Aug 2011 02:16:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPA008V3N3RI1@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Tue, 02 Aug 2011 17:16:39 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPA00D5MN3RHE@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Tue, 02 Aug 2011 17:16:39 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACZ26543; Tue, 02 Aug 2011 17:16:35 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 02 Aug 2011 17:16:32 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 02 Aug 2011 17:16:33 +0800 Date: Tue, 02 Aug 2011 09:16:32 +0000 From: Mach Chen Subject: RE: Solicit comments on BFD for Interface draft In-reply-to: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> X-Originating-IP: [10.110.98.131] To: Rajeev Nair Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Solicit comments on BFD for Interface draft Thread-index: AQHMTXaSGUO8YfsvQESe7fRUbEFVi5UH/5aAgAFBhRA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 09:16:39 -0000 Hi Rajeev, The solution does not consider the scenario you raised. It currently only works well for the links that are point-to-point, where packets sent from one side and will definitely come out from other side. Best regards, Mach > -----Original Message----- > From: Rajeev Nair [mailto:rajeenai@cisco.com] > Sent: Tuesday, August 02, 2011 5:17 AM > To: Mach Chen > Cc: rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > Hi Mach, > > Does this scheme (or a current per-link implementation) work with a > port-channel that is not connected back-to-back ? > i.e. L3 port-channels with L2 cloud in between ? > > thanks > Rajeev > > On Jul 28, 2011, at 3:34 PM, Mach Chen wrote: > > > Hi, > > > > We uploaded a new > draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD > running over interface(e.g., LAG/Bundle interface). You are very welcome to > read the draft and give your comments. > > > > Many thanks, > > Mach From tnadeau@lucidvision.com Tue Aug 2 04:54:22 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C233121F8BEC for ; Tue, 2 Aug 2011 04:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03d-7K7LKa6m for ; Tue, 2 Aug 2011 04:54:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 43B5621F873A for ; Tue, 2 Aug 2011 04:54:21 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A20051D48D31; Tue, 2 Aug 2011 07:54:29 -0400 (EDT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Nadeau In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 2 Aug 2011 07:54:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9110B5CD-B7A4-4D92-9A91-B8F950A6FFBB@lucidvision.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> To: "Shahram Davari" X-Mailer: Apple Mail (2.1244.3) Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 11:54:22 -0000 =09 On Aug 1, 2011, at 5:22 PM, Shahram Davari wrote: > It doesn't matter if BFD is easier to configure since you need to = configure link OAM only once for some limited number of links in each = router. Until you add another link (or interface), in which case BFD is = automatically configured in most implementations (globally). But I guess = links being added never happens in your operational world? > Also the Argument that service providers are more familiar with BFD = therefore lets use BFD for any required OAM is very dangerous. I am sure = if this draft becomes and RFC then sooner or later drafts will pop up to = use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc. Why is it dangerous? Please explain. And to the effect of = using BFD for ethernet/sonet/etc=85 that has already been tried and = failed about 6 years ago, so let us please not go there. > I am sure IETF doesn't want to start a inter-operability nightmare. It doesn't, and this is one of the reasons why many of us = (myself included) advocated to not take that route. --Tom >=20 > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 1:52 PM > To: Shahram Davari > Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: >=20 >> Let's do the math: >>=20 >> BFD Tx direction: >>=20 >> My Discr: Auto assignment by SW >> Your Discr: default to 0 >> Remote IP add: need to configure >> Min Tx interval: need to configure >> Min Rx interval: need to configure >>=20 >> BFD Rx direction: >>=20 >> Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) >> Remote Tx interval: learn >> Remote Rx interval: learn >>=20 >> CFM Tx direction: >> MD name: Auto assign for all MDL=3D0 (such as LinkMD) >> MDL: need to configure MDL=3D0 >> MEPID: Auto assign by SW >> UP/Down: SW can automatically set to down for all MDL=3D0 >> Tx Rate: need to configure >>=20 >> CFM Rx direction: >> MD name: Learn (unknown MDL redirected to CPU for learning) >> MDL: Learn (unknown MDL redirected to CPU for learning) >> MEPID: Learn (unknown MEPID redirected to CPU for learning) >> UP/Down: SW sets to Down for all MDL=3D0=20 >> Rx rate: need to configure >>=20 >>=20 >> As you can see there isn't much difference in configuration of BFD = and 802.1ag for Link OAM. For BFD one needs to configure the Remote IP = address and the Tx/Rx rate and for OAM one needs to configure the MDL = and the Tx/Rx rate. >>=20 >> So your argument is moot. >=20 > Which part? >=20 > You mean the "tools already understand generation of configlets (and = auditing)" bit? Please point to the bit where my (or most) CM systems = understands OAM config for major vendors... >=20 > You mean the "operators are already familiar with the protocol" bit? = Hmmm, also no... =20 >=20 > Maybe you don't buy that "a lot of operators already use BFD in their = networks"? Really? >=20 > But, it has become apparent that you are not actually listening, so = I've lost interest.... >=20 > W >=20 >>=20 >> Regards >> Shahram >>=20 >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net]=20 >> Sent: Monday, August 01, 2011 8:39 AM >> To: Thomas Nadeau >> Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >>=20 >> On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >>=20 >>>=20 >>> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>>=20 >>>> Hi Shane, >>>>=20 >>>> Same for BFD. You need to know my discriminator, your = discriminator, local IP address, remote IP address, Min Tx Interval, Min = Rx Interval, Demand mode, Authentication, Active/Passive, Detection = Interval, etc. >>>=20 >>> While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) >>=20 >> +1 >>=20 >> Yes -- and a lot of operators already use BFD in their networks, they = are already familiar with the protocol, their tools already understand = generation of configlets (and auditing), etc. It already "just works" -- = having it run on component link seems like a no brainer.... >>=20 >>>=20 >>>> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD.=20 >>>=20 >>> On paper perhaps, but in reality that is not the case. I do not = know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Regards >>>> Shahram =20 >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >>>> Sent: Saturday, July 30, 2011 9:36 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Manav, Sharam, Others, >>>>=20 >>>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>>=20 >>>>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>>>=20 >>>> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>>>=20 >>>> The problem with 802.1ag/Y.1731 is the massive amount of, = potentially error-prone, configuration required. Take a moment and = think about how many variables are *required* to properly set-up = 802.1ag/Y.1731: >>>> a) What MD "name" should you use? >>>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>>> c) What MD "level" should you use, (probably 0 or 1)? >>>> d) What MEP ID's do I assign to each side of the link? >>>> e) Don't forget to configure the right direction, up or down, for = the MEP? >>>> ... that is *ridiculous*! >>>>=20 >>>> Let's not forget that there are [potentially] 100's if not 1,000's = of LAG's in each carrier's network, so this needs to get repeated over = and over and over again. Bottom-line: 802.1ag/Y.1731 is extremely = complex to set-up *and* maintain. =20 >>>>=20 >>>> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>>>=20 >>>> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> -shane >>>>=20 >>>>=20 >>>>=20 >>>>> I think (and this is also what Shahram was alluding to) that BFD = is meant to detect IP liveliness. This means that if I run BFD over an = IP interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hello Manav, >>>>>>=20 >>>>>> others have already replied but the part "[...] has no=20 >>>>>> business" triggers now my reply. I deliberately=20 >>>>>> "mis"-understand it. Point is that this is about business.=20 >>>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>>> component links. Reasons I know >>>>>>=20 >>>>>> - LACP is not fast enough >>>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>>> Designers and Operations, so they would like to use it everywhere >>>>>> - BFDs reputation for being fast and working >>>>>>=20 >>>>>>=20 >>>>>> So now we have 3-4 different implementation for=20 >>>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>>> exists more. Probably not that much different but enough to=20 >>>>>> make interoperability impossible. It's again customers who=20 >>>>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>>>=20 >>>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>>> component link and (b) run a single BFD session over the LAG=20 >>>>>> interface. They solve different network setups as far as I can = see. >>>>>>=20 >>>>>>=20 >>>>>> Regards, Marc >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>>=20 >>>>>>> Hi Jeff, >>>>>>>=20 >>>>>>> Let me understand this. If you have an IP interface over a=20 >>>>>> LAG with 5 component links, then you internally establish 5=20 >>>>>> BFD sessions with 30ms timeouts? >>>>>>>=20 >>>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>>> long as there is reachability over the lag. IMO it has no=20 >>>>>> business to bother with each individual component links.=20 >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>>> To: Bhatia, Manav (Manav) >>>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We have been supporting this mode of BFD over LAG=20 >>>>>> operations for last 5 years and our customers love it. >>>>>>>=20 >>>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>>> hit min-links, do you really want to bring the LAG down? >>>>>>>=20 >>>>>>> Mach - be aware of patents :) >>>>>>>=20 >>>>>>> Regards, >>>>>>> Jeff >>>>>>>=20 >>>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Mach, >>>>>>>>=20 >>>>>>>> I am not sure I understand why you would want BFD to=20 >>>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>>> seems to suggest establishing separate BFD session for each=20 >>>>>> pair of component interfaces to detect the failures. Why=20 >>>>>> should BFD be concerned about each component link? I would=20 >>>>>> rather that BFD sprays packets over each component link in a=20 >>>>>> round robin fashion and brings down the IP interface over a=20 >>>>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>>>=20 >>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Mach Chen >>>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>>> To: rtg-bfd@ietf.org >>>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> We uploaded a new=20 >>>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>>> interface). You are very welcome to read the draft and give=20 >>>>>> your comments. >>>>>>>>=20 >>>>>>>> Many thanks, >>>>>>>> Mach >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Marc Binderberger >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 From jeff.tantsura@ericsson.com Tue Aug 2 12:32:02 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A674021F8574 for ; Tue, 2 Aug 2011 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4WVh3BG7xXV for ; Tue, 2 Aug 2011 12:32:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6421F8571 for ; Tue, 2 Aug 2011 12:32:01 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p72JVhfx019139; Tue, 2 Aug 2011 14:31:45 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 2 Aug 2011 15:31:41 -0400 From: Jeff Tantsura To: Shahram Davari , Warren Kumari Date: Tue, 2 Aug 2011 15:31:39 -0400 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQjNcYAyzp3qJ/S+mPe1aMZKuslgAA5fegAAJN2EA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 19:32:02 -0000 Hi Shahram, Have you ever talked to a "live" customer? You should be grateful for Shane's and Warren's comments providing their po= int of view. At the end your salary is paid by them...=20 Regards, Jeff =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Monday, August 01, 2011 14:22 To: Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft It doesn't matter if BFD is easier to configure since you need to configure= link OAM only once for some limited number of links in each router. Also the Argument that service providers are more familiar with BFD therefo= re lets use BFD for any required OAM is very dangerous. I am sure if this d= raft becomes and RFC then sooner or later drafts will pop up to use BFD for= Ethernet, SONET, OTN, PON, MLPPP, etc. I am sure IETF doesn't want to start a inter-operability nightmare. Shahram -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, August 01, 2011 1:52 PM To: Shahram Davari Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > Let's do the math: >=20 > BFD Tx direction: >=20 > My Discr: Auto assignment by SW > Your Discr: default to 0 > Remote IP add: need to configure > Min Tx interval: need to configure > Min Rx interval: need to configure >=20 > BFD Rx direction: >=20 > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn >=20 > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) > MDL: need to configure MDL=3D0 > MEPID: Auto assign by SW > UP/Down: SW can automatically set to down for all MDL=3D0 > Tx Rate: need to configure >=20 > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) > UP/Down: SW sets to Down for all MDL=3D0=20 > Rx rate: need to configure >=20 >=20 > As you can see there isn't much difference in configuration of BFD and 80= 2.1ag for Link OAM. For BFD one needs to configure the Remote IP address an= d the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx r= ate. >=20 > So your argument is moot. Which part? You mean the "tools already understand generation of configlets (and auditi= ng)" bit? Please point to the bit where my (or most) CM systems understands= OAM config for major vendors... You mean the "operators are already familiar with the protocol" bit? Hmmm, = also no... =20 Maybe you don't buy that "a lot of operators already use BFD in their netwo= rks"? Really? But, it has become apparent that you are not actually listening, so I've lo= st interest.... W >=20 > Regards > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 >>=20 >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>=20 >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> While those parameters are required, that doesn't mean that clever impl= ementations can choose reasonable defaults for you. I know such implementat= ions from at least 3 major vendors. *) >=20 > +1 >=20 > Yes -- and a lot of operators already use BFD in their networks, they are= already familiar with the protocol, their tools already understand generat= ion of configlets (and auditing), etc. It already "just works" -- having it= run on component link seems like a no brainer.... >=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= .=20 >>=20 >> On paper perhaps, but in reality that is not the case. I do not know o= f any implementations where MIP/MEP configuration is done automatically suc= h as is the case for links and routing protocols in the major implementatio= ns using BFD. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. Take a moment and think about how many= variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for the = MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-u= p *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx= } interval". (The "multiplier" should default to 3, unless you want to con= figure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From davari@broadcom.com Tue Aug 2 12:36:52 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8E31F0C44 for ; Tue, 2 Aug 2011 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-gKbiGFFMtF for ; Tue, 2 Aug 2011 12:36:51 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76B781F0C39 for ; Tue, 2 Aug 2011 12:36:51 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 02 Aug 2011 12:41:37 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 2 Aug 2011 12:36:21 -0700 From: "Shahram Davari" To: "Thomas Nadeau" Date: Tue, 2 Aug 2011 12:36:19 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxRCvp/4UyF/wTPRb+p+aDJvu9TYAAPaYQg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBBFE@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <9110B5CD-B7A4-4D92-9A91-B8F950A6FFBB@lucidvision.com> In-Reply-To: <9110B5CD-B7A4-4D92-9A91-B8F950A6FFBB@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62268D7B3W4895973-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 19:36:52 -0000 Please see inline. -Shahram -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Tuesday, August 02, 2011 4:54 AM To: Shahram Davari Cc: Warren Kumari; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft =09 On Aug 1, 2011, at 5:22 PM, Shahram Davari wrote: > It doesn't matter if BFD is easier to configure since you need to configu= re link OAM only once for some limited number of links in each router. Until you add another link (or interface), in which case BFD is automatica= lly configured in most implementations (globally). But I guess links being = added never happens in your operational world? [SD] Adding a link can happen and as I said you could configure Ethernet OA= M in advance on all Links that need OAM and just enable or disable OAM as n= eeded automatically.=20 > Also the Argument that service providers are more familiar with BFD there= fore lets use BFD for any required OAM is very dangerous. I am sure if this= draft becomes and RFC then sooner or later drafts will pop up to use BFD f= or Ethernet, SONET, OTN, PON, MLPPP, etc. Why is it dangerous? Please explain. And to the effect of using BFD for = ethernet/sonet/etc... that has already been tried and failed about 6 years = ago, so let us please not go there. [SD] using client layer OAM (IP BFD) to proxy for server layer (Ethernet Li= nk) is not a good idea because of many reasons such as: 1) It only works if the client is IP. For example it won't work in MPLS-TP = network 2) It may detect link level connectivity loss, but can't diagnose the probl= em. you still need Server Layer OAM for diagnosing and fixing the problem 3) It is not clear how to force BFD to take a specific Link. It is also not= clear how one can run BFD on a link that is disabled so that one ensures t= hat link is healthy before adding it to the bundle. These may require HW ch= ange.=20 > I am sure IETF doesn't want to start a inter-operability nightmare. It doesn't, and this is one of the reasons why many of us (myself included= ) advocated to not take that route. --Tom >=20 > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 1:52 PM > To: Shahram Davari > Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: >=20 >> Let's do the math: >>=20 >> BFD Tx direction: >>=20 >> My Discr: Auto assignment by SW >> Your Discr: default to 0 >> Remote IP add: need to configure >> Min Tx interval: need to configure >> Min Rx interval: need to configure >>=20 >> BFD Rx direction: >>=20 >> Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) >> Remote Tx interval: learn >> Remote Rx interval: learn >>=20 >> CFM Tx direction: >> MD name: Auto assign for all MDL=3D0 (such as LinkMD) >> MDL: need to configure MDL=3D0 >> MEPID: Auto assign by SW >> UP/Down: SW can automatically set to down for all MDL=3D0 >> Tx Rate: need to configure >>=20 >> CFM Rx direction: >> MD name: Learn (unknown MDL redirected to CPU for learning) >> MDL: Learn (unknown MDL redirected to CPU for learning) >> MEPID: Learn (unknown MEPID redirected to CPU for learning) >> UP/Down: SW sets to Down for all MDL=3D0=20 >> Rx rate: need to configure >>=20 >>=20 >> As you can see there isn't much difference in configuration of BFD and 8= 02.1ag for Link OAM. For BFD one needs to configure the Remote IP address a= nd the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx = rate. >>=20 >> So your argument is moot. >=20 > Which part? >=20 > You mean the "tools already understand generation of configlets (and audi= ting)" bit? Please point to the bit where my (or most) CM systems understan= ds OAM config for major vendors... >=20 > You mean the "operators are already familiar with the protocol" bit? Hmmm= , also no... =20 >=20 > Maybe you don't buy that "a lot of operators already use BFD in their net= works"? Really? >=20 > But, it has become apparent that you are not actually listening, so I've = lost interest.... >=20 > W >=20 >>=20 >> Regards >> Shahram >>=20 >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net]=20 >> Sent: Monday, August 01, 2011 8:39 AM >> To: Thomas Nadeau >> Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >>=20 >> On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >>=20 >>>=20 >>> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>>=20 >>>> Hi Shane, >>>>=20 >>>> Same for BFD. You need to know my discriminator, your discriminator, l= ocal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Deman= d mode, Authentication, Active/Passive, Detection Interval, etc. >>>=20 >>> While those parameters are required, that doesn't mean that clever imp= lementations can choose reasonable defaults for you. I know such implementa= tions from at least 3 major vendors. *) >>=20 >> +1 >>=20 >> Yes -- and a lot of operators already use BFD in their networks, they ar= e already familiar with the protocol, their tools already understand genera= tion of configlets (and auditing), etc. It already "just works" -- having i= t run on component link seems like a no brainer.... >>=20 >>>=20 >>>> Believe me BFD requires more configuration than 802.1ag. So your argum= ent of requiring a lot of info to configure 802.1ag applies even more to BF= D.=20 >>>=20 >>> On paper perhaps, but in reality that is not the case. I do not know = of any implementations where MIP/MEP configuration is done automatically su= ch as is the case for links and routing protocols in the major implementati= ons using BFD. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Regards >>>> Shahram =20 >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Be= half Of Shane Amante >>>> Sent: Saturday, July 30, 2011 9:36 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Manav, Sharam, Others, >>>>=20 >>>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>>=20 >>>>> I completely agree that LACP is not fast enough and that operators al= so want to detect individual component link breakdowns instead of the entir= e LAG. If that's the case then folks should use IEEE 802.1ag for individual= component links and BFD for the entire LAG. Are we trying to position BFD = as an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD ove= r component links since not all links may be ethernet? >>>>=20 >>>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.17= 31 (or 802.3ah) for *fast* detection of component-link failures in a LAG is= : operational simplicity, clear and simple. >>>>=20 >>>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how man= y variables are *required* to properly set-up 802.1ag/Y.1731: >>>> a) What MD "name" should you use? >>>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>>> c) What MD "level" should you use, (probably 0 or 1)? >>>> d) What MEP ID's do I assign to each side of the link? >>>> e) Don't forget to configure the right direction, up or down, for the= MEP? >>>> ... that is *ridiculous*! >>>>=20 >>>> Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and ove= r and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-= up *and* maintain. =20 >>>>=20 >>>> BFD is simple. At a bare minimum you just need to configure an "{Tx|R= x} interval". (The "multiplier" should default to 3, unless you want to co= nfigure it differently). That's it! Done! >>>>=20 >>>> So, in short, let me throw my hat in the ring with other operators tha= t I really, really, really want a standards-based way of running BFD over c= omponent-links in a LAG in order to quickly detect a component-link failure= and take it out of the bundle. >=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> -shane >>>>=20 >>>>=20 >>>>=20 >>>>> I think (and this is also what Shahram was alluding to) that BFD is m= eant to detect IP liveliness. This means that if I run BFD over an IP inter= face it should bring it down only when the IP connectivity goes down. Shoul= dn't BFD be oblivious to the number of links alive in a LAG as long as the = LAG remains up and it can reach the other end. It is a simple implementatio= n effort to note the status of each component link of a lag and to bring it= down if the number goes below a certain threshold - You don't need to run = BFD over each link! >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hello Manav, >>>>>>=20 >>>>>> others have already replied but the part "[...] has no=20 >>>>>> business" triggers now my reply. I deliberately=20 >>>>>> "mis"-understand it. Point is that this is about business.=20 >>>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>>> component links. Reasons I know >>>>>>=20 >>>>>> - LACP is not fast enough >>>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>>> Designers and Operations, so they would like to use it everywhere >>>>>> - BFDs reputation for being fast and working >>>>>>=20 >>>>>>=20 >>>>>> So now we have 3-4 different implementation for=20 >>>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>>> exists more. Probably not that much different but enough to=20 >>>>>> make interoperability impossible. It's again customers who=20 >>>>>> push now for standardization. Thus the draft to find an agreement :-= ) >>>>>>=20 >>>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>>> component link and (b) run a single BFD session over the LAG=20 >>>>>> interface. They solve different network setups as far as I can see. >>>>>>=20 >>>>>>=20 >>>>>> Regards, Marc >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>>=20 >>>>>>> Hi Jeff, >>>>>>>=20 >>>>>>> Let me understand this. If you have an IP interface over a=20 >>>>>> LAG with 5 component links, then you internally establish 5=20 >>>>>> BFD sessions with 30ms timeouts? >>>>>>>=20 >>>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>>> long as there is reachability over the lag. IMO it has no=20 >>>>>> business to bother with each individual component links.=20 >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>>> To: Bhatia, Manav (Manav) >>>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We have been supporting this mode of BFD over LAG=20 >>>>>> operations for last 5 years and our customers love it. >>>>>>>=20 >>>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>>> hit min-links, do you really want to bring the LAG down? >>>>>>>=20 >>>>>>> Mach - be aware of patents :) >>>>>>>=20 >>>>>>> Regards, >>>>>>> Jeff >>>>>>>=20 >>>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Mach, >>>>>>>>=20 >>>>>>>> I am not sure I understand why you would want BFD to=20 >>>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>>> seems to suggest establishing separate BFD session for each=20 >>>>>> pair of component interfaces to detect the failures. Why=20 >>>>>> should BFD be concerned about each component link? I would=20 >>>>>> rather that BFD sprays packets over each component link in a=20 >>>>>> round robin fashion and brings down the IP interface over a=20 >>>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>>>=20 >>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Mach Chen >>>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>>> To: rtg-bfd@ietf.org >>>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> We uploaded a new=20 >>>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>>> interface). You are very welcome to read the draft and give=20 >>>>>> your comments. >>>>>>>>=20 >>>>>>>> Many thanks, >>>>>>>> Mach >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Marc Binderberger >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 From davari@broadcom.com Tue Aug 2 12:45:37 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300C721F84E4 for ; Tue, 2 Aug 2011 12:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlN3k3+7Evlm for ; Tue, 2 Aug 2011 12:45:36 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0389821F84E2 for ; Tue, 2 Aug 2011 12:45:35 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 02 Aug 2011 12:50:38 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 2 Aug 2011 12:45:37 -0700 From: "Shahram Davari" To: "Jeff Tantsura" , "Warren Kumari" Date: Tue, 2 Aug 2011 12:45:37 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQjNcYAyzp3qJ/S+mPe1aMZKuslgAA5fegAAJN2EAALK1xQA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBC13@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62268A873KO1935227-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 19:45:37 -0000 Hi Jeff, Not only I have talked to a live customer but I have talked to live custome= r's customer as well. Also Shane and Warren are not paying my salary and my= intention is not to please them. Thx Shahram -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: Tuesday, August 02, 2011 12:32 PM To: Shahram Davari; Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft Hi Shahram, Have you ever talked to a "live" customer? You should be grateful for Shane's and Warren's comments providing their po= int of view. At the end your salary is paid by them...=20 Regards, Jeff =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Monday, August 01, 2011 14:22 To: Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft It doesn't matter if BFD is easier to configure since you need to configure= link OAM only once for some limited number of links in each router. Also the Argument that service providers are more familiar with BFD therefo= re lets use BFD for any required OAM is very dangerous. I am sure if this d= raft becomes and RFC then sooner or later drafts will pop up to use BFD for= Ethernet, SONET, OTN, PON, MLPPP, etc. I am sure IETF doesn't want to start a inter-operability nightmare. Shahram -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, August 01, 2011 1:52 PM To: Shahram Davari Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > Let's do the math: >=20 > BFD Tx direction: >=20 > My Discr: Auto assignment by SW > Your Discr: default to 0 > Remote IP add: need to configure > Min Tx interval: need to configure > Min Rx interval: need to configure >=20 > BFD Rx direction: >=20 > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn >=20 > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) > MDL: need to configure MDL=3D0 > MEPID: Auto assign by SW > UP/Down: SW can automatically set to down for all MDL=3D0 > Tx Rate: need to configure >=20 > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) > UP/Down: SW sets to Down for all MDL=3D0=20 > Rx rate: need to configure >=20 >=20 > As you can see there isn't much difference in configuration of BFD and 80= 2.1ag for Link OAM. For BFD one needs to configure the Remote IP address an= d the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx r= ate. >=20 > So your argument is moot. Which part? You mean the "tools already understand generation of configlets (and auditi= ng)" bit? Please point to the bit where my (or most) CM systems understands= OAM config for major vendors... You mean the "operators are already familiar with the protocol" bit? Hmmm, = also no... =20 Maybe you don't buy that "a lot of operators already use BFD in their netwo= rks"? Really? But, it has become apparent that you are not actually listening, so I've lo= st interest.... W >=20 > Regards > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 >>=20 >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>=20 >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> While those parameters are required, that doesn't mean that clever impl= ementations can choose reasonable defaults for you. I know such implementat= ions from at least 3 major vendors. *) >=20 > +1 >=20 > Yes -- and a lot of operators already use BFD in their networks, they are= already familiar with the protocol, their tools already understand generat= ion of configlets (and auditing), etc. It already "just works" -- having it= run on component link seems like a no brainer.... >=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= .=20 >>=20 >> On paper perhaps, but in reality that is not the case. I do not know o= f any implementations where MIP/MEP configuration is done automatically suc= h as is the case for links and routing protocols in the major implementatio= ns using BFD. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. Take a moment and think about how many= variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for the = MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-u= p *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx= } interval". (The "multiplier" should default to 3, unless you want to con= figure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From jeff.tantsura@ericsson.com Tue Aug 2 14:10:13 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D9721F84EF for ; Tue, 2 Aug 2011 14:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKC5m2bgMmRk for ; Tue, 2 Aug 2011 14:10:12 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D196B21F84E0 for ; Tue, 2 Aug 2011 14:10:11 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p72L9SYw017077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Aug 2011 16:09:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 2 Aug 2011 17:09:39 -0400 From: Jeff Tantsura To: Shahram Davari , Warren Kumari Date: Tue, 2 Aug 2011 17:09:38 -0400 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQjNcYAyzp3qJ/S+mPe1aMZKuslgAA5fegAAJN2EAALK1xQAACO68g Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6CCB@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBC13@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBC13@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 21:10:13 -0000 Hi Shahram, Please don't tell me you are making your products for the sake of making th= em or trying to make the world a better place. We did it because our customers asked us to, Cisco did it last year for exa= ctly same reasons. Others didn't because either their customers didn't real= ize how good it could work/ couldn't properly do it, mostly due to ASIC's l= imitations. Personally - I'm intimately familiar with at least 4 different vendors CLIs= - BFD is MUCH easier to configure on all of them. Another aspect of the story - historically BFD has been available on most p= latforms for at least 5 years while L2 OAM at sub 100ms just 2-3 years. /drama mode on "Dear vendor - we'd like to spend M $xxx on your products if you do per con= stituent BFD as we are familiar with it, like it and run it everywhere" - = =20 go away and don't come back - you bloody layer violator :) /drama mode off It would be great if we could interoperate with other vendors, our customer= s would greatly benefit! Regards, Jeff =20 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Tuesday, August 02, 2011 12:46 To: Jeff Tantsura; Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft Hi Jeff, Not only I have talked to a live customer but I have talked to live custome= r's customer as well. Also Shane and Warren are not paying my salary and my= intention is not to please them. Thx Shahram -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: Tuesday, August 02, 2011 12:32 PM To: Shahram Davari; Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft Hi Shahram, Have you ever talked to a "live" customer? You should be grateful for Shane's and Warren's comments providing their po= int of view. At the end your salary is paid by them...=20 Regards, Jeff =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Monday, August 01, 2011 14:22 To: Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft It doesn't matter if BFD is easier to configure since you need to configure= link OAM only once for some limited number of links in each router. Also the Argument that service providers are more familiar with BFD therefo= re lets use BFD for any required OAM is very dangerous. I am sure if this d= raft becomes and RFC then sooner or later drafts will pop up to use BFD for= Ethernet, SONET, OTN, PON, MLPPP, etc. I am sure IETF doesn't want to start a inter-operability nightmare. Shahram -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, August 01, 2011 1:52 PM To: Shahram Davari Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > Let's do the math: >=20 > BFD Tx direction: >=20 > My Discr: Auto assignment by SW > Your Discr: default to 0 > Remote IP add: need to configure > Min Tx interval: need to configure > Min Rx interval: need to configure >=20 > BFD Rx direction: >=20 > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn >=20 > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) > MDL: need to configure MDL=3D0 > MEPID: Auto assign by SW > UP/Down: SW can automatically set to down for all MDL=3D0 > Tx Rate: need to configure >=20 > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) > UP/Down: SW sets to Down for all MDL=3D0=20 > Rx rate: need to configure >=20 >=20 > As you can see there isn't much difference in configuration of BFD and 80= 2.1ag for Link OAM. For BFD one needs to configure the Remote IP address an= d the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx r= ate. >=20 > So your argument is moot. Which part? You mean the "tools already understand generation of configlets (and auditi= ng)" bit? Please point to the bit where my (or most) CM systems understands= OAM config for major vendors... You mean the "operators are already familiar with the protocol" bit? Hmmm, = also no... =20 Maybe you don't buy that "a lot of operators already use BFD in their netwo= rks"? Really? But, it has become apparent that you are not actually listening, so I've lo= st interest.... W >=20 > Regards > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >=20 >>=20 >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>=20 >>> Hi Shane, >>>=20 >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >>=20 >> While those parameters are required, that doesn't mean that clever impl= ementations can choose reasonable defaults for you. I know such implementat= ions from at least 3 major vendors. *) >=20 > +1 >=20 > Yes -- and a lot of operators already use BFD in their networks, they are= already familiar with the protocol, their tools already understand generat= ion of configlets (and auditing), etc. It already "just works" -- having it= run on component link seems like a no brainer.... >=20 >>=20 >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= .=20 >>=20 >> On paper perhaps, but in reality that is not the case. I do not know o= f any implementations where MIP/MEP configuration is done automatically suc= h as is the case for links and routing protocols in the major implementatio= ns using BFD. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards >>> Shahram =20 >>>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>> Manav, Sharam, Others, >>>=20 >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>=20 >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>>=20 >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>>=20 >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. Take a moment and think about how many= variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for the = MEP? >>> ... that is *ridiculous*! >>>=20 >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-u= p *and* maintain. =20 >>>=20 >>> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx= } interval". (The "multiplier" should default to 3, unless you want to con= figure it differently). That's it! Done! >>>=20 >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>>=20 >>> Thanks, >>>=20 >>> -shane >>>=20 >>>=20 >>>=20 >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de]=20 >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>=20 >>>>> Hello Manav, >>>>>=20 >>>>> others have already replied but the part "[...] has no=20 >>>>> business" triggers now my reply. I deliberately=20 >>>>> "mis"-understand it. Point is that this is about business.=20 >>>>> Customers have pushed their vendors to implement BFD over LAG=20 >>>>> component links. Reasons I know >>>>>=20 >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco=20 >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>>=20 >>>>>=20 >>>>> So now we have 3-4 different implementation for=20 >>>>> per-cmponent-link BFD that I know about. Potentially there=20 >>>>> exists more. Probably not that much different but enough to=20 >>>>> make interoperability impossible. It's again customers who=20 >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>>=20 >>>>> Will there be only one solution for "BFD over LAG"? Not sure=20 >>>>> as I see two fundamental setups: (a) run BFD on every=20 >>>>> component link and (b) run a single BFD session over the LAG=20 >>>>> interface. They solve different network setups as far as I can see. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>=20 >>>>>> Hi Jeff, >>>>>>=20 >>>>>> Let me understand this. If you have an IP interface over a=20 >>>>> LAG with 5 component links, then you internally establish 5=20 >>>>> BFD sessions with 30ms timeouts? >>>>>>=20 >>>>>> You don't need to do this. You could use LACP for lag and=20 >>>>> BFD for IP connectivity - which means BFD should remain up as=20 >>>>> long as there is reachability over the lag. IMO it has no=20 >>>>> business to bother with each individual component links.=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> We have been supporting this mode of BFD over LAG=20 >>>>> operations for last 5 years and our customers love it. >>>>>>=20 >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't=20 >>>>> hit min-links, do you really want to bring the LAG down? >>>>>>=20 >>>>>> Mach - be aware of patents :) >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)"=20 >>>>> wrote: >>>>>>=20 >>>>>>> Hi Mach, >>>>>>>=20 >>>>>>> I am not sure I understand why you would want BFD to=20 >>>>> ensure liveliness of each component link in a LAG. The draft=20 >>>>> seems to suggest establishing separate BFD session for each=20 >>>>> pair of component interfaces to detect the failures. Why=20 >>>>> should BFD be concerned about each component link? I would=20 >>>>> rather that BFD sprays packets over each component link in a=20 >>>>> round robin fashion and brings down the IP interface over a=20 >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org=20 >>>>> [mailto:rtg-bfd-bounces@ietf.org] On=20 >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We uploaded a new=20 >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00)=20 >>>>> that is about BFD running over interface(e.g., LAG/Bundle=20 >>>>> interface). You are very welcome to read the draft and give=20 >>>>> your comments. >>>>>>>=20 >>>>>>> Many thanks, >>>>>>> Mach >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Marc Binderberger >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From davari@broadcom.com Tue Aug 2 14:28:38 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AC111E8095 for ; Tue, 2 Aug 2011 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFpFP7jbMcao for ; Tue, 2 Aug 2011 14:28:37 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64D11E808F for ; Tue, 2 Aug 2011 14:28:37 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 02 Aug 2011 14:34:16 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 2 Aug 2011 14:28:39 -0700 From: "Shahram Davari" To: "Jeff Tantsura" , "Warren Kumari" Date: Tue, 2 Aug 2011 14:28:37 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxQjNcYAyzp3qJ/S+mPe1aMZKuslgAA5fegAAJN2EAALK1xQAACO68gAAFd5pA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBCE1@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBC13@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6CCB@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6CCB@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6226B2D23DK7089808-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 21:28:38 -0000 I made my objection to this draft based on technical grounds and sound engi= neering practices. I leave it to the rest of the group member to endorse or= object to this hack. Thx Shahram -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: Tuesday, August 02, 2011 2:10 PM To: Shahram Davari; Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft Hi Shahram, Please don't tell me you are making your products for the sake of making th= em or trying to make the world a better place. We did it because our customers asked us to, Cisco did it last year for exa= ctly same reasons. Others didn't because either their customers didn't real= ize how good it could work/ couldn't properly do it, mostly due to ASIC's l= imitations. Personally - I'm intimately familiar with at least 4 different vendors CLIs= - BFD is MUCH easier to configure on all of them. Another aspect of the story - historically BFD has been available on most p= latforms for at least 5 years while L2 OAM at sub 100ms just 2-3 years. /drama mode on "Dear vendor - we'd like to spend M $xxx on your products if you do per con= stituent BFD as we are familiar with it, like it and run it everywhere" - go away and don't come back - you bloody layer violator :) /drama mode off It would be great if we could interoperate with other vendors, our customer= s would greatly benefit! Regards, Jeff -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Tuesday, August 02, 2011 12:46 To: Jeff Tantsura; Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft Hi Jeff, Not only I have talked to a live customer but I have talked to live custome= r's customer as well. Also Shane and Warren are not paying my salary and my= intention is not to please them. Thx Shahram -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: Tuesday, August 02, 2011 12:32 PM To: Shahram Davari; Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft Hi Shahram, Have you ever talked to a "live" customer? You should be grateful for Shane's and Warren's comments providing their po= int of view. At the end your salary is paid by them... Regards, Jeff -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Monday, August 01, 2011 14:22 To: Warren Kumari Cc: rtg-bfd@ietf.org; Shane Amante Subject: RE: Solicit comments on BFD for Interface draft It doesn't matter if BFD is easier to configure since you need to configure= link OAM only once for some limited number of links in each router. Also the Argument that service providers are more familiar with BFD therefo= re lets use BFD for any required OAM is very dangerous. I am sure if this d= raft becomes and RFC then sooner or later drafts will pop up to use BFD for= Ethernet, SONET, OTN, PON, MLPPP, etc. I am sure IETF doesn't want to start a inter-operability nightmare. Shahram -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net] Sent: Monday, August 01, 2011 1:52 PM To: Shahram Davari Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > Let's do the math: > > BFD Tx direction: > > My Discr: Auto assignment by SW > Your Discr: default to 0 > Remote IP add: need to configure > Min Tx interval: need to configure > Min Rx interval: need to configure > > BFD Rx direction: > > Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) > Remote Tx interval: learn > Remote Rx interval: learn > > CFM Tx direction: > MD name: Auto assign for all MDL=3D0 (such as LinkMD) > MDL: need to configure MDL=3D0 > MEPID: Auto assign by SW > UP/Down: SW can automatically set to down for all MDL=3D0 > Tx Rate: need to configure > > CFM Rx direction: > MD name: Learn (unknown MDL redirected to CPU for learning) > MDL: Learn (unknown MDL redirected to CPU for learning) > MEPID: Learn (unknown MEPID redirected to CPU for learning) > UP/Down: SW sets to Down for all MDL=3D0 > Rx rate: need to configure > > > As you can see there isn't much difference in configuration of BFD and 80= 2.1ag for Link OAM. For BFD one needs to configure the Remote IP address an= d the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx r= ate. > > So your argument is moot. Which part? You mean the "tools already understand generation of configlets (and auditi= ng)" bit? Please point to the bit where my (or most) CM systems understands= OAM config for major vendors... You mean the "operators are already familiar with the protocol" bit? Hmmm, = also no... Maybe you don't buy that "a lot of operators already use BFD in their netwo= rks"? Really? But, it has become apparent that you are not actually listening, so I've lo= st interest.... W > > Regards > Shahram > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, August 01, 2011 8:39 AM > To: Thomas Nadeau > Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > > On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: > >> >> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >> >>> Hi Shane, >>> >>> Same for BFD. You need to know my discriminator, your discriminator, lo= cal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand= mode, Authentication, Active/Passive, Detection Interval, etc. >> >> While those parameters are required, that doesn't mean that clever = implementations can choose reasonable defaults for you. I know such impleme= ntations from at least 3 major vendors. *) > > +1 > > Yes -- and a lot of operators already use BFD in their networks, they are= already familiar with the protocol, their tools already understand generat= ion of configlets (and auditing), etc. It already "just works" -- having it= run on component link seems like a no brainer.... > >> >>> Believe me BFD requires more configuration than 802.1ag. So your argume= nt of requiring a lot of info to configure 802.1ag applies even more to BFD= . >> >> On paper perhaps, but in reality that is not the case. I do not kn= ow of any implementations where MIP/MEP configuration is done automatically= such as is the case for links and routing protocols in the major implement= ations using BFD. >> >> --Tom >> >> >>> >>> Regards >>> Shahram >>> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf Of Shane Amante >>> Sent: Saturday, July 30, 2011 9:36 AM >>> To: Bhatia, Manav (Manav) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>> >>> Manav, Sharam, Others, >>> >>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>> >>>> I completely agree that LACP is not fast enough and that operators als= o want to detect individual component link breakdowns instead of the entire= LAG. If that's the case then folks should use IEEE 802.1ag for individual = component links and BFD for the entire LAG. Are we trying to position BFD a= s an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over= component links since not all links may be ethernet? >>> >>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.173= 1 (or 802.3ah) for *fast* detection of component-link failures in a LAG is:= operational simplicity, clear and simple. >>> >>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially e= rror-prone, configuration required. Take a moment and think about how many= variables are *required* to properly set-up 802.1ag/Y.1731: >>> a) What MD "name" should you use? >>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>> c) What MD "level" should you use, (probably 0 or 1)? >>> d) What MEP ID's do I assign to each side of the link? >>> e) Don't forget to configure the right direction, up or down, for the = MEP? >>> ... that is *ridiculous*! >>> >>> Let's not forget that there are [potentially] 100's if not 1,000's of L= AG's in each carrier's network, so this needs to get repeated over and over= and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-u= p *and* maintain. >>> >>> BFD is simple. At a bare minimum you just need to configure an "{Tx|Rx= } interval". (The "multiplier" should default to 3, unless you want to con= figure it differently). That's it! Done! >>> >>> So, in short, let me throw my hat in the ring with other operators that= I really, really, really want a standards-based way of running BFD over co= mponent-links in a LAG in order to quickly detect a component-link failure = and take it out of the bundle. >>> >>> Thanks, >>> >>> -shane >>> >>> >>> >>>> I think (and this is also what Shahram was alluding to) that BFD is me= ant to detect IP liveliness. This means that if I run BFD over an IP interf= ace it should bring it down only when the IP connectivity goes down. Should= n't BFD be oblivious to the number of links alive in a LAG as long as the L= AG remains up and it can reach the other end. It is a simple implementation= effort to note the status of each component link of a lag and to bring it = down if the number goes below a certain threshold - You don't need to run B= FD over each link! >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>> >>>>> Hello Manav, >>>>> >>>>> others have already replied but the part "[...] has no >>>>> business" triggers now my reply. I deliberately >>>>> "mis"-understand it. Point is that this is about business. >>>>> Customers have pushed their vendors to implement BFD over LAG >>>>> component links. Reasons I know >>>>> >>>>> - LACP is not fast enough >>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>> Designers and Operations, so they would like to use it everywhere >>>>> - BFDs reputation for being fast and working >>>>> >>>>> >>>>> So now we have 3-4 different implementation for >>>>> per-cmponent-link BFD that I know about. Potentially there >>>>> exists more. Probably not that much different but enough to >>>>> make interoperability impossible. It's again customers who >>>>> push now for standardization. Thus the draft to find an agreement :-) >>>>> >>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>> as I see two fundamental setups: (a) run BFD on every >>>>> component link and (b) run a single BFD session over the LAG >>>>> interface. They solve different network setups as far as I can see. >>>>> >>>>> >>>>> Regards, Marc >>>>> >>>>> >>>>> >>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>> >>>>>> Hi Jeff, >>>>>> >>>>>> Let me understand this. If you have an IP interface over a >>>>> LAG with 5 component links, then you internally establish 5 >>>>> BFD sessions with 30ms timeouts? >>>>>> >>>>>> You don't need to do this. You could use LACP for lag and >>>>> BFD for IP connectivity - which means BFD should remain up as >>>>> long as there is reachability over the lag. IMO it has no >>>>> business to bother with each individual component links. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>> >>>>>> Hi, >>>>>> >>>>>> We have been supporting this mode of BFD over LAG >>>>> operations for last 5 years and our customers love it. >>>>>> >>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>> hit min-links, do you really want to bring the LAG down? >>>>>> >>>>>> Mach - be aware of patents :) >>>>>> >>>>>> Regards, >>>>>> Jeff >>>>>> >>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>> wrote: >>>>>> >>>>>>> Hi Mach, >>>>>>> >>>>>>> I am not sure I understand why you would want BFD to >>>>> ensure liveliness of each component link in a LAG. The draft >>>>> seems to suggest establishing separate BFD session for each >>>>> pair of component interfaces to detect the failures. Why >>>>> should BFD be concerned about each component link? I would >>>>> rather that BFD sprays packets over each component link in a >>>>> round robin fashion and brings down the IP interface over a >>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org >>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>> Behalf Of Mach Chen >>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We uploaded a new >>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>> interface). You are very welcome to read the draft and give >>>>> your comments. >>>>>>> >>>>>>> Many thanks, >>>>>>> Mach >>>>>> >>>>> >>>>> -- >>>>> Marc Binderberger >>>>> >>>>> >>> >>> >>> >>> >> > > > From marc@sniff.de Tue Aug 2 15:53:19 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F193711E80E4 for ; Tue, 2 Aug 2011 15:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKQ8dKf78-Ur for ; Tue, 2 Aug 2011 15:53:17 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6811E8095 for ; Tue, 2 Aug 2011 15:53:16 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 744782AA0F; Tue, 2 Aug 2011 22:53:23 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBCE1@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 3 Aug 2011 00:53:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FB1AAF1-CDDF-4CAD-8A40-BEA8C0474F0F@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326 CBC13@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6CCB@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBCE1@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari X-Mailer: Apple Mail (2.1084) Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 22:53:19 -0000 Shahram, making comments like "hack" (but without the quotes) is not professional = and simply inappropriate in my book. You repeatedly made incorrect = statements about what we try to achieve and then argue against it (e.g. = [1][2]). Interesting technique for a technical discussion ... . Regarding the layer violation, as this is a central point of your = criticism: layers are not a value on their own. It's a tool to = modularize a problem. It's a good tool but nothing is absolute. The = draft is mentioning what problem can happen because we know some = implementation have done it, so for the sake of interoperability it = should be mentioned. I think we used the correct phrases like MAY etc. = to ensure such behaviour is not a mandatory part of the proposal. Anyway, we will pick up some of the detailed questions you asked in = former emails in an updated draft and I appreciate this constructive = input. I say "some" as for some others the answer will be that it's an = "implementation detail", like how to send out on a specific component = link or how to handle this on a central CPU. Regards, Marc [1]: "Also the Argument that service providers are more familiar with = BFD therefore lets use BFD for any required OAM is very dangerous. I am = sure if this draft becomes and RFC then sooner or later drafts will pop = up to use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc." [2]: "Your argument is not valid that we need a single protocol to do = Link as well as IP layer OAM, since if you continue this path sooner or = later one could ask why not run BFD for Ethernet and why not run BFD for = OTN and why not run BFD for GPON." On 2011-08-02, at 11:28 PM, Shahram Davari wrote: > I made my objection to this draft based on technical grounds and sound = engineering practices. I leave it to the rest of the group member to = endorse or object to this hack. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, August 02, 2011 2:10 PM > To: Shahram Davari; Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft >=20 > Hi Shahram, >=20 > Please don't tell me you are making your products for the sake of = making them or trying to make the world a better place. >=20 > We did it because our customers asked us to, Cisco did it last year = for exactly same reasons. Others didn't because either their customers = didn't realize how good it could work/ couldn't properly do it, mostly = due to ASIC's limitations. >=20 > Personally - I'm intimately familiar with at least 4 different vendors = CLIs - BFD is MUCH easier to configure on all of them. >=20 > Another aspect of the story - historically BFD has been available on = most platforms for at least 5 years while L2 OAM at sub 100ms just 2-3 = years. >=20 > /drama mode on > "Dear vendor - we'd like to spend M $xxx on your products if you do = per constituent BFD as we are familiar with it, like it and run it = everywhere" - > go away and don't come back - you bloody layer violator :) > /drama mode off >=20 > It would be great if we could interoperate with other vendors, our = customers would greatly benefit! >=20 > Regards, > Jeff >=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Tuesday, August 02, 2011 12:46 > To: Jeff Tantsura; Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft >=20 > Hi Jeff, >=20 > Not only I have talked to a live customer but I have talked to live = customer's customer as well. Also Shane and Warren are not paying my = salary and my intention is not to please them. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, August 02, 2011 12:32 PM > To: Shahram Davari; Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft >=20 > Hi Shahram, >=20 > Have you ever talked to a "live" customer? > You should be grateful for Shane's and Warren's comments providing = their point of view. > At the end your salary is paid by them... >=20 > Regards, > Jeff > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shahram Davari > Sent: Monday, August 01, 2011 14:22 > To: Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft >=20 > It doesn't matter if BFD is easier to configure since you need to = configure link OAM only once for some limited number of links in each = router. >=20 > Also the Argument that service providers are more familiar with BFD = therefore lets use BFD for any required OAM is very dangerous. I am sure = if this draft becomes and RFC then sooner or later drafts will pop up to = use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc. >=20 > I am sure IETF doesn't want to start a inter-operability nightmare. >=20 > Shahram >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, August 01, 2011 1:52 PM > To: Shahram Davari > Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft >=20 >=20 > On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: >=20 >> Let's do the math: >>=20 >> BFD Tx direction: >>=20 >> My Discr: Auto assignment by SW >> Your Discr: default to 0 >> Remote IP add: need to configure >> Min Tx interval: need to configure >> Min Rx interval: need to configure >>=20 >> BFD Rx direction: >>=20 >> Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) >> Remote Tx interval: learn >> Remote Rx interval: learn >>=20 >> CFM Tx direction: >> MD name: Auto assign for all MDL=3D0 (such as LinkMD) >> MDL: need to configure MDL=3D0 >> MEPID: Auto assign by SW >> UP/Down: SW can automatically set to down for all MDL=3D0 >> Tx Rate: need to configure >>=20 >> CFM Rx direction: >> MD name: Learn (unknown MDL redirected to CPU for learning) >> MDL: Learn (unknown MDL redirected to CPU for learning) >> MEPID: Learn (unknown MEPID redirected to CPU for learning) >> UP/Down: SW sets to Down for all MDL=3D0 >> Rx rate: need to configure >>=20 >>=20 >> As you can see there isn't much difference in configuration of BFD = and 802.1ag for Link OAM. For BFD one needs to configure the Remote IP = address and the Tx/Rx rate and for OAM one needs to configure the MDL = and the Tx/Rx rate. >>=20 >> So your argument is moot. >=20 > Which part? >=20 > You mean the "tools already understand generation of configlets (and = auditing)" bit? Please point to the bit where my (or most) CM systems = understands OAM config for major vendors... >=20 > You mean the "operators are already familiar with the protocol" bit? = Hmmm, also no... >=20 > Maybe you don't buy that "a lot of operators already use BFD in their = networks"? Really? >=20 > But, it has become apparent that you are not actually listening, so = I've lost interest.... >=20 > W >=20 >>=20 >> Regards >> Shahram >>=20 >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net] >> Sent: Monday, August 01, 2011 8:39 AM >> To: Thomas Nadeau >> Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >>=20 >>=20 >> On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >>=20 >>>=20 >>> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>>=20 >>>> Hi Shane, >>>>=20 >>>> Same for BFD. You need to know my discriminator, your = discriminator, local IP address, remote IP address, Min Tx Interval, Min = Rx Interval, Demand mode, Authentication, Active/Passive, Detection = Interval, etc. >>>=20 >>> While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) >>=20 >> +1 >>=20 >> Yes -- and a lot of operators already use BFD in their networks, they = are already familiar with the protocol, their tools already understand = generation of configlets (and auditing), etc. It already "just works" -- = having it run on component link seems like a no brainer.... >>=20 >>>=20 >>>> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD. >>>=20 >>> On paper perhaps, but in reality that is not the case. I do not = know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Regards >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >>>> Sent: Saturday, July 30, 2011 9:36 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>> Manav, Sharam, Others, >>>>=20 >>>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>>=20 >>>>> I completely agree that LACP is not fast enough and that operators = also want to detect individual component link breakdowns instead of the = entire LAG. If that's the case then folks should use IEEE 802.1ag for = individual component links and BFD for the entire LAG. Are we trying to = position BFD as an IETF equivalent of 802.1ag? Or is it that we're = trying to run BFD over component links since not all links may be = ethernet? >>>>=20 >>>> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>>>=20 >>>> The problem with 802.1ag/Y.1731 is the massive amount of, = potentially error-prone, configuration required. Take a moment and = think about how many variables are *required* to properly set-up = 802.1ag/Y.1731: >>>> a) What MD "name" should you use? >>>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>>> c) What MD "level" should you use, (probably 0 or 1)? >>>> d) What MEP ID's do I assign to each side of the link? >>>> e) Don't forget to configure the right direction, up or down, for = the MEP? >>>> ... that is *ridiculous*! >>>>=20 >>>> Let's not forget that there are [potentially] 100's if not 1,000's = of LAG's in each carrier's network, so this needs to get repeated over = and over and over again. Bottom-line: 802.1ag/Y.1731 is extremely = complex to set-up *and* maintain. >>>>=20 >>>> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>>>=20 >>>> So, in short, let me throw my hat in the ring with other operators = that I really, really, really want a standards-based way of running BFD = over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >=20 >=20 >=20 >=20 >=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> -shane >>>>=20 >>>>=20 >>>>=20 >>>>> I think (and this is also what Shahram was alluding to) that BFD = is meant to detect IP liveliness. This means that if I run BFD over an = IP interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Hello Manav, >>>>>>=20 >>>>>> others have already replied but the part "[...] has no >>>>>> business" triggers now my reply. I deliberately >>>>>> "mis"-understand it. Point is that this is about business. >>>>>> Customers have pushed their vendors to implement BFD over LAG >>>>>> component links. Reasons I know >>>>>>=20 >>>>>> - LACP is not fast enough >>>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>>> Designers and Operations, so they would like to use it everywhere >>>>>> - BFDs reputation for being fast and working >>>>>>=20 >>>>>>=20 >>>>>> So now we have 3-4 different implementation for >>>>>> per-cmponent-link BFD that I know about. Potentially there >>>>>> exists more. Probably not that much different but enough to >>>>>> make interoperability impossible. It's again customers who >>>>>> push now for standardization. Thus the draft to find an agreement = :-) >>>>>>=20 >>>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>>> as I see two fundamental setups: (a) run BFD on every >>>>>> component link and (b) run a single BFD session over the LAG >>>>>> interface. They solve different network setups as far as I can = see. >>>>>>=20 >>>>>>=20 >>>>>> Regards, Marc >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>>=20 >>>>>>> Hi Jeff, >>>>>>>=20 >>>>>>> Let me understand this. If you have an IP interface over a >>>>>> LAG with 5 component links, then you internally establish 5 >>>>>> BFD sessions with 30ms timeouts? >>>>>>>=20 >>>>>>> You don't need to do this. You could use LACP for lag and >>>>>> BFD for IP connectivity - which means BFD should remain up as >>>>>> long as there is reachability over the lag. IMO it has no >>>>>> business to bother with each individual component links. >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>>> To: Bhatia, Manav (Manav) >>>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We have been supporting this mode of BFD over LAG >>>>>> operations for last 5 years and our customers love it. >>>>>>>=20 >>>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>>> hit min-links, do you really want to bring the LAG down? >>>>>>>=20 >>>>>>> Mach - be aware of patents :) >>>>>>>=20 >>>>>>> Regards, >>>>>>> Jeff >>>>>>>=20 >>>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Mach, >>>>>>>>=20 >>>>>>>> I am not sure I understand why you would want BFD to >>>>>> ensure liveliness of each component link in a LAG. The draft >>>>>> seems to suggest establishing separate BFD session for each >>>>>> pair of component interfaces to detect the failures. Why >>>>>> should BFD be concerned about each component link? I would >>>>>> rather that BFD sprays packets over each component link in a >>>>>> round robin fashion and brings down the IP interface over a >>>>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>>>=20 >>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>>> Behalf Of Mach Chen >>>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>>> To: rtg-bfd@ietf.org >>>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> We uploaded a new >>>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>>> interface). You are very welcome to read the draft and give >>>>>> your comments. >>>>>>>>=20 >>>>>>>> Many thanks, >>>>>>>> Mach >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Marc Binderberger >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Marc Binderberger From gregimirsky@gmail.com Tue Aug 2 16:20:40 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D19A11E80F1 for ; Tue, 2 Aug 2011 16:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0zTUtLqbhYZ for ; Tue, 2 Aug 2011 16:20:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BED2411E8095 for ; Tue, 2 Aug 2011 16:20:38 -0700 (PDT) Received: by vxi40 with SMTP id 40so279412vxi.31 for ; Tue, 02 Aug 2011 16:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=s0jmJ+mjWZgEPp64exc3quoEr7w6sKohF+vXtFwHiFY=; b=E/p9cAsdRRciwRaFV0ETr1MdtnNsQ5SYOm10TRWY19tClPxfacZO9zQG4Avks7HDAq +RWYaq4M9+YdWxCqdC3jhdBi8gMjJ3J5cK4v6hkvsgU+aBthdUnwCm3e2TL9mFYOXMUm FUPkblxBU5LHi3s1GBZ85uT5CzSL/EQcRjhBs= MIME-Version: 1.0 Received: by 10.52.115.165 with SMTP id jp5mr6383764vdb.158.1312327245597; Tue, 02 Aug 2011 16:20:45 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Tue, 2 Aug 2011 16:20:45 -0700 (PDT) In-Reply-To: <1FB1AAF1-CDDF-4CAD-8A40-BEA8C0474F0F@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6CCB@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBCE1@SJEXCHCCR02.corp.ad.broadcom.com> <1FB1AAF1-CDDF-4CAD-8A40-BEA8C0474F0F@sniff.de> Date: Tue, 2 Aug 2011 16:20:45 -0700 Message-ID: Subject: Re: Solicit comments on BFD for Interface draft From: Greg Mirsky To: Marc Binderberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 23:20:40 -0000 Dear Marc, it is strange to see argument that properly layered architecture doesn't add value to a solution when discussing networking. I think that detailed scope and extended applicability of proposed mechanism will address some of arguments that been expressed in this discussion. Regards, Greg On Tue, Aug 2, 2011 at 3:53 PM, Marc Binderberger wrote: > Shahram, > > making comments like "hack" (but without the quotes) is not professional = and simply inappropriate in my book. You repeatedly made incorrect statemen= ts about what we try to achieve and then argue against it (e.g. [1][2]). In= teresting technique for a technical discussion ... . > > > Regarding the layer violation, as this is a central point of your critici= sm: layers are not a value on their own. It's a tool to modularize a proble= m. It's a good tool but nothing is absolute. The draft is mentioning what p= roblem can happen because we know some implementation have done it, so for = the sake of interoperability it should be mentioned. I think we used the co= rrect phrases like MAY etc. to ensure such behaviour is not a mandatory par= t of the proposal. > > > Anyway, we will pick up some of the detailed questions you asked in forme= r emails in an updated draft and I appreciate this constructive input. I sa= y "some" as for some others the answer will be that it's an "implementation= detail", like how to send out on a specific component link or how to handl= e this on a central CPU. > > > Regards, Marc > > [1]: "Also the Argument that service providers are more familiar with BFD= therefore lets use BFD for any required OAM is very dangerous. I am sure i= f this draft becomes and RFC then sooner or later drafts will pop up to use= BFD for Ethernet, SONET, OTN, PON, MLPPP, etc." > > [2]: "Your argument is not valid that we need a single protocol to do Lin= k as well as IP layer OAM, since if you continue this path sooner or later = one could ask why not run BFD for Ethernet and why not run BFD for OTN and = why not run BFD for GPON." > > > > On 2011-08-02, at 11:28 PM, Shahram Davari wrote: > >> I made my objection to this draft based on technical grounds and sound e= ngineering practices. I leave it to the rest of the group member to endorse= or object to this hack. >> >> Thx >> Shahram >> >> -----Original Message----- >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >> Sent: Tuesday, August 02, 2011 2:10 PM >> To: Shahram Davari; Warren Kumari >> Cc: rtg-bfd@ietf.org; Shane Amante >> Subject: RE: Solicit comments on BFD for Interface draft >> >> Hi Shahram, >> >> Please don't tell me you are making your products for the sake of making= them or trying to make the world a better place. >> >> We did it because our customers asked us to, Cisco did it last year for = exactly same reasons. Others didn't because either their customers didn't r= ealize how good it could work/ couldn't properly do it, mostly due to ASIC'= s limitations. >> >> Personally - I'm intimately familiar with at least 4 different vendors C= LIs - BFD is MUCH easier to configure on all of them. >> >> Another aspect of the story - historically BFD has been available on mos= t platforms for at least 5 years while L2 OAM at sub 100ms just 2-3 years. >> >> /drama mode on >> "Dear vendor - we'd like to spend M $xxx on your products if you do per = constituent BFD as we are familiar with it, like it and run it everywhere" = - >> go away and don't come back - you bloody layer violator :) >> /drama mode off >> >> It would be great if we could interoperate with other vendors, our custo= mers would greatly benefit! >> >> Regards, >> Jeff >> >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Tuesday, August 02, 2011 12:46 >> To: Jeff Tantsura; Warren Kumari >> Cc: rtg-bfd@ietf.org; Shane Amante >> Subject: RE: Solicit comments on BFD for Interface draft >> >> Hi Jeff, >> >> Not only I have talked to a live customer but I have talked to live cust= omer's customer as well. Also Shane and Warren are not paying my salary and= my intention is not to please them. >> >> Thx >> Shahram >> >> -----Original Message----- >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >> Sent: Tuesday, August 02, 2011 12:32 PM >> To: Shahram Davari; Warren Kumari >> Cc: rtg-bfd@ietf.org; Shane Amante >> Subject: RE: Solicit comments on BFD for Interface draft >> >> Hi Shahram, >> >> Have you ever talked to a "live" customer? >> You should be grateful for Shane's and Warren's comments providing their= point of view. >> At the end your salary is paid by them... >> >> Regards, >> Jeff >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beha= lf Of Shahram Davari >> Sent: Monday, August 01, 2011 14:22 >> To: Warren Kumari >> Cc: rtg-bfd@ietf.org; Shane Amante >> Subject: RE: Solicit comments on BFD for Interface draft >> >> It doesn't matter if BFD is easier to configure since you need to config= ure link OAM only once for some limited number of links in each router. >> >> Also the Argument that service providers are more familiar with BFD ther= efore lets use BFD for any required OAM is very dangerous. I am sure if thi= s draft becomes and RFC then sooner or later drafts will pop up to use BFD = for Ethernet, SONET, OTN, PON, MLPPP, etc. >> >> I am sure IETF doesn't want to start a inter-operability nightmare. >> >> Shahram >> >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net] >> Sent: Monday, August 01, 2011 1:52 PM >> To: Shahram Davari >> Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >> >> >> On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: >> >>> Let's do the math: >>> >>> BFD Tx direction: >>> >>> My Discr: Auto assignment by SW >>> Your Discr: default to 0 >>> Remote IP add: need to configure >>> Min Tx interval: need to configure >>> Min Rx interval: need to configure >>> >>> BFD Rx direction: >>> >>> Remote =A0Discr: Learn (remote Disc=3D0 redirected to CPU for learning) >>> Remote Tx interval: learn >>> Remote Rx interval: learn >>> >>> CFM Tx direction: >>> MD name: Auto assign for all MDL=3D0 (such as LinkMD) >>> MDL: need to configure MDL=3D0 >>> MEPID: Auto assign by SW >>> UP/Down: SW can automatically set to down for all MDL=3D0 >>> Tx Rate: need to configure >>> >>> CFM Rx direction: >>> MD name: Learn (unknown MDL redirected to CPU for learning) >>> MDL: Learn (unknown MDL redirected to CPU for learning) >>> MEPID: Learn (unknown MEPID redirected to CPU for learning) >>> UP/Down: SW sets to Down for all MDL=3D0 >>> Rx rate: need to configure >>> >>> >>> As you can see there isn't much difference in configuration of BFD and = 802.1ag for Link OAM. For BFD one needs to configure the Remote IP address = and the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx= rate. >>> >>> So your argument is moot. >> >> Which part? >> >> You mean the "tools already understand generation of configlets (and aud= iting)" bit? Please point to the bit where my (or most) CM systems understa= nds OAM config for major vendors... >> >> You mean the "operators are already familiar with the protocol" bit? Hmm= m, also no... >> >> Maybe you don't buy that "a lot of operators already use BFD in their ne= tworks"? Really? >> >> But, it has become apparent that you are not actually listening, so I've= lost interest.... >> >> W >> >>> >>> Regards >>> Shahram >>> >>> -----Original Message----- >>> From: Warren Kumari [mailto:warren@kumari.net] >>> Sent: Monday, August 01, 2011 8:39 AM >>> To: Thomas Nadeau >>> Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>> >>> >>> On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >>> >>>> >>>> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>>> >>>>> Hi Shane, >>>>> >>>>> Same for BFD. You need to know my discriminator, your discriminator, = local IP address, remote IP address, Min Tx Interval, Min Rx Interval, Dema= nd mode, Authentication, Active/Passive, Detection Interval, etc. >>>> >>>> =A0 =A0 While those parameters are required, that doesn't mean that cl= ever implementations can choose reasonable defaults for you. I know such im= plementations from at least 3 major vendors. *) >>> >>> +1 >>> >>> Yes -- and a lot of operators already use BFD in their networks, they a= re already familiar with the protocol, their tools already understand gener= ation of configlets (and auditing), etc. It already "just works" -- having = it run on component link seems like a no brainer.... >>> >>>> >>>>> Believe me BFD requires more configuration than 802.1ag. So your argu= ment of requiring a lot of info to configure 802.1ag applies even more to B= FD. >>>> >>>> =A0 =A0 On paper perhaps, but in reality that is not the case. =A0I do= not know of any implementations where MIP/MEP configuration is done automa= tically such as is the case for links and routing protocols in the major im= plementations using BFD. >>>> >>>> =A0 =A0 --Tom >>>> >>>> >>>>> >>>>> Regards >>>>> Shahram >>>>> >>>>> -----Original Message----- >>>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On B= ehalf Of Shane Amante >>>>> Sent: Saturday, July 30, 2011 9:36 AM >>>>> To: Bhatia, Manav (Manav) >>>>> Cc: rtg-bfd@ietf.org >>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>> >>>>> Manav, Sharam, Others, >>>>> >>>>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>>> >>>>>> I completely agree that LACP is not fast enough and that operators a= lso want to detect individual component link breakdowns instead of the enti= re LAG. If that's the case then folks should use IEEE 802.1ag for individua= l component links and BFD for the entire LAG. Are we trying to position BFD= as an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD ov= er component links since not all links may be ethernet? >>>>> >>>>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1= 731 (or 802.3ah) for *fast* detection of component-link failures in a LAG i= s: operational simplicity, clear and simple. >>>>> >>>>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially= error-prone, configuration required. =A0Take a moment and think about how = many variables are *required* to properly set-up 802.1ag/Y.1731: >>>>> a) =A0What MD "name" should you use? >>>>> b) =A0What MD "name format" should you use, (ASCII, DNS, etc.)? >>>>> c) =A0What MD "level" should you use, (probably 0 or 1)? >>>>> d) =A0What MEP ID's do I assign to each side of the link? >>>>> e) =A0Don't forget to configure the right direction, up or down, for = the MEP? >>>>> ... that is *ridiculous*! >>>>> >>>>> Let's not forget that there are [potentially] 100's if not 1,000's of= LAG's in each carrier's network, so this needs to get repeated over and ov= er and over again. =A0Bottom-line: 802.1ag/Y.1731 is extremely complex to s= et-up *and* maintain. >>>>> >>>>> BFD is simple. =A0At a bare minimum you just need to configure an "{T= x|Rx} interval". =A0(The "multiplier" should default to 3, unless you want = to configure it differently). That's it! =A0Done! >>>>> >>>>> So, in short, let me throw my hat in the ring with other operators th= at I really, really, really want a standards-based way of running BFD over = component-links in a LAG in order to quickly detect a component-link failur= e and take it out of the bundle. >> >> >> >> >> >>>>> >>>>> Thanks, >>>>> >>>>> -shane >>>>> >>>>> >>>>> >>>>>> I think (and this is also what Shahram was alluding to) that BFD is = meant to detect IP liveliness. This means that if I run BFD over an IP inte= rface it should bring it down only when the IP connectivity goes down. Shou= ldn't BFD be oblivious to the number of links alive in a LAG as long as the= LAG remains up and it can reach the other end. It is a simple implementati= on effort to note the status of each component link of a lag and to bring i= t down if the number goes below a certain threshold - You don't need to run= BFD over each link! >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>>>> To: Bhatia, Manav (Manav) >>>>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>> >>>>>>> Hello Manav, >>>>>>> >>>>>>> others have already replied but the part "[...] has no >>>>>>> business" triggers now my reply. I deliberately >>>>>>> "mis"-understand it. Point is that this is about business. >>>>>>> Customers have pushed their vendors to implement BFD over LAG >>>>>>> component links. Reasons I know >>>>>>> >>>>>>> - LACP is not fast enough >>>>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>>>> Designers and Operations, so they would like to use it everywhere >>>>>>> - BFDs reputation for being fast and working >>>>>>> >>>>>>> >>>>>>> So now we have 3-4 different implementation for >>>>>>> per-cmponent-link BFD that I know about. Potentially there >>>>>>> exists more. Probably not that much different but enough to >>>>>>> make interoperability impossible. It's again customers who >>>>>>> push now for standardization. Thus the draft to find an agreement := -) >>>>>>> >>>>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>>>> as I see two fundamental setups: (a) run BFD on every >>>>>>> component link =A0and (b) run a single BFD session over the LAG >>>>>>> interface. They solve different network setups as far as I can see. >>>>>>> >>>>>>> >>>>>>> Regards, Marc >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>>> >>>>>>>> Hi Jeff, >>>>>>>> >>>>>>>> Let me understand this. If you have an IP interface over a >>>>>>> LAG with 5 component links, then you internally establish 5 >>>>>>> BFD sessions with 30ms timeouts? >>>>>>>> >>>>>>>> You don't need to do this. You could use LACP for lag and >>>>>>> BFD for IP connectivity - which means BFD should remain up as >>>>>>> long as there is reachability over the lag. IMO it has no >>>>>>> business to bother with each individual component links. >>>>>>>> >>>>>>>> Cheers, Manav >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>>>> To: Bhatia, Manav (Manav) >>>>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We have been supporting this mode of BFD over LAG >>>>>>> operations for last 5 years and our customers love it. >>>>>>>> >>>>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>>>> hit min-links, do you really want to bring the LAG down? >>>>>>>> >>>>>>>> Mach - be aware of patents :) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Jeff >>>>>>>> >>>>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Mach, >>>>>>>>> >>>>>>>>> I am not sure I understand why you would want BFD to >>>>>>> ensure liveliness of each component link in a LAG. The draft >>>>>>> seems to suggest establishing separate BFD session for each >>>>>>> pair of component interfaces to detect the failures. Why >>>>>>> should BFD be concerned about each component link? I would >>>>>>> rather that BFD sprays packets over each component link in a >>>>>>> round robin fashion and brings down the IP interface over a >>>>>>> lag only if it misses 3 consecutive packets. Am I missing something= ? >>>>>>>>> >>>>>>>>> Cheers, Manav >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>>>> Behalf Of Mach Chen >>>>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>>>> To: rtg-bfd@ietf.org >>>>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We uploaded a new >>>>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>>>> interface). You are very welcome to read the draft and give >>>>>>> your comments. >>>>>>>>> >>>>>>>>> Many thanks, >>>>>>>>> Mach >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Marc Binderberger =A0 =A0 =A0 =A0 =A0 >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> >> >> >> >> > > -- > Marc Binderberger =A0 =A0 =A0 =A0 =A0 > > From marc@sniff.de Tue Aug 2 16:43:01 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404911E80DD for ; Tue, 2 Aug 2011 16:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EZ6Fwby8OsK for ; Tue, 2 Aug 2011 16:42:59 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ECE11E8095 for ; Tue, 2 Aug 2011 16:42:58 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9CD932AA0F; Tue, 2 Aug 2011 23:43:06 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 3 Aug 2011 01:43:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A3412B9-DED5-4A6C-80C1-9D6928A6DC51@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2 C6CCB@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBCE1@SJEXCHCCR02.corp.ad.broadcom.com> <1FB1AAF1-CDDF-4CAD-8A40-BEA8C0474F0F@sniff.de> To: Greg Mirsky X-Mailer: Apple Mail (2.1084) Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 23:43:01 -0000 Hi Greg, my answer is: an implication is not an equivalence :-) Translated from boolean algebra into real words: properly layered architecture -> added value: I would agree, in general = terms for added value -> needs properly layered architecture: I disagree The problem I have is with the attitude that "layer violation" is a = reason to condemn a proposal right away. Not to mention that the "layer = violation" wording is exaggerated.=20 > I think that detailed scope and extended applicability of proposed > mechanism will address some of arguments that been expressed in this > discussion. fair enough, looking forward! Regards, Marc On 2011-08-03, at 1:20 AM, Greg Mirsky wrote: > Dear Marc, > it is strange to see argument that properly layered architecture > doesn't add value to a solution when discussing networking. > I think that detailed scope and extended applicability of proposed > mechanism will address some of arguments that been expressed in this > discussion. >=20 > Regards, > Greg >=20 > On Tue, Aug 2, 2011 at 3:53 PM, Marc Binderberger = wrote: >> Shahram, >>=20 >> making comments like "hack" (but without the quotes) is not = professional and simply inappropriate in my book. You repeatedly made = incorrect statements about what we try to achieve and then argue against = it (e.g. [1][2]). Interesting technique for a technical discussion ... . >>=20 >>=20 >> Regarding the layer violation, as this is a central point of your = criticism: layers are not a value on their own. It's a tool to = modularize a problem. It's a good tool but nothing is absolute. The = draft is mentioning what problem can happen because we know some = implementation have done it, so for the sake of interoperability it = should be mentioned. I think we used the correct phrases like MAY etc. = to ensure such behaviour is not a mandatory part of the proposal. >>=20 >>=20 >> Anyway, we will pick up some of the detailed questions you asked in = former emails in an updated draft and I appreciate this constructive = input. I say "some" as for some others the answer will be that it's an = "implementation detail", like how to send out on a specific component = link or how to handle this on a central CPU. >>=20 >>=20 >> Regards, Marc >>=20 >> [1]: "Also the Argument that service providers are more familiar with = BFD therefore lets use BFD for any required OAM is very dangerous. I am = sure if this draft becomes and RFC then sooner or later drafts will pop = up to use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc." >>=20 >> [2]: "Your argument is not valid that we need a single protocol to do = Link as well as IP layer OAM, since if you continue this path sooner or = later one could ask why not run BFD for Ethernet and why not run BFD for = OTN and why not run BFD for GPON." >>=20 >>=20 >>=20 >> On 2011-08-02, at 11:28 PM, Shahram Davari wrote: >>=20 >>> I made my objection to this draft based on technical grounds and = sound engineering practices. I leave it to the rest of the group member = to endorse or object to this hack. >>>=20 >>> Thx >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>> Sent: Tuesday, August 02, 2011 2:10 PM >>> To: Shahram Davari; Warren Kumari >>> Cc: rtg-bfd@ietf.org; Shane Amante >>> Subject: RE: Solicit comments on BFD for Interface draft >>>=20 >>> Hi Shahram, >>>=20 >>> Please don't tell me you are making your products for the sake of = making them or trying to make the world a better place. >>>=20 >>> We did it because our customers asked us to, Cisco did it last year = for exactly same reasons. Others didn't because either their customers = didn't realize how good it could work/ couldn't properly do it, mostly = due to ASIC's limitations. >>>=20 >>> Personally - I'm intimately familiar with at least 4 different = vendors CLIs - BFD is MUCH easier to configure on all of them. >>>=20 >>> Another aspect of the story - historically BFD has been available on = most platforms for at least 5 years while L2 OAM at sub 100ms just 2-3 = years. >>>=20 >>> /drama mode on >>> "Dear vendor - we'd like to spend M $xxx on your products if you do = per constituent BFD as we are familiar with it, like it and run it = everywhere" - >>> go away and don't come back - you bloody layer violator :) >>> /drama mode off >>>=20 >>> It would be great if we could interoperate with other vendors, our = customers would greatly benefit! >>>=20 >>> Regards, >>> Jeff >>>=20 >>> -----Original Message----- >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Tuesday, August 02, 2011 12:46 >>> To: Jeff Tantsura; Warren Kumari >>> Cc: rtg-bfd@ietf.org; Shane Amante >>> Subject: RE: Solicit comments on BFD for Interface draft >>>=20 >>> Hi Jeff, >>>=20 >>> Not only I have talked to a live customer but I have talked to live = customer's customer as well. Also Shane and Warren are not paying my = salary and my intention is not to please them. >>>=20 >>> Thx >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>> Sent: Tuesday, August 02, 2011 12:32 PM >>> To: Shahram Davari; Warren Kumari >>> Cc: rtg-bfd@ietf.org; Shane Amante >>> Subject: RE: Solicit comments on BFD for Interface draft >>>=20 >>> Hi Shahram, >>>=20 >>> Have you ever talked to a "live" customer? >>> You should be grateful for Shane's and Warren's comments providing = their point of view. >>> At the end your salary is paid by them... >>>=20 >>> Regards, >>> Jeff >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shahram Davari >>> Sent: Monday, August 01, 2011 14:22 >>> To: Warren Kumari >>> Cc: rtg-bfd@ietf.org; Shane Amante >>> Subject: RE: Solicit comments on BFD for Interface draft >>>=20 >>> It doesn't matter if BFD is easier to configure since you need to = configure link OAM only once for some limited number of links in each = router. >>>=20 >>> Also the Argument that service providers are more familiar with BFD = therefore lets use BFD for any required OAM is very dangerous. I am sure = if this draft becomes and RFC then sooner or later drafts will pop up to = use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc. >>>=20 >>> I am sure IETF doesn't want to start a inter-operability nightmare. >>>=20 >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Warren Kumari [mailto:warren@kumari.net] >>> Sent: Monday, August 01, 2011 1:52 PM >>> To: Shahram Davari >>> Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org >>> Subject: Re: Solicit comments on BFD for Interface draft >>>=20 >>>=20 >>> On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: >>>=20 >>>> Let's do the math: >>>>=20 >>>> BFD Tx direction: >>>>=20 >>>> My Discr: Auto assignment by SW >>>> Your Discr: default to 0 >>>> Remote IP add: need to configure >>>> Min Tx interval: need to configure >>>> Min Rx interval: need to configure >>>>=20 >>>> BFD Rx direction: >>>>=20 >>>> Remote Discr: Learn (remote Disc=3D0 redirected to CPU for = learning) >>>> Remote Tx interval: learn >>>> Remote Rx interval: learn >>>>=20 >>>> CFM Tx direction: >>>> MD name: Auto assign for all MDL=3D0 (such as LinkMD) >>>> MDL: need to configure MDL=3D0 >>>> MEPID: Auto assign by SW >>>> UP/Down: SW can automatically set to down for all MDL=3D0 >>>> Tx Rate: need to configure >>>>=20 >>>> CFM Rx direction: >>>> MD name: Learn (unknown MDL redirected to CPU for learning) >>>> MDL: Learn (unknown MDL redirected to CPU for learning) >>>> MEPID: Learn (unknown MEPID redirected to CPU for learning) >>>> UP/Down: SW sets to Down for all MDL=3D0 >>>> Rx rate: need to configure >>>>=20 >>>>=20 >>>> As you can see there isn't much difference in configuration of BFD = and 802.1ag for Link OAM. For BFD one needs to configure the Remote IP = address and the Tx/Rx rate and for OAM one needs to configure the MDL = and the Tx/Rx rate. >>>>=20 >>>> So your argument is moot. >>>=20 >>> Which part? >>>=20 >>> You mean the "tools already understand generation of configlets (and = auditing)" bit? Please point to the bit where my (or most) CM systems = understands OAM config for major vendors... >>>=20 >>> You mean the "operators are already familiar with the protocol" bit? = Hmmm, also no... >>>=20 >>> Maybe you don't buy that "a lot of operators already use BFD in = their networks"? Really? >>>=20 >>> But, it has become apparent that you are not actually listening, so = I've lost interest.... >>>=20 >>> W >>>=20 >>>>=20 >>>> Regards >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: Warren Kumari [mailto:warren@kumari.net] >>>> Sent: Monday, August 01, 2011 8:39 AM >>>> To: Thomas Nadeau >>>> Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>=20 >>>>=20 >>>> On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >>>>=20 >>>>>=20 >>>>> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>>>>=20 >>>>>> Hi Shane, >>>>>>=20 >>>>>> Same for BFD. You need to know my discriminator, your = discriminator, local IP address, remote IP address, Min Tx Interval, Min = Rx Interval, Demand mode, Authentication, Active/Passive, Detection = Interval, etc. >>>>>=20 >>>>> While those parameters are required, that doesn't mean that = clever implementations can choose reasonable defaults for you. I know = such implementations from at least 3 major vendors. *) >>>>=20 >>>> +1 >>>>=20 >>>> Yes -- and a lot of operators already use BFD in their networks, = they are already familiar with the protocol, their tools already = understand generation of configlets (and auditing), etc. It already = "just works" -- having it run on component link seems like a no = brainer.... >>>>=20 >>>>>=20 >>>>>> Believe me BFD requires more configuration than 802.1ag. So your = argument of requiring a lot of info to configure 802.1ag applies even = more to BFD. >>>>>=20 >>>>> On paper perhaps, but in reality that is not the case. I do = not know of any implementations where MIP/MEP configuration is done = automatically such as is the case for links and routing protocols in the = major implementations using BFD. >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>> Shahram >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] = On Behalf Of Shane Amante >>>>>> Sent: Saturday, July 30, 2011 9:36 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>=20 >>>>>> Manav, Sharam, Others, >>>>>>=20 >>>>>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>>>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>>>>=20 >>>>>>> I completely agree that LACP is not fast enough and that = operators also want to detect individual component link breakdowns = instead of the entire LAG. If that's the case then folks should use IEEE = 802.1ag for individual component links and BFD for the entire LAG. Are = we trying to position BFD as an IETF equivalent of 802.1ag? Or is it = that we're trying to run BFD over component links since not all links = may be ethernet? >>>>>>=20 >>>>>> The main reason (we) operators want to use BFD instead of = 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link = failures in a LAG is: operational simplicity, clear and simple. >>>>>>=20 >>>>>> The problem with 802.1ag/Y.1731 is the massive amount of, = potentially error-prone, configuration required. Take a moment and = think about how many variables are *required* to properly set-up = 802.1ag/Y.1731: >>>>>> a) What MD "name" should you use? >>>>>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>>>>> c) What MD "level" should you use, (probably 0 or 1)? >>>>>> d) What MEP ID's do I assign to each side of the link? >>>>>> e) Don't forget to configure the right direction, up or down, = for the MEP? >>>>>> ... that is *ridiculous*! >>>>>>=20 >>>>>> Let's not forget that there are [potentially] 100's if not = 1,000's of LAG's in each carrier's network, so this needs to get = repeated over and over and over again. Bottom-line: 802.1ag/Y.1731 is = extremely complex to set-up *and* maintain. >>>>>>=20 >>>>>> BFD is simple. At a bare minimum you just need to configure an = "{Tx|Rx} interval". (The "multiplier" should default to 3, unless you = want to configure it differently). That's it! Done! >>>>>>=20 >>>>>> So, in short, let me throw my hat in the ring with other = operators that I really, really, really want a standards-based way of = running BFD over component-links in a LAG in order to quickly detect a = component-link failure and take it out of the bundle. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -shane >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> I think (and this is also what Shahram was alluding to) that BFD = is meant to detect IP liveliness. This means that if I run BFD over an = IP interface it should bring it down only when the IP connectivity goes = down. Shouldn't BFD be oblivious to the number of links alive in a LAG = as long as the LAG remains up and it can reach the other end. It is a = simple implementation effort to note the status of each component link = of a lag and to bring it down if the number goes below a certain = threshold - You don't need to run BFD over each link! >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>>>>> To: Bhatia, Manav (Manav) >>>>>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>>>=20 >>>>>>>> Hello Manav, >>>>>>>>=20 >>>>>>>> others have already replied but the part "[...] has no >>>>>>>> business" triggers now my reply. I deliberately >>>>>>>> "mis"-understand it. Point is that this is about business. >>>>>>>> Customers have pushed their vendors to implement BFD over LAG >>>>>>>> component links. Reasons I know >>>>>>>>=20 >>>>>>>> - LACP is not fast enough >>>>>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>>>>> Designers and Operations, so they would like to use it = everywhere >>>>>>>> - BFDs reputation for being fast and working >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> So now we have 3-4 different implementation for >>>>>>>> per-cmponent-link BFD that I know about. Potentially there >>>>>>>> exists more. Probably not that much different but enough to >>>>>>>> make interoperability impossible. It's again customers who >>>>>>>> push now for standardization. Thus the draft to find an = agreement :-) >>>>>>>>=20 >>>>>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>>>>> as I see two fundamental setups: (a) run BFD on every >>>>>>>> component link and (b) run a single BFD session over the LAG >>>>>>>> interface. They solve different network setups as far as I can = see. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, Marc >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>>>>=20 >>>>>>>>> Hi Jeff, >>>>>>>>>=20 >>>>>>>>> Let me understand this. If you have an IP interface over a >>>>>>>> LAG with 5 component links, then you internally establish 5 >>>>>>>> BFD sessions with 30ms timeouts? >>>>>>>>>=20 >>>>>>>>> You don't need to do this. You could use LACP for lag and >>>>>>>> BFD for IP connectivity - which means BFD should remain up as >>>>>>>> long as there is reachability over the lag. IMO it has no >>>>>>>> business to bother with each individual component links. >>>>>>>>>=20 >>>>>>>>> Cheers, Manav >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>>>>> To: Bhatia, Manav (Manav) >>>>>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> We have been supporting this mode of BFD over LAG >>>>>>>> operations for last 5 years and our customers love it. >>>>>>>>>=20 >>>>>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>>>>> hit min-links, do you really want to bring the LAG down? >>>>>>>>>=20 >>>>>>>>> Mach - be aware of patents :) >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Jeff >>>>>>>>>=20 >>>>>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Mach, >>>>>>>>>>=20 >>>>>>>>>> I am not sure I understand why you would want BFD to >>>>>>>> ensure liveliness of each component link in a LAG. The draft >>>>>>>> seems to suggest establishing separate BFD session for each >>>>>>>> pair of component interfaces to detect the failures. Why >>>>>>>> should BFD be concerned about each component link? I would >>>>>>>> rather that BFD sprays packets over each component link in a >>>>>>>> round robin fashion and brings down the IP interface over a >>>>>>>> lag only if it misses 3 consecutive packets. Am I missing = something? >>>>>>>>>>=20 >>>>>>>>>> Cheers, Manav >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>>>>> Behalf Of Mach Chen >>>>>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>>>>> To: rtg-bfd@ietf.org >>>>>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> We uploaded a new >>>>>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>>>>> interface). You are very welcome to read the draft and give >>>>>>>> your comments. >>>>>>>>>>=20 >>>>>>>>>> Many thanks, >>>>>>>>>> Mach >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Marc Binderberger >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >>=20 >=20 -- Marc Binderberger From marc@sniff.de Tue Aug 2 17:05:35 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE62711E80DD for ; Tue, 2 Aug 2011 17:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7l0nLOMY-13 for ; Tue, 2 Aug 2011 17:05:35 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6211E8095 for ; Tue, 2 Aug 2011 17:05:34 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A45532AA0F; Wed, 3 Aug 2011 00:05:40 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> Date: Wed, 3 Aug 2011 02:05:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> To: Rajeev Nair X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 00:05:35 -0000 Hello Rajeev, ah, wondered when this question comes :-) I assume with L2 cloud you mean Ethernet switches/bridges and not = Ethernet ports cross-connected through pseudo-wires ? So this situation: +-------+ +-------+ | Core1 | | Core2 | +-------+ +-------+ ||| ||| ||| ||| +----------+ | Ethernet | | Switch | +----------+ || | || | +---------+ +---------+ | Access1 | | Access2 | +---------+ +---------+ Section of an example PoP network topology. Double/triple lines indicate LAG links. Answer is: is not implemented for switches in between, only for = back-to-back scenarios (to my best knowledge but I can confirm it only = for one vendor). The reason is simplicity and that is was/is sufficient for the customers = (which may change, of course). Regards, Marc On 2011-08-01, at 11:16 PM, Rajeev Nair wrote: > Hi Mach, >=20 > Does this scheme (or a current per-link implementation) work with a = port-channel that is not connected back-to-back ?=20 > i.e. L3 port-channels with L2 cloud in between ? >=20 > thanks > Rajeev >=20 > On Jul 28, 2011, at 3:34 PM, Mach Chen wrote: >=20 >> Hi, >>=20 >> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >>=20 >> Many thanks, >> Mach >=20 -- Marc Binderberger From davari@broadcom.com Tue Aug 2 17:22:48 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA47011E8117 for ; Tue, 2 Aug 2011 17:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBmr+-2xNkt1 for ; Tue, 2 Aug 2011 17:22:47 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 924F811E8108 for ; Tue, 2 Aug 2011 17:22:45 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 02 Aug 2011 17:25:35 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 2 Aug 2011 17:20:35 -0700 From: "Shahram Davari" To: "Marc Binderberger" Date: Tue, 2 Aug 2011 17:20:33 -0700 Subject: RE: Solicit comments on BFD for Interface draft Thread-Topic: Solicit comments on BFD for Interface draft Thread-Index: AcxRZwGgj6TcqDnkRYm8ih6yW3UrgwAAPLqQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBE5D@SJEXCHCCR02.corp.ad.broadcom.com> References: <7C362EEF9C7896468B36C9B79200D8350CFF56D466@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFF56D46D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20A4247E-A076-4041-9313-EAE9E077B349@sniff.de> <7C362EEF9C7896468B36C9B79200D8350CFF56D684@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6A93261641D@SJEXCHCCR02.corp.ad.broadcom.com> <94637E03-B99B-4AA2-A27E-F1D550DDA570@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93261678F@SJEXCHCCR02.corp.ad.broadcom.com> <286D55E3-B14B-457D-8BF8-B5664788D778@kumari.net> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB523@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6BB9@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326 CBC13@SJEXCHCCR02.corp.ad.broadcom.com> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA2C6CCB@EUSAACMS0701.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CBCE1@SJEXCHCCR02.corp.ad.broadcom.com> <1FB1AAF1-CDDF-4CAD-8A40-BEA8C0474F0F@sniff.de> In-Reply-To: <1FB1AAF1-CDDF-4CAD-8A40-BEA8C0474F0F@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62264AF53KO1992176-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Shane Amante , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 00:22:49 -0000 Marc, The reason we have layers is that they stay independent of each other so th= at you can stack them as you wish and still be able to provide a proper ser= vice. Now (as you said) constructive comments (since I have to implement it): 1) I suggest using a Known Multicast MAC address such as the one used for 8= 02.1ag (01-80-C2-00-00-30) so that these packets can be filtered before the= LAG is terminated. This way you have terminated the MAC and can process th= e payload that is BFD. This can avoid a) layer violation b) can be used in = networks without IP layer such as MPLS-TP, c) BFD can be run even when that= link is disabled by LAG. 2) I suggest generating AIS for the higher level BFD flow in case of the fa= ilure detection on component links since the higher level BFD may trigger p= rotection switching 3) I suggest restricting this draft to a single P2P Ethernet physical Link = and explicitly say a non P2P link and switched Ethernet network between the= routers is outside of the scope of this draft. 4) I suggest stating that both sides should be BFD Active by default to ens= ure it always works without configuration. Also explicitly stating that Dem= and mode is not require to be supported. I will send more comments latee. Thanks Shahram -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Tuesday, August 02, 2011 3:53 PM To: Shahram Davari Cc: Jeff Tantsura; Warren Kumari; Shane Amante; rtg-bfd@ietf.org Subject: Re: Solicit comments on BFD for Interface draft Shahram, making comments like "hack" (but without the quotes) is not professional an= d simply inappropriate in my book. You repeatedly made incorrect statements= about what we try to achieve and then argue against it (e.g. [1][2]). Inte= resting technique for a technical discussion ... . Regarding the layer violation, as this is a central point of your criticism= : layers are not a value on their own. It's a tool to modularize a problem.= It's a good tool but nothing is absolute. The draft is mentioning what pro= blem can happen because we know some implementation have done it, so for th= e sake of interoperability it should be mentioned. I think we used the corr= ect phrases like MAY etc. to ensure such behaviour is not a mandatory part = of the proposal. Anyway, we will pick up some of the detailed questions you asked in former = emails in an updated draft and I appreciate this constructive input. I say = "some" as for some others the answer will be that it's an "implementation d= etail", like how to send out on a specific component link or how to handle = this on a central CPU. Regards, Marc [1]: "Also the Argument that service providers are more familiar with BFD t= herefore lets use BFD for any required OAM is very dangerous. I am sure if = this draft becomes and RFC then sooner or later drafts will pop up to use B= FD for Ethernet, SONET, OTN, PON, MLPPP, etc." [2]: "Your argument is not valid that we need a single protocol to do Link = as well as IP layer OAM, since if you continue this path sooner or later on= e could ask why not run BFD for Ethernet and why not run BFD for OTN and wh= y not run BFD for GPON." On 2011-08-02, at 11:28 PM, Shahram Davari wrote: > I made my objection to this draft based on technical grounds and sound en= gineering practices. I leave it to the rest of the group member to endorse = or object to this hack. > > Thx > Shahram > > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, August 02, 2011 2:10 PM > To: Shahram Davari; Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft > > Hi Shahram, > > Please don't tell me you are making your products for the sake of making = them or trying to make the world a better place. > > We did it because our customers asked us to, Cisco did it last year for e= xactly same reasons. Others didn't because either their customers didn't re= alize how good it could work/ couldn't properly do it, mostly due to ASIC's= limitations. > > Personally - I'm intimately familiar with at least 4 different vendors CL= Is - BFD is MUCH easier to configure on all of them. > > Another aspect of the story - historically BFD has been available on most= platforms for at least 5 years while L2 OAM at sub 100ms just 2-3 years. > > /drama mode on > "Dear vendor - we'd like to spend M $xxx on your products if you do per c= onstituent BFD as we are familiar with it, like it and run it everywhere" - > go away and don't come back - you bloody layer violator :) > /drama mode off > > It would be great if we could interoperate with other vendors, our custom= ers would greatly benefit! > > Regards, > Jeff > > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Tuesday, August 02, 2011 12:46 > To: Jeff Tantsura; Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft > > Hi Jeff, > > Not only I have talked to a live customer but I have talked to live custo= mer's customer as well. Also Shane and Warren are not paying my salary and = my intention is not to please them. > > Thx > Shahram > > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, August 02, 2011 12:32 PM > To: Shahram Davari; Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft > > Hi Shahram, > > Have you ever talked to a "live" customer? > You should be grateful for Shane's and Warren's comments providing their = point of view. > At the end your salary is paid by them... > > Regards, > Jeff > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Shahram Davari > Sent: Monday, August 01, 2011 14:22 > To: Warren Kumari > Cc: rtg-bfd@ietf.org; Shane Amante > Subject: RE: Solicit comments on BFD for Interface draft > > It doesn't matter if BFD is easier to configure since you need to configu= re link OAM only once for some limited number of links in each router. > > Also the Argument that service providers are more familiar with BFD there= fore lets use BFD for any required OAM is very dangerous. I am sure if this= draft becomes and RFC then sooner or later drafts will pop up to use BFD f= or Ethernet, SONET, OTN, PON, MLPPP, etc. > > I am sure IETF doesn't want to start a inter-operability nightmare. > > Shahram > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, August 01, 2011 1:52 PM > To: Shahram Davari > Cc: Thomas Nadeau; Shane Amante; rtg-bfd@ietf.org > Subject: Re: Solicit comments on BFD for Interface draft > > > On Aug 1, 2011, at 1:16 PM, Shahram Davari wrote: > >> Let's do the math: >> >> BFD Tx direction: >> >> My Discr: Auto assignment by SW >> Your Discr: default to 0 >> Remote IP add: need to configure >> Min Tx interval: need to configure >> Min Rx interval: need to configure >> >> BFD Rx direction: >> >> Remote Discr: Learn (remote Disc=3D0 redirected to CPU for learning) >> Remote Tx interval: learn >> Remote Rx interval: learn >> >> CFM Tx direction: >> MD name: Auto assign for all MDL=3D0 (such as LinkMD) >> MDL: need to configure MDL=3D0 >> MEPID: Auto assign by SW >> UP/Down: SW can automatically set to down for all MDL=3D0 >> Tx Rate: need to configure >> >> CFM Rx direction: >> MD name: Learn (unknown MDL redirected to CPU for learning) >> MDL: Learn (unknown MDL redirected to CPU for learning) >> MEPID: Learn (unknown MEPID redirected to CPU for learning) >> UP/Down: SW sets to Down for all MDL=3D0 >> Rx rate: need to configure >> >> >> As you can see there isn't much difference in configuration of BFD and 8= 02.1ag for Link OAM. For BFD one needs to configure the Remote IP address a= nd the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx = rate. >> >> So your argument is moot. > > Which part? > > You mean the "tools already understand generation of configlets (and audi= ting)" bit? Please point to the bit where my (or most) CM systems understan= ds OAM config for major vendors... > > You mean the "operators are already familiar with the protocol" bit? Hmmm= , also no... > > Maybe you don't buy that "a lot of operators already use BFD in their net= works"? Really? > > But, it has become apparent that you are not actually listening, so I've = lost interest.... > > W > >> >> Regards >> Shahram >> >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net] >> Sent: Monday, August 01, 2011 8:39 AM >> To: Thomas Nadeau >> Cc: Shahram Davari; Shane Amante; rtg-bfd@ietf.org >> Subject: Re: Solicit comments on BFD for Interface draft >> >> >> On Aug 1, 2011, at 9:08 AM, Thomas Nadeau wrote: >> >>> >>> On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote: >>> >>>> Hi Shane, >>>> >>>> Same for BFD. You need to know my discriminator, your discriminator, l= ocal IP address, remote IP address, Min Tx Interval, Min Rx Interval, Deman= d mode, Authentication, Active/Passive, Detection Interval, etc. >>> >>> While those parameters are required, that doesn't mean that clever = implementations can choose reasonable defaults for you. I know such impleme= ntations from at least 3 major vendors. *) >> >> +1 >> >> Yes -- and a lot of operators already use BFD in their networks, they ar= e already familiar with the protocol, their tools already understand genera= tion of configlets (and auditing), etc. It already "just works" -- having i= t run on component link seems like a no brainer.... >> >>> >>>> Believe me BFD requires more configuration than 802.1ag. So your argum= ent of requiring a lot of info to configure 802.1ag applies even more to BF= D. >>> >>> On paper perhaps, but in reality that is not the case. I do not kn= ow of any implementations where MIP/MEP configuration is done automatically= such as is the case for links and routing protocols in the major implement= ations using BFD. >>> >>> --Tom >>> >>> >>>> >>>> Regards >>>> Shahram >>>> >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Be= half Of Shane Amante >>>> Sent: Saturday, July 30, 2011 9:36 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Solicit comments on BFD for Interface draft >>>> >>>> Manav, Sharam, Others, >>>> >>>> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote: >>>>> I think the diagnoses is correct, but the medicine isn't! :-) >>>>> >>>>> I completely agree that LACP is not fast enough and that operators al= so want to detect individual component link breakdowns instead of the entir= e LAG. If that's the case then folks should use IEEE 802.1ag for individual= component links and BFD for the entire LAG. Are we trying to position BFD = as an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD ove= r component links since not all links may be ethernet? >>>> >>>> The main reason (we) operators want to use BFD instead of 802.1ag/Y.17= 31 (or 802.3ah) for *fast* detection of component-link failures in a LAG is= : operational simplicity, clear and simple. >>>> >>>> The problem with 802.1ag/Y.1731 is the massive amount of, potentially = error-prone, configuration required. Take a moment and think about how man= y variables are *required* to properly set-up 802.1ag/Y.1731: >>>> a) What MD "name" should you use? >>>> b) What MD "name format" should you use, (ASCII, DNS, etc.)? >>>> c) What MD "level" should you use, (probably 0 or 1)? >>>> d) What MEP ID's do I assign to each side of the link? >>>> e) Don't forget to configure the right direction, up or down, for the= MEP? >>>> ... that is *ridiculous*! >>>> >>>> Let's not forget that there are [potentially] 100's if not 1,000's of = LAG's in each carrier's network, so this needs to get repeated over and ove= r and over again. Bottom-line: 802.1ag/Y.1731 is extremely complex to set-= up *and* maintain. >>>> >>>> BFD is simple. At a bare minimum you just need to configure an "{Tx|R= x} interval". (The "multiplier" should default to 3, unless you want to co= nfigure it differently). That's it! Done! >>>> >>>> So, in short, let me throw my hat in the ring with other operators tha= t I really, really, really want a standards-based way of running BFD over c= omponent-links in a LAG in order to quickly detect a component-link failure= and take it out of the bundle. > > > > > >>>> >>>> Thanks, >>>> >>>> -shane >>>> >>>> >>>> >>>>> I think (and this is also what Shahram was alluding to) that BFD is m= eant to detect IP liveliness. This means that if I run BFD over an IP inter= face it should bring it down only when the IP connectivity goes down. Shoul= dn't BFD be oblivious to the number of links alive in a LAG as long as the = LAG remains up and it can reach the other end. It is a simple implementatio= n effort to note the status of each component link of a lag and to bring it= down if the number goes below a certain threshold - You don't need to run = BFD over each link! >>>>> >>>>> Cheers, Manav >>>>> >>>>>> -----Original Message----- >>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>> Sent: Saturday, July 30, 2011 3:34 AM >>>>>> To: Bhatia, Manav (Manav) >>>>>> Cc: Jeff Tantsura; rtg-bfd@ietf.org >>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>> >>>>>> Hello Manav, >>>>>> >>>>>> others have already replied but the part "[...] has no >>>>>> business" triggers now my reply. I deliberately >>>>>> "mis"-understand it. Point is that this is about business. >>>>>> Customers have pushed their vendors to implement BFD over LAG >>>>>> component links. Reasons I know >>>>>> >>>>>> - LACP is not fast enough >>>>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco >>>>>> Designers and Operations, so they would like to use it everywhere >>>>>> - BFDs reputation for being fast and working >>>>>> >>>>>> >>>>>> So now we have 3-4 different implementation for >>>>>> per-cmponent-link BFD that I know about. Potentially there >>>>>> exists more. Probably not that much different but enough to >>>>>> make interoperability impossible. It's again customers who >>>>>> push now for standardization. Thus the draft to find an agreement :-= ) >>>>>> >>>>>> Will there be only one solution for "BFD over LAG"? Not sure >>>>>> as I see two fundamental setups: (a) run BFD on every >>>>>> component link and (b) run a single BFD session over the LAG >>>>>> interface. They solve different network setups as far as I can see. >>>>>> >>>>>> >>>>>> Regards, Marc >>>>>> >>>>>> >>>>>> >>>>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote: >>>>>> >>>>>>> Hi Jeff, >>>>>>> >>>>>>> Let me understand this. If you have an IP interface over a >>>>>> LAG with 5 component links, then you internally establish 5 >>>>>> BFD sessions with 30ms timeouts? >>>>>>> >>>>>>> You don't need to do this. You could use LACP for lag and >>>>>> BFD for IP connectivity - which means BFD should remain up as >>>>>> long as there is reachability over the lag. IMO it has no >>>>>> business to bother with each individual component links. >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >>>>>>> Sent: Friday, July 29, 2011 7:15 AM >>>>>>> To: Bhatia, Manav (Manav) >>>>>>> Cc: Mach Chen; rtg-bfd@ietf.org >>>>>>> Subject: Re: Solicit comments on BFD for Interface draft >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have been supporting this mode of BFD over LAG >>>>>> operations for last 5 years and our customers love it. >>>>>>> >>>>>>> Manav - imagine you have lost 3 out of 8 links but didn't >>>>>> hit min-links, do you really want to bring the LAG down? >>>>>>> >>>>>>> Mach - be aware of patents :) >>>>>>> >>>>>>> Regards, >>>>>>> Jeff >>>>>>> >>>>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" >>>>>> wrote: >>>>>>> >>>>>>>> Hi Mach, >>>>>>>> >>>>>>>> I am not sure I understand why you would want BFD to >>>>>> ensure liveliness of each component link in a LAG. The draft >>>>>> seems to suggest establishing separate BFD session for each >>>>>> pair of component interfaces to detect the failures. Why >>>>>> should BFD be concerned about each component link? I would >>>>>> rather that BFD sprays packets over each component link in a >>>>>> round robin fashion and brings down the IP interface over a >>>>>> lag only if it misses 3 consecutive packets. Am I missing something? >>>>>>>> >>>>>>>> Cheers, Manav >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: rtg-bfd-bounces@ietf.org >>>>>> [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>>> Behalf Of Mach Chen >>>>>>>> Sent: Friday, July 29, 2011 4:05 AM >>>>>>>> To: rtg-bfd@ietf.org >>>>>>>> Subject: Solicit comments on BFD for Interface draft >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We uploaded a new >>>>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) >>>>>> that is about BFD running over interface(e.g., LAG/Bundle >>>>>> interface). You are very welcome to read the draft and give >>>>>> your comments. >>>>>>>> >>>>>>>> Many thanks, >>>>>>>> Mach >>>>>>> >>>>>> >>>>>> -- >>>>>> Marc Binderberger >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > > > > > > -- Marc Binderberger From adrian@olddog.co.uk Thu Aug 11 10:14:22 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A42621F8BCB for ; Thu, 11 Aug 2011 10:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE7Czu9nDE0Z for ; Thu, 11 Aug 2011 10:14:22 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 768AC21F8BAD for ; Thu, 11 Aug 2011 10:14:20 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7BH9C4g027220; Thu, 11 Aug 2011 18:09:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7BH9BXx027211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Aug 2011 18:09:12 +0100 From: "Adrian Farrel" To: , Subject: IESG offers minor edits to the new BFD Charter Date: Thu, 11 Aug 2011 18:14:47 +0100 Message-ID: <058901cc584a$2c62abf0$852803d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxYSgUr9GagkjfQS7OvGyUzQPyLUw== Content-Language: en-gb X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:14:22 -0000 Hi, The IESG approves the new charter, but suggests two security-related updates. Can I test the water with you all, please. Thanks, Adrian OLD 2c. Specify cryptographic authentication procedures for the BFD protocol using SHA-2 and HMAC-SHA-2 using the generic keying-based cryptographic authentication mechanism. NEW 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. END and OLD Dec 2011 Submit the cryptographic authentication procedures for BFD for SHA-2 and HMAC-SHA2 to the IESG to be considered as a Proposed Standard NEW Dec 2011 Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard END From tnadeau@lucidvision.com Thu Aug 11 10:17:01 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0678E21F8B08 for ; Thu, 11 Aug 2011 10:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSVa6lx8GhoY for ; Thu, 11 Aug 2011 10:17:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 601CC21F8B07 for ; Thu, 11 Aug 2011 10:17:00 -0700 (PDT) Received: from [10.100.68.51] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id DB9B31D70E7B; Thu, 11 Aug 2011 13:17:34 -0400 (EDT) Subject: Re: IESG offers minor edits to the new BFD Charter Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <058901cc584a$2c62abf0$852803d0$@olddog.co.uk> Date: Thu, 11 Aug 2011 13:17:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B10AD00-C864-4114-B2FC-882E15D2E1C1@lucidvision.com> References: <058901cc584a$2c62abf0$852803d0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1244.3) Cc: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2011 17:17:01 -0000 This seems reasonable.=20 --Tom On Aug 11, 2011, at 1:14 PM, Adrian Farrel wrote: > Hi, >=20 > The IESG approves the new charter, but suggests two security-related = updates. > Can I test the water with you all, please. >=20 > Thanks, > Adrian >=20 > OLD > 2c. Specify cryptographic authentication procedures for the BFD = protocol > using SHA-2 and HMAC-SHA-2 using the generic keying-based = cryptographic > authentication mechanism. > NEW > 2c. Specify cryptographic authentication procedures for the BFD = protocol > using HMAC-SHA-256 (possibly truncated to a smaller integrity check = value) > using the generic keying-based cryptographic authentication mechanism. > END >=20 > and >=20 > OLD > Dec 2011 Submit the cryptographic authentication procedures for BFD > for SHA-2 and HMAC-SHA2 to the IESG to be considered as a > Proposed Standard > NEW > Dec 2011 Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > END >=20 >=20 From adrian@olddog.co.uk Thu Aug 18 10:30:17 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85491F0C3F for ; Thu, 18 Aug 2011 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwMW3ixkWfsR for ; Thu, 18 Aug 2011 10:30:17 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3206E11E808C for ; Thu, 18 Aug 2011 10:30:17 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7IHVAEc017064; Thu, 18 Aug 2011 18:31:10 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7IHV6bb017052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Aug 2011 18:31:06 +0100 From: "Adrian Farrel" To: , References: <058901cc584a$2c62abf0$852803d0$@olddog.co.uk> In-Reply-To: <058901cc584a$2c62abf0$852803d0$@olddog.co.uk> Subject: RE: IESG offers minor edits to the new BFD Charter Date: Thu, 18 Aug 2011 18:31:05 +0100 Message-ID: <02ce01cc5dcc$9c9e18a0$d5da49e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJpCMByIIqxLDdl78k+UEn3o4drYZPphvzA Content-Language: en-gb X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:30:18 -0000 Hi, I heard one murmur of "whatever" and otherwise silence. So I'll go ahead and approve this. Thanks, Adrian > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 11 August 2011 18:15 > To: rtg-bfd@ietf.org; bfd-chairs@tools.ietf.org > Subject: IESG offers minor edits to the new BFD Charter > > Hi, > > The IESG approves the new charter, but suggests two security-related updates. > Can I test the water with you all, please. > > Thanks, > Adrian > > OLD > 2c. Specify cryptographic authentication procedures for the BFD protocol > using SHA-2 and HMAC-SHA-2 using the generic keying-based cryptographic > authentication mechanism. > NEW > 2c. Specify cryptographic authentication procedures for the BFD protocol > using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) > using the generic keying-based cryptographic authentication mechanism. > END > > and > > OLD > Dec 2011 Submit the cryptographic authentication procedures for BFD > for SHA-2 and HMAC-SHA2 to the IESG to be considered as a > Proposed Standard > NEW > Dec 2011 Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > END From adrian@olddog.co.uk Thu Aug 18 10:42:28 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889FF21F8713 for ; Thu, 18 Aug 2011 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQn-ociAcfTz for ; Thu, 18 Aug 2011 10:42:28 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id C7A8021F85FF for ; Thu, 18 Aug 2011 10:42:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7IHb4Vt013459; Thu, 18 Aug 2011 18:37:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7IHb35L013452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Aug 2011 18:37:04 +0100 From: "Adrian Farrel" To: Subject: Change in "responsible" AD Date: Thu, 18 Aug 2011 18:43:18 +0100 Message-ID: <02e001cc5dce$511af8b0$f350ea10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acxdzk9moehI7Uc7TTGCw5rG3oX43A== Content-Language: en-gb X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:42:28 -0000 Hi, Having pushed through (finally :-) your charter update, it is time for me to swap responsibility for the WG with Stewart. Since both the chairs have Juniper sponsorship, it is not appropriate for me (also sponsored by Juniper) to be the responsible AD. Thanks for the work, and good luck with the next steps. You should see the new charter and the change in AD posted to the charter page soon. Adrian From wwwrun@ietfa.amsl.com Thu Aug 18 11:40:13 2011 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id A9A5B21F8BB2; Thu, 18 Aug 2011 11:40:13 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Subject: WG Action: RECHARTER: Bidirectional Forwarding Detection (bfd) Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110818184013.A9A5B21F8BB2@ietfa.amsl.com> Date: Thu, 18 Aug 2011 11:40:13 -0700 (PDT) Cc: rtg-bfd@ietf.org, dward@juniper.net X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2011 18:40:13 -0000 The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Bidirectional Forwarding Detection (bfd) --------------------------------------------------- Current Status: Active Working Group Chairs: David Ward Jeffrey Haas Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Technical Advisor: Dave Katz Mailing List: Address: rtg-bfd@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/rtg-bfd Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to-multipoint links and networks. 4. Provide a mechanism for bootstrapping BFD on dynamically configured edge devices using DHCPv4 and DHCPv6. 5. Assist in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 6. Assist with the standardization of the BFD protocol for Trill. Goals and Milestones: Done Submit the base protocol specification to the IESG to be considered as a Proposed Standard. Done Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Sep 2011 Submit the BFD MIB to the IESG to be considered as a Proposed Standard Dec 2011 Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Dec 2011 Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Dec 2011 Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Mar 2012 Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Jun 2012 Submit the bootstrapping mechanism for BFD using DHCP to the IESG to be considered as a Proposed Standard From rajeenai@cisco.com Tue Aug 23 14:29:10 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1BD21F8C52 for ; Tue, 23 Aug 2011 14:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4XRI8z4Qy20 for ; Tue, 23 Aug 2011 14:29:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BF6EE21F8C4B for ; Tue, 23 Aug 2011 14:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajeenai@cisco.com; l=2490; q=dns/txt; s=iport; t=1314135019; x=1315344619; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tUfsd3LMk0Fct7XvdhcckpynxVkPL4KIj3dnty4S7gQ=; b=RwtfyRr0GCMnBy4CV3ko9tIip3B7AURgMQB0PGJNaZJCiM3nBds/Wy5g 7WBUcS47lE18FThSMB5yyB3v5QZjU1F3Kgp9W/mKyg9gS7RYYExrKMvty 2f50gM9u7bOZeh/XkGPDEO78bCZO3GyjfvT1uYZo7LSUinBc0m4Qj6BVw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALcaVE6rRDoI/2dsb2JhbABCp2V3gTkHAQEBAQIBEgEnPwULCxguVwYTIodPBJ1yAZ9EhWlfBIdhiziRGg X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15837982" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 23 Aug 2011 21:30:18 +0000 Received: from dhcp-171-71-55-223.cisco.com (dhcp-171-71-55-223.cisco.com [171.71.55.223]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7NLUHoj003292; Tue, 23 Aug 2011 21:30:17 GMT Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rajeev Nair In-Reply-To: Date: Tue, 23 Aug 2011 14:31:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> To: Marc Binderberger X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2011 21:29:11 -0000 Hi Marc, There isn't anything in the proposal that says it applies only to = back-to-back L3 scenarios.=20 If this is pushed as a replacement for LACP it should address L2 in = middle scenario as well. For achieving correct inter operability, packet format should also be = captured in this same draft.=20 thanks & regards Rajeev On Aug 2, 2011, at 5:05 PM, Marc Binderberger wrote: > Hello Rajeev, >=20 > ah, wondered when this question comes :-) > I assume with L2 cloud you mean Ethernet switches/bridges and not = Ethernet ports cross-connected through pseudo-wires ? >=20 > So this situation: >=20 > +-------+ +-------+ > | Core1 | | Core2 | > +-------+ +-------+ > ||| ||| > ||| ||| > +----------+ > | Ethernet | > | Switch | > +----------+ > || | > || | > +---------+ +---------+ > | Access1 | | Access2 | > +---------+ +---------+ >=20 > Section of an example PoP network topology. Double/triple lines > indicate LAG links. >=20 >=20 > Answer is: is not implemented for switches in between, only for = back-to-back scenarios (to my best knowledge but I can confirm it only = for one vendor). >=20 > The reason is simplicity and that is was/is sufficient for the = customers (which may change, of course). >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On 2011-08-01, at 11:16 PM, Rajeev Nair wrote: >=20 >> Hi Mach, >>=20 >> Does this scheme (or a current per-link implementation) work with a = port-channel that is not connected back-to-back ?=20 >> i.e. L3 port-channels with L2 cloud in between ? >>=20 >> thanks >> Rajeev >>=20 >> On Jul 28, 2011, at 3:34 PM, Mach Chen wrote: >>=20 >>> Hi, >>>=20 >>> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >>>=20 >>> Many thanks, >>> Mach >>=20 >=20 > -- > Marc Binderberger >=20 From marc@sniff.de Tue Aug 23 17:18:33 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472C21F8C8D for ; Tue, 23 Aug 2011 17:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1q-5+Wq8d5e for ; Tue, 23 Aug 2011 17:18:33 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2021F8C93 for ; Tue, 23 Aug 2011 17:18:32 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 57D202AA0F; Wed, 24 Aug 2011 00:19:39 +0000 (GMT) Subject: Re: Solicit comments on BFD for Interface draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 24 Aug 2011 02:19:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29CF5DF8-D27B-4650-B83B-E309FDE0637B@sniff.de> References: <496E6C1D-AF83-4BC9-AA40-53C1985FA937@cisco.com> To: Rajeev Nair X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 00:18:34 -0000 Hello Rajeev, > There isn't anything in the proposal that says it applies only to = back-to-back L3 scenarios.=20 yes, the v01 draft needs a lot more of these clarifications. We start = working on it. Now the reason why the existing implementations - and thus the draft - = "aren't for L2 switches" is that a 1:1 relation of the links are = required. The LAG (L1) would not cross a switch, it would terminate on = the switch and potentially another LAG (L2) on the other side would = connect switch and peer router. Even when both L1 and L2 have the same = number of component links there is no guarantee of a 1:1 relation for = BFD packets. There exists a vague idea of extending the per-component link BFD to run = through a switch. Hasn't been discussed and thought-out yet to the = extend that I want to share it. Also: the existing draft should IMHO be = a kind of subset - and taking the amount of discussion we had I think it = makes sense to do this first step first. > If this is pushed as a replacement for LACP it should address L2 in = middle scenario as well. I think this is a misunderstanding and actually most customers I know = run this together wit LACP. It is not a replacement (although you could = use it that way) but a "booster" for detection. And as mentioned by = others it is attractive to customers with an IP focus. > For achieving correct inter operability, packet format should also be = captured in this same draft.=20 Okay. Well, the packet is RFC5880/RFC5881 but I agree we need to add = more details; we got several comments in this direction, which we = address in the v01 draft. Thanks for the feedback! Marc >=20 > thanks & regards > Rajeev >=20 > On Aug 2, 2011, at 5:05 PM, Marc Binderberger wrote: >=20 >> Hello Rajeev, >>=20 >> ah, wondered when this question comes :-) >> I assume with L2 cloud you mean Ethernet switches/bridges and not = Ethernet ports cross-connected through pseudo-wires ? >>=20 >> So this situation: >>=20 >> +-------+ +-------+ >> | Core1 | | Core2 | >> +-------+ +-------+ >> ||| ||| >> ||| ||| >> +----------+ >> | Ethernet | >> | Switch | >> +----------+ >> || | >> || | >> +---------+ +---------+ >> | Access1 | | Access2 | >> +---------+ +---------+ >>=20 >> Section of an example PoP network topology. Double/triple lines >> indicate LAG links. >>=20 >>=20 >> Answer is: is not implemented for switches in between, only for = back-to-back scenarios (to my best knowledge but I can confirm it only = for one vendor). >>=20 >> The reason is simplicity and that is was/is sufficient for the = customers (which may change, of course). >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >>=20 >> On 2011-08-01, at 11:16 PM, Rajeev Nair wrote: >>=20 >>> Hi Mach, >>>=20 >>> Does this scheme (or a current per-link implementation) work with a = port-channel that is not connected back-to-back ?=20 >>> i.e. L3 port-channels with L2 cloud in between ? >>>=20 >>> thanks >>> Rajeev >>>=20 >>> On Jul 28, 2011, at 3:34 PM, Mach Chen wrote: >>>=20 >>>> Hi, >>>>=20 >>>> We uploaded a new = draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is = about BFD running over interface(e.g., LAG/Bundle interface). You are = very welcome to read the draft and give your comments. >>>>=20 >>>> Many thanks, >>>> Mach >>>=20 >>=20 >> -- >> Marc Binderberger >>=20 >=20 -- Marc Binderberger